idnits 2.17.00 (12 Aug 2021) /tmp/idnits16623/draft-saintandre-tls-server-id-check-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2010) is 4176 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) == Outdated reference: draft-daboo-srv-email has been published as RFC 6186 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. 'LDAP-TLS') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 4741 (ref. 'NETCONF') (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (ref. 'NETCONF-SSH') (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5539 (ref. 'NETCONF-TLS') (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2459 (ref. 'PKIX-OLD') (Obsoleted by RFC 3280) -- Obsolete informational reference (is this intentional?): RFC 5953 (ref. 'SNMP-TLS') (Obsoleted by RFC 6353) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) == Outdated reference: draft-ietf-tls-rfc4366-bis has been published as RFC 6066 == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP-OLD') (Obsoleted by RFC 6120) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: BCP J. Hodges 5 Expires: June 16, 2011 PayPal 6 December 13, 2010 8 Representation and Verification of Domain-Based Application Service 9 Identity within Internet Public Key Infrastructure Using X.509 (PKIX) 10 Certificates in the Context of Transport Layer Security (TLS) 11 draft-saintandre-tls-server-id-check-12 13 Abstract 15 Many application technologies enable secure communication between two 16 entities by means of Internet Public Key Infrastructure Using X.509 17 (PKIX) certificates in the context of Transport Layer Security (TLS). 18 This document specifies best current practices for representing and 19 verifying the identity of application services in such interactions. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 16, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2. Applicability and Audience . . . . . . . . . . . . . . . . 5 58 1.3. Overview of Recommendations . . . . . . . . . . . . . . . 6 59 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7 62 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 63 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 2.1. Naming Application Services . . . . . . . . . . . . . . . 13 65 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 66 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 67 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 68 3. Representation of Server Identity . . . . . . . . . . . . . . 18 69 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 4. Verification of Service Identity . . . . . . . . . . . . . . . 20 72 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 4.2. Constructing a List of Reference Identifiers . . . . . . . 20 74 4.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 75 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 22 76 4.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 22 77 4.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 24 78 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 24 79 4.4.2. Checking of Internationalized Domain Names . . . . . . 24 80 4.4.3. Checking of Wildcard Certificates . . . . . . . . . . 25 81 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 25 82 4.5. Matching the Application Type Portion . . . . . . . . . . 26 83 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 26 84 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 26 85 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 26 87 4.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 27 88 4.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 27 89 4.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 27 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 91 5.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 28 92 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 28 93 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 29 94 5.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 29 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 101 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 37 102 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 37 103 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 38 104 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 39 105 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 42 106 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 43 107 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 44 108 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 45 109 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 47 110 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 48 111 A.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 49 112 A.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 50 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 115 1. Introduction 117 1.1. Motivation 119 The visible face of the Internet largely consists of services that 120 employ a client-server architecture in which an interactive or 121 automated client communicates with an application service in order to 122 retrieve or upload information, communicate with other entities, or 123 access a broader network of services. When a client communicates 124 with an application service using Transport Layer Security [TLS] or 125 Datagram Transport Layer Security [DTLS], it references some notion 126 of the server's identity (e.g., "the website at example.com") while 127 attempting to establish secure communication. Likewise, during TLS 128 negotiation the server presents its notion of the service's identity 129 in the form of a public-key certificate that was issued by a 130 certification authority (CA) in the context of the Internet Public 131 Key Infrastructure using X.509 [PKIX]. Informally, we can think of 132 these identities as the client's "reference identity" and the 133 server's "presented identity" (these rough ideas are defined more 134 precisely later in this document through the concept of particular 135 identifiers). In general, a client needs to verify that the server's 136 presented identity matches its reference identity so it can be sure 137 that the certificate can legitimately be used to authenticate the 138 communication. 140 Many application technologies adhere to the pattern just outlined, 141 including but not limited to the following: 143 o The Internet Message Access Protocol [IMAP] and the Post Office 144 Protocol [POP3], for which see also [USINGTLS] 146 o The Hypertext Transfer Protocol [HTTP], for which see also 147 [HTTP-TLS] 149 o The Lightweight Directory Access Protocol [LDAP], for which see 150 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 152 o The Simple Mail Transfer Protocol [SMTP], for which see also 153 [SMTP-AUTH] and [SMTP-TLS] 155 o The Extensible Messaging and Presence Protocol [XMPP], for which 156 see also [XMPP-OLD] 158 o The Network News Transfer Protocol [NNTP], for which see also 159 [NNTP-TLS] 161 o The NETCONF Configuration Protocol [NETCONF], for which see also 162 [NETCONF-SSH] and [NETCONF-TLS] 164 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] and 165 [SYSLOG-DTLS] 167 o The Session Initiation Protocol [SIP], for which see also 168 [SIP-CERTS] 170 o The Simple Network Management Protocol [SNMP], for which see also 171 [SNMP-TLS] 173 o The General Internet Signalling Transport [GIST] 175 Application protocols have traditionally specified their own rules 176 for representing and verifying application service identity. 177 Unfortunately, this divergence of approaches has caused some 178 confusion among certification authorities, application developers, 179 and protocol designers. 181 Therefore, to codify best current practices regarding the 182 implementation and deployment of secure PKIX-based authentication, 183 this document specifies recommended procedures for representing and 184 verifying application service identity in certificates intended for 185 use in application protocols employing TLS. 187 1.2. Applicability and Audience 189 This document does not supersede the rules for certificate issuance 190 or validation provided in [PKIX]. Therefore, [PKIX] is authoritative 191 on any point that might also be discussed in this document. 192 Furthermore, [PKIX] also governs any certificate-related topic on 193 which this document is silent, including but limited to certificate 194 syntax, certificate extensions such as name constraints and extended 195 key usage, and handling of certification paths. 197 This document addresses only name forms in the leaf "end entity" 198 server certificate, not any name forms in the chain of certificates 199 used to validate the server certificate. Therefore, in order to 200 ensure proper authentication, application clients need to verify the 201 entire certification path per [PKIX]. 203 This document also does not supersede the rules for verifying service 204 identity provided in specifications for existing application 205 protocols published prior to this BCP, such as those excerpted under 206 Appendix A. However, the best current practices described here can 207 be referenced by future specifications, including updates to 208 specifications for existing application protocols if the relevant 209 technology communities agree to do so. It is also expected that this 210 document will be updated or obsoleted in the future as best practices 211 for issuance and verification of PKIX certificates continue to evolve 212 through more widespread implementation and deployment of TLS- 213 protected application services over the Internet. 215 The primary audience for this document consists of application 216 protocol designers, who can reference this document instead of 217 defining their own rules for the representation and verification of 218 application service identity. Secondarily, the audience consists of 219 certification authorities, client developers, service providers, and 220 other members of technology communities that can re-use the 221 recommendations in this document when defining certificate issuance 222 policies, writing software algorithms for identity matching, 223 generating certificate signing requests, and so forth. 225 1.3. Overview of Recommendations 227 To orient the reader, this section provides an informational overview 228 of the recommendations contained in this document. 230 For the primary audience of application protocol designers, based on 231 best current practices this document provides recommended procedures 232 for the representation and verification of application service 233 identity within PKIX certificates used in the context of TLS. 235 For the secondary audiences, in essence this document encourages 236 certification authorities, application service providers, and 237 application client developers to coalesce on the following best 238 current practices: 240 o Move away from including and checking strings that look like 241 domain names in the subject's Common Name. 243 o Move toward including and checking DNS domain names via the 244 subjectAlternativeName extension designed for that purpose: 245 dNSName. 247 o Move toward including and checking even more specific 248 subjectAlternativeName extensions where appropriate for the using 249 protocol (e.g., uniformResourceIdentifier and the otherName form 250 SRVName). 252 o Move away from the issuance of so-called wildcard certificates 253 (e.g., a certificate containing an identifier for 254 "*.example.com"). 256 These suggestions are not entirely consistent with all practices that 257 are currently followed by certification authorities, client 258 developers, and service providers. However, they reflect the best 259 aspects of current practices and are expected to become more widely 260 adopted in the coming years. 262 1.4. Scope 264 1.4.1. In Scope 266 This document applies only to service identities associated with 267 fully-qualified DNS domain names, only to TLS and DTLS (or the older 268 Secure Sockets Layer (SSL) technology), and only to PKIX-based 269 systems. As a result, the scenarios described in the following 270 section are out of scope for this specification (although they might 271 be addressed by future specifications). 273 1.4.2. Out of Scope 275 The following topics are out of scope for this specification: 277 o Client or end-user identities. 279 Certificates representing client or end-user identities (e.g., the 280 rfc822Name identifier) can be used for mutual authentication 281 between a client and server or between two clients, thus enabling 282 stronger client-server security or end-to-end security. However, 283 certification authorities, application developers, and service 284 operators have less experience with client certificates than with 285 server certificates, thus giving us fewer models from which to 286 generalize and a less solid basis for defining best practices. 288 o Identifiers other than fully-qualified DNS domain names. 290 Some certification authorities issue server certificates based on 291 IP addresses, but preliminary evidence indicates that such 292 certificates are a very small percentage (less than 1%) of issued 293 certificates. Furthermore, IP addresses are not necessarily 294 reliable identifiers for application services because of the 295 existence of private internets [PRIVATE], host mobility, multiple 296 interfaces on a given host, Network Address Translators (NATs) 297 resulting in different addresses for a host from different 298 locations on the network, the practice of grouping many hosts 299 together behind a single IP address, etc. Most fundamentally, 300 most users find DNS domain names much easier to work with than IP 301 addresses, which is why the domain name system was designed in the 302 first place. We prefer to define best practices for the much more 303 common use case and not to complicate the rules in this 304 specification. 306 Furthermore, we focus here on application service identities, not 307 specific resources located at such services. Therefore this 308 document discusses Uniform Resource Identifiers [URI] only as a 309 way to communicate a DNS domain name (via the URI "authority" 310 component), not as a way to communicate other aspects of a service 311 such as a specific resource (via the URI "path" component) or 312 parameters (via the URI "query" component). 314 We also do not discuss attributes unrelated to DNS domain names, 315 such as those defined in [X.520] and other such specifications 316 (e.g., organizational attributes, geographical attributes, company 317 logos, and the like). 319 o Security protocols other than [TLS], [DTLS], or the older Secure 320 Sockets Layer (SSL) technology. 322 Although other secure, lower-layer protocols exist and even employ 323 PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases 324 can differ from those of TLS-based and DTLS-based application 325 technologies. Furthermore, application technologies have less 326 experience with IPsec than with TLS, thus making it more difficult 327 to gather feedback on proposed best practices. 329 o Keys or certificates employed outside the context of PKIX-based 330 systems. 332 Some deployed application technologies use a web of trust model 333 based on or similar to OpenPGP [OPENPGP], or use self-signed 334 certificates, or are deployed on networks that are not directly 335 connected to the public Internet and therefore cannot depend on 336 Certificate Revocation Lists (CRLs) or the Online Certificate 337 Status Protocol [OCSP] to check CA-issued certificates. However, 338 the method for binding a public key to an identifier in OpenPGP 339 differs essentially from the method in X.509, the data in self- 340 signed certificates has not been certified by a third party in any 341 way, and checking of CA-issued certificates via CRLs or OSCP is 342 critically important to maintaining the security of PKIX-based 343 systems. Attempting to define best practices for such 344 technologies would unduly complicate the rules defined in this 345 specification. 347 o Certification authority policies, such as: 349 * What types or "classes" of certificates to issue and whether to 350 apply different policies for them (e.g., allow the wildcard 351 character in certificates issued to individuals who have 352 provided proof of identity but do not allow the wildcard 353 character in "Extended Validation" certificates [EV-CERTS]). 355 * Whether to issue certificates based on IP addresses (or some 356 other form, such as relative domain names) in addition to 357 fully-qualified DNS domain names. 359 * Which identifiers to include (e.g., whether to include SRV-IDs 360 or URI-IDs as defined in the body of this specification). 362 * How to certify or validate fully-qualified DNS domain names and 363 application service types. 365 * How to certify or validate other kinds of information that 366 might be included in a certificate (e.g., organization name). 368 o Resolution of DNS domain names. 370 Although the process whereby a client resolves the DNS domain name 371 of an application service can involve several steps (e.g., this is 372 true of resolutions that depend on DNS SRV resource records, 373 Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and 374 related technologies such as [S-NAPTR]), for our purposes we care 375 only about the fact that the client needs to verify the identity 376 of the entity with which it communicates as a result of the 377 resolution process. Thus the resolution process itself is out of 378 scope for this specification. 380 o User interface issues. 382 In general, such issues are properly the responsibility of client 383 software developers and standards development organizations 384 dedicated to particular application technologies (see for example 385 [WSC-UI]). 387 1.5. Terminology 389 Because many concepts related to "identity" are often too vague to be 390 actionable in application protocols, we define a set of more concrete 391 terms for use in this specification. 393 application service: A service on the Internet that enables 394 interactive and automated clients to connect for the purpose of 395 retrieving or uploading information, communicating with other 396 entities, or connecting to a broader network of services. 398 application service provider: An organization or individual that 399 hosts or deploys an application service. 401 attribute-type-and-value pair: A colloquial name for the ASN.1-based 402 construction comprising a Relative Distinguished Name (RDN), which 403 itself is a building-block component of Distinguished Names. See 404 Section 2 of [LDAP-DN]. 406 automated client: A software agent or device that is not directly 407 controlled by a human user. 409 delegated domain: A domain name or host name that is explicitly 410 configured for communicating with the source domain, by either (a) 411 the human user controlling an interactive client or (b) a trusted 412 administrator. In case (a), one example of delegation is an 413 account setup that specifies the domain name of a particular host 414 to be used for retrieving information or connecting to a network, 415 which might be different from the server portion of the user's 416 account name (e.g., a server at mailhost.example.com for 417 connecting to an IMAP server hosting an email address of 418 juliet@example.com). In case (b), one example of delegation is an 419 admin-configured host-to-address/address-to-host lookup table. 421 derived domain: A domain name or host name that a client has derived 422 from the source domain in an automated fashion (e.g., by means of 423 a [DNS-SRV] lookup). 425 identifier: A particular instance of an identifier type that is 426 either presented by a server in a certificate or referenced by a 427 client for matching purposes. 429 identifier type: A formally defined category of identifier that can 430 be included in a certificate and therefore that can also be used 431 for matching purposes. For conciseness and convenience, we define 432 the following identifier types of interest, which are based on 433 those found in the PKIX specification [PKIX] and various PKIX 434 extensions. 436 * CN-ID = a Relative Distinguished Name (RDN) in the certificate 437 subject field that contains one and only one attribute-type- 438 and-value pair of type Common Name (CN), where the value 439 matches the overall form of a domain name (informally, dot- 440 separated letter-digit-hyphen labels); see [PKIX] and also 441 [LDAP-SCHEMA] 443 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 445 * SRV-ID = a subjectAltName entry of type otherName whose name 446 form is SRVName; see [SRVNAME] 448 * URI-ID = a subjectAltName entry of type 449 uniformResourceIdentifier whose value includes both (i) a 450 "scheme" and (ii) an "authority" component whose "host" 451 subcomponent matches the "reg-name" rule (where the quoted 452 terms represent the associated [ABNF] productions from [URI]); 453 see [PKIX] and [URI] 455 interactive client: A software agent or device that is directly 456 controlled by a human user. (Other specifications related to 457 security and application protocols, such as [WSC-UI], often refer 458 to this entity as a "user agent". 460 pinning: The act of establishing a cached name association between 461 the application service's certificate and one of the client's 462 reference identifiers, despite the fact that none of the presented 463 identifiers matches the given reference identifier. Pinning is 464 accomplished by allowing a human user to positively accept the 465 mismatch during an attempt to communicate with the application 466 service. Once a cached name association is established, the 467 certificate is said to be pinned to the reference identifier and 468 in future communication attempts the client simply verifies that 469 the service's presented certificate matches the pinned 470 certificate, as described under Section 4.6.2. (A similar 471 definition of "pinning" is provided in [WSC-UI].) 473 PKIX: PKIX is a short name for the Internet Public Key 474 Infrastructure using X.509 defined in RFC 5280 [PKIX], which 475 comprises a profile of the X.509v3 certificate specifications and 476 X.509v2 certificate revocation list (CRL) specifications for use 477 in the Internet. 479 PKIX-based system: A software implementation or deployed service 480 that makes use of X.509v3 certificates and X.509v2 certificate 481 revocation lists (CRLs). 483 PKIX certificate: An X.509v3 certificate generated and employed in 484 the context of PKIX. 486 presented identifier: An identifier that is presented by a server to 487 a client within a PKIX certificate when the client attempts to 488 establish secure communication with the server; the certificate 489 can include one or more presented identifiers of different types, 490 and if the server hosts more than one domain then the certificate 491 might present distinct identifiers for each domain. 493 reference identifier: An identifier, constructed from a source 494 domain and optionally a service type, used by the client for 495 matching purposes when examining presented identifiers. 497 service type: A formal identifier for the application protocol used 498 to provide a particular kind of service at a domain; the service 499 type typically takes the form of a Uniform Resource Identifier 500 scheme [URI] or a DNS SRV Service [DNS-SRV]. 502 source domain: The fully-qualified DNS domain name that a client 503 expects an application service to present in the certificate 504 (e.g., "www.example.com"), typically input by a human user, 505 configured into a client, or provided by reference such as in a 506 hyperlink. The combination of a source domain and, optionally, a 507 service type enables a client to construct one or more reference 508 identifiers. 510 subjectAltName entry: An identifier placed in a subjectAltName 511 extension. 513 subjectAltName extension: A standard PKIX certificate extension 514 [PKIX] enabling identifiers of various types to be bound to the 515 certificate subject -- in addition to, or in place of, identifiers 516 that may be embedded within or provided as a certificate's subject 517 field. 519 subject field: The subject field of a PKIX certificate identifies 520 the entity associated with the public key stored in the subject 521 public key field (see Section 4.1.2.6 of [PKIX]). 523 subject name: In an overall sense, a subject's name(s) can be 524 represented by or in the subject field, the subjectAltName 525 extension, or both (see [PKIX] for details). More specifically, 526 the term often refers to the name of a PKIX certificate's subject, 527 encoded as the X.501 type Name and conveyed in a certificate's 528 subject field (see Section 4.1.2.6 of [PKIX]). 530 TLS client: An entity that assumes the role of a client in a 531 Transport Layer Security [TLS] negotiation; in this specification 532 we generally assume that the TLS client is an (interactive or 533 automated) application client, however in application protocols 534 that enable server-to-server communication the TLS client could be 535 a peer application service. 537 TLS server: An entity that assumes the role of a server in a 538 Transport Layer Security [TLS] negotiation; in this specfication 539 we assume that the TLS server is an application service. 541 Most security-related terms in this document are to be understood in 542 the sense defined in [SECTERMS]; such terms include, but are not 543 limited to, "attack", "authentication", "authorization", 544 "certification authority", "certification path", "certificate", 545 "credential", "identity", "self-signed certificate", "trust", "trust 546 anchor", "trust chain", "validate", and "verify". 548 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 549 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 550 "OPTIONAL" in this document are to be interpreted as described in 551 [KEYWORDS]. 553 2. Names 555 This section discusses naming of application services on the 556 Internet, followed by a brief tutorial about subject naming in PKIX. 558 2.1. Naming Application Services 560 This specification assumes that the name of an application service is 561 based on a DNS domain name (e.g., "example.com") -- supplemented in 562 some circumstances by a service type (e.g., "the IMAP server at 563 example.com"). 565 From the perspective of the application client or user, some names 566 are direct because they are provided directly by a human user (e.g., 567 via runtime input, prior configuration, or explicit acceptance of a 568 client communication attempt) whereas other names are indirect 569 because they are automatically resolved by the client based on user 570 input (e.g., a target name resolved from a source name using DNS SRV 571 or NAPTR records). This dimension matters most for certificate 572 consumption, specifically verification as discussed in this document. 574 From the perspective of the application service, some names are 575 unrestricted because they can be used in any type of service (e.g., a 576 certificate might be re-used for both the HTTP service and the IMAP 577 service at example.com) whereas other names are restricted because 578 they can be used in only one type of service (e.g., a special-purpose 579 certificate that can be used only for an IMAP service). This 580 dimension matters most for certificate issuance. 582 Therefore we can categorize the identifier types of interest as 583 follows: 585 o A CN-ID is direct and unrestricted. 587 o A DNS-ID is direct and unrestricted. 589 o An SRV-ID can be either direct or (more typically) indirect, and 590 is restricted. 592 o A URI-ID is direct and restricted. 594 We summarize this taxonomy in the following table. 596 +-----------+-----------+---------------+ 597 | | Direct | Restricted | 598 +-----------+-----------+---------------+ 599 | CN-ID | Yes | No | 600 +-----------+-----------+---------------+ 601 | DNS-ID | Yes | No | 602 +-----------+-----------+---------------+ 603 | SRV-ID | Either | Yes | 604 +-----------+-----------+---------------+ 605 | URI-ID | Yes | Yes | 606 +-----------+-----------+---------------+ 608 When implementing software, deploying services, and issuing 609 certificates for secure PKIX-based authentication, it is important to 610 keep these distinctions in mind. In particular, best practices 611 differ somewhat for application server implementations, application 612 client implementations, application service providers, and 613 certification authorities. Ideally, protocol specifications that 614 reference this document will specify which identifiers are mandatory- 615 to-implement by servers and clients, which identifiers ought to be 616 supported by certificate issuers, and which identifiers ought to be 617 requested by application service providers. Because these 618 requirements differ across applications, it is impossible to 619 categorically stipulate universal rules (e.g., that all software 620 implementations, service providers, and certification authorities for 621 all application protocols need to use or support DNS-IDs as a 622 baseline for the purpose of interoperability). 624 However, it is preferable that each application protocol will at 625 least define a baseline that applies to the community of software 626 developers, application service providers, and CAs actively using or 627 supporting that technology (one such community, the CA/Browser Forum, 628 has codified such a baseline for "Extended Validation Certificates" 629 in [EV-CERTS]). 631 2.2. DNS Domain Names 633 For the purposes of this specification, the name of an application 634 service is (or is based on) a DNS domain name that conforms to one of 635 the following forms: 637 1. A "traditional domain name", i.e., a fully-qualified DNS domain 638 name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 639 labels" as described in [IDNA-DEFS]. Informally, such labels are 640 constrained to [US-ASCII] letters, digits, and the hyphen, with 641 the hyphen prohibited in the first character position. 642 Additional qualifications apply (please refer to the above- 643 referenced specifications for details) but they are not relevant 644 to this specification. 646 2. An "internationalized domain name", i.e., a DNS domain name that 647 conforms to the overall form of a domain name (informally, dot- 648 separated letter-digit-hyphen labels) but includes at least one 649 label containing appropriately encoded Unicode code points 650 outside the traditional US-ASCII range. That is, it contains at 651 least one U-label or A-label, but otherwise may contain any 652 mixture of NR-LDH labels, A-labels, or U-labels, as described in 653 [IDNA-DEFS] and the associated documents). 655 2.3. Subject Naming in PKIX Certificates 657 In theory, the Internet Public Key Infrastructure using X.509 [PKIX] 658 employs the global directory service model defined in [X.500] and 659 [X.501]. Under that model, information is held in a directory 660 information base (DIB) and entries in the DIB are organized in a 661 hierarchy called the directory information tree (DIT). An object or 662 alias entry in that hierarchy consists of a set of attributes (each 663 of which has a defined type and one or more values) and is uniquely 664 identified by a Distinguished Name (DN). The DN of an entry is 665 constructed by combining the Relative Distinguished Names of its 666 superior entries in the tree (all the way down to the root of the 667 DIT) with one or more specially-nominated attributes of the entry 668 itself (which together comprise the Relative Distinguished Name (RDN) 669 of the entry, so-called because it is relative to the Distinguished 670 Names of the superior entries in the tree). The entry closest to the 671 root is sometimes referred to as the "most significant" entry and the 672 entry farthest from the root is sometimes referred to as the "least 673 significant" entry. An RDN is a set (i.e., an unordered group) of 674 attribute-type-and-value pairs (see also [LDAP-DN]), each of which 675 asserts some attribute about the entry. 677 In practice, the certificates used in [X.509] and [PKIX] borrow key 678 concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify 679 entities, but such certificates are not necessarily part of a global 680 directory information base. Specifically, the subject field of a 681 PKIX certificate is an X.501 type Name that "identifies the entity 682 associated with the public key stored in the subject public key 683 field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly 684 acceptable for the subject field to be empty, as long as the 685 certificate contains a subject alternative name ("subjectAltName") 686 extension that includes at least one subjectAltName entry, because 687 the subjectAltName extension allows various identities to be bound to 688 the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName 689 extension itself is a sequence of typed entries, where each type is a 690 distinct kind of identifier. 692 For our purposes, an application service can be identified by a name 693 or names carried in the subject field (i.e., a CN-ID) and/or in one 694 of the following identifier types within subjectAltName entries: 696 o DNS-ID 697 o SRV-ID 698 o URI-ID 700 Existing certificates often use a CN-ID in the subject field to 701 represent a fully-qualified DNS domain name; for example, consider 702 the following three subject names, where the attribute of type Common 703 Name contains a string whose form matches that of a fully-qualified 704 DNS domain name ("im.example.org", "mail.example.net", and 705 "www.example.com" respectively): 707 CN=im.example.org,O=Example Org,C=GB 709 C=CA,O=Example Internetworking,CN=mail.example.net 711 O=Examples-R-Us,CN=www.example.com,C=US 713 However, a Common Name might contain a human-friendly string for the 714 service, rather than a string whose form matches that of a fully- 715 qualified DNS domain name (a certificate with such a single Common 716 Name will tyupically have at least one subjectAltName entry 717 containing the fully-qualified DNS domain name): 719 CN=A Free Chat Service,O=Example Org,C=GB 721 Or, a certificate's subject might contain both a CN-ID as well as 722 another common name attribute containing a human-friendly string: 724 CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB 726 In general, this specification recommends and prefers use of 727 subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the 728 subject field (CN-ID) where possible, as more completely described in 729 the following sections. However, specifications that re-use this one 730 can legitimately encourage continued support for the CN-ID identifier 731 type if they have good reasons to do so, such as backward 732 compatibility with deployed infrastructure (see, for example, 733 [EV-CERTS]). 735 2.3.1. Implementation Notes 737 Confusion sometimes arises from different renderings or encodings of 738 the hierarchical information contained in a certificate. 740 Certificates are binary objects and are encoded using the 741 Distinguished Encoding Rules (DER) specified in [X.690]. However, 742 some implementations generate displayable (a.k.a. printable) 743 renderings of the certificate issuer, subject field, and 744 subjectAltName extension, and these renderings convert the DER- 745 encoded sequences into a "string representation" before being 746 displayed. Because a certificate subject field (of type Name 747 [X.509], the same as for a Distinguished Name (DN) [X.501]) is an 748 ordered sequence, order is typically preserved in subject string 749 representations, although the two most prevalent subject (and DN) 750 string representations differ in employing left-to-right vs. right- 751 to-left ordering. However, because a Relative Distinguished Name 752 (RDN) is an unordered group of attribute-type-and-value pairs, the 753 string representation of an RDN can differ from the canonical DER 754 encoding (and the order of attribute-type-and-value pairs can differ 755 in the RDN string representations or display orders provided by 756 various implementations). Furthermore, various specifications refer 757 to the order of RDNs in DNs or certificate subject fields using 758 terminology that is implicitly related to an information hierarchy 759 (which may or may not actually exist), such as "most specific" vs. 760 "least specific", "left-most" vs. "right-most", "first" vs. "last", 761 or "most significant" vs. "least significant" (see for example 762 [LDAP-DN]). 764 To reduce confusion, in this specification we avoid such terms and 765 instead use the terms provided under Section 1.5; in particular, we 766 do not use the term "(most specific) Common Name field in the subject 767 field" from [HTTP-TLS] and instead state that a CN-ID is a Relative 768 Distinguished Name (RDN) in the certificate subject containing one 769 and only one attribute-type-and-value pair of type Common Name (thus 770 removing the possibility that an RDN might contain multiple AVAs of 771 type CN, one of which could be considered "most specific"). 773 Finally, although theoretically some consider the order of RDNs 774 within a subject field to have meaning, in practice that rule is 775 often not observed. An AVA of type CN is considered to be valid at 776 any position within the subject field. 778 3. Representation of Server Identity 780 3.1. Rules 782 When a certification authority issues a certificate based on the 783 fully-qualified DNS domain name at which the application service 784 provider will provide the relevant application, the following rules 785 apply to the representation of application service identities. The 786 reader needs to be aware that some of these rules are cumulative and 787 can interact in important ways that are illustrated later in this 788 document. 790 1. The certificate SHOULD include a "DNS-ID" if possible as a 791 baseline for interoperability. 793 2. If the service using the certificate deploys a technology in 794 which a server is discovered by means of DNS SRV records 795 [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate 796 SHOULD include an "SRV-ID". 798 3. If the service using the certificate deploys a technology in 799 which a server is programatically associated with a URI for 800 security purposes (e.g., this is true of [SIP] as specified by 801 [SIP-CERTS], but not true of [HTTP] since [HTTP-TLS] does not 802 describe usage of a URI-ID for HTTP services), then the 803 certificate SHOULD include a URI-ID; the scheme SHALL be that of 804 the protocol associated with the service type and the "authority" 805 component SHALL be the fully-qualified DNS domain name of the 806 service. A specification that re-uses this one MUST specify 807 which URI schemes are to be considered acceptable in URI-IDs 808 contained in PKIX certificates used for the application protocol 809 (e.g., "sip" but not "sips" or "tel" for SIP as described in 810 [SIP-SIPS], or perhaps http and https for HTTP as might be 811 described in a future specification). 813 4. The certificate MAY include other application-specific 814 identifiers for types that were defined before publication of 815 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names 816 or URI schemes do not exist; however, such application-specific 817 identifiers are not applicable to all application technologies 818 and therefore are out of scope for this specification. 820 5. Even though many deployed clients still check for the CN-ID 821 within the certificate subject field, the certificate SHOULD NOT 822 represent the server's fully-qualified DNS domain name in a CN-ID 823 unless a specification that re-uses this one encourages continued 824 support for the CN-ID identifier type. 826 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or 827 URI-ID but SHOULD NOT contain more than one CN-ID, as further 828 explained under Section 5.4. 830 7. Unless a specification that re-uses this one allows continued 831 support for the wildcard character '*', the DNS domain name 832 portion of a presented identifier SHOULD NOT contain the wildcard 833 character, whether as the complete left-most label within the 834 identifier (following the definition of "label" from [DNS], e.g., 835 "*.example.com") or as a fragment thereof (e.g., *oo.example.com, 836 f*o.example.com, or foo*.example.com). A more detailed 837 discussion of so-called "wildcard certificates" is provided under 838 Section 5.2. 840 3.2. Examples 842 Consider a simple website at "www.example.com", which is not 843 discoverable via DNS SRV lookups. A certificate for this service 844 might include only a DNS-ID of "www.example.com". 846 Consider an IMAP-accessible email server at "mail.example.net" 847 servicing email addresses of the form "user@example.net" and 848 discoverable via DNS SRV lookups on the "example.net" domain. A 849 certificate for this service might include SRV-IDs of 850 "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along 851 with a DNS-ID of "example.net". 853 Consider a SIP-accessible voice-over-IP (VoIP) server at 854 "voice.example.edu" servicing SIP addresses of the form 855 "user@voice.example.edu" and identified by a URI of . A certificate for this service would include a 857 URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 859 Consider an XMPP-compatible instant messaging (IM) server at 860 "im.example.org" servicing IM addresses of the form 861 "user@im.example.org" and discoverable via DNS SRV lookups on the 862 "im.example.org" domain. A certificate for this service might 863 include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- 864 server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", 865 and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). 867 4. Verification of Service Identity 869 4.1. Overview 871 At a high level, the client verifies the application service's 872 identity by performing the actions listed below (which are defined in 873 the following subsections of this document): 875 1. The client constructs a list of acceptable reference identifiers 876 based on the source domain and, optionally, the type of service 877 to which the client is connecting. 879 2. The server provides its identifiers in the form of a PKIX 880 certificate. 882 3. The client checks each of its reference identifiers against the 883 presented identifiers for the purpose of finding a match. 885 4. When checking a reference identifier against a presented 886 identifier, the client matches the source domain of the 887 identifiers and, optionally, their service type. 889 Naturally, in addition to checking identifiers, a client might 890 complete further checks to ensure that the server is authorized to 891 provide the requested service. However, such checking is not a 892 matter of verifying the application service identity presented in a 893 certificate, and therefore methods for doing so (e.g., consulting 894 local policy information) are out of scope for this document. 896 4.2. Constructing a List of Reference Identifiers 898 4.2.1. Rules 900 The client MUST construct a list of acceptable reference identifiers, 901 and MUST do so independently of the identifiers presented by the 902 service. 904 The inputs used by the client to construct its list of reference 905 identifiers might be a URI that a user has typed into an interface 906 (e.g., an HTTPS URL for a web site), configured account information 907 (e.g., the domain name of a particular host or URI used for 908 retrieving information or connecting to a network, which might be 909 different from the DNS domain name portion of a username), a 910 hyperlink in a web page that triggers a browser to retrieve a media 911 object or script, or some other combination of information that can 912 yield a source domain and a service type. 914 The client might need to extract the source domain and service type 915 from the input(s) it has received. The extracted data MUST include 916 only information that can be securely parsed out of the inputs (e.g., 917 parsing the fully-qualified DNS domain name out of the "authority" 918 component of a URI or deriving the service type from the scheme of a 919 URI) or information that is derived in a manner not subject to 920 subversion by network attackers (e.g., pulling the data from a 921 delegated domain that is explicitly established via client or system 922 configuration, resolving the data via [DNSSEC], or obtaining the data 923 from a third-party domain mapping service in which a human user has 924 explicitly placed trust and with which the client communicates over a 925 connection or association that provides both mutual authentication 926 and integrity checking). These considerations apply only to 927 extraction of the source domain from the inputs; naturally, if the 928 inputs themselves are invalid or corrupt (e.g., a user has clicked a 929 link provided by a malicious entity in a phishing attack), then the 930 client might end up communicating with an unexpected application 931 service. 933 Example: Given an input URI of , a client 934 would derive the service type "sip" from the "scheme" and parse 935 the domain name "example.net" from the "authority" component. 937 Each reference identifier in the list SHOULD be based on the source 938 domain and SHOULD NOT be based on a derived domain (e.g., a host name 939 or domain name discovered through DNS resolution of the source 940 domain). This rule is important because only a match between the 941 user inputs and a presented identifier enables the client to be sure 942 that the certificate can legitimately be used to secure the client's 943 communication with the server. There is only one scenario in which 944 it is acceptable for an interactive client to override the 945 recommendation in this rule and therefore communicate with a domain 946 name other than the source domain: because a human user has "pinned" 947 the application service's certificate to the alternative domain name 948 as further discussed under Section 4.6.4 and Section 5.1. In this 949 case, the inputs used by the client to construct its list of 950 reference identifiers might include more than one fully-qualified DNS 951 domain name, i.e., both (a) the source domain and (b) the alternative 952 domain contained in the pinned certificate. 954 Using the combination of fully-qualified DNS domain name(s) and 955 service type, the client constructs a list of reference identifiers 956 in accordance with the following rules: 958 o The list MUST include a DNS-ID. A reference identifier of type 959 DNS-ID can be directly constructed from a fully-qualified DNS 960 domain name that is (a) contained in or securely derived from the 961 inputs (i.e., the source domain), or (b) explicitly associated 962 with the source domain by means of user configuration (i.e., a 963 derived domain). 965 o If a server for the service type is typically discovered by means 966 of DNS SRV records, then the list SHOULD include an SRV-ID. 968 o If a server for the service type is typically associated with a 969 URI for security purposes, then the list SHOULD include a URI-ID. 971 o The list MAY include a CN-ID, mainly for the sake of backward 972 compatibility with deployed infrastructure. 974 The client does not need to construct the foregoing identifiers in 975 the actual formats found in a certificate (e.g., as ASN.1 types); it 976 only needs to construct the functional equivalent of such identifiers 977 for matching purposes. 979 Security Warning: A client MUST NOT construct a reference 980 identifier corresponding to Relative Distinguished Names (RDNs) 981 other than those of type Common Name and MUST NOT check for RDNs 982 other than those of type Common Name in the presented identifiers. 984 4.2.2. Examples 986 A web browser that is connecting via HTTPS to the website at 987 "www.example.com" might have two reference identifiers: a DNS-ID of 988 "www.example.com" and, as a fallback, a CN-ID of "www.example.com". 990 A mail user agent that is connecting via IMAP to the email service at 991 "example.net" (resolved as "mail.example.net") might have two 992 reference identifiers: an SRV-ID of "_imaps.example.net" (see 993 [EMAIL-SRV]) and a DNS-ID of "example.net". 995 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 996 voice service at "voice.example.edu" might have only one reference 997 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 999 An instant messaging (IM) client that is connecting via XMPP to the 1000 IM service at "im.example.org" might have three reference 1001 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), 1002 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of 1003 "im.example.org" (see [XMPP]). 1005 4.3. Preparing to Seek a Match 1007 Once the client has constructed its list of reference identifiers and 1008 has received the server's presented identifiers in the form of a PKIX 1009 certificate, the client checks its reference identifiers against the 1010 presented identifiers for the purpose of finding a match. The search 1011 fails if the client exhausts its list of reference identifiers 1012 without finding a match. The search succeeds if any presented 1013 identifier matches one of the reference identifiers, at which point 1014 the client SHOULD stop the search. 1016 Implementation Note: A client might be configured to perform 1017 multiple searches, i.e., to match more than one reference 1018 identifier; although such behavior is not forbidden by this 1019 specification, rules for matching multiple reference identifiers 1020 are a matter for implementation or future specification. 1022 Security Warning: A client MUST NOT seek a match for a reference 1023 identifier of CN-ID if the presented identifiers include a DNS-ID, 1024 SRV-ID, URI-ID, or any application-specific identifier types 1025 supported by the client. 1027 Before applying the comparison rules provided in the following 1028 sections, the client might need to split the reference identifier 1029 into its DNS domain name portion and its service type portion, as 1030 follows: 1032 o A reference identifier of type DNS-ID does not include a service 1033 type portion and thus can be used directly as the DNS domain name 1034 for comparison purposes. As an example, a DNS-ID of 1035 "www.example.com" would result in a DNS domain name portion of 1036 "www.example.com". 1038 o A reference identifier of type CN-ID also does not include a 1039 service type portion and thus can be used directly as the DNS 1040 domain name for comparison purposes. As previously mentioned, 1041 this document specifies that a CN-ID always contains a string 1042 whose form matches that of a DNS domain name (thus differentiating 1043 a CN-ID from a Common Name containing a human-friendly name). 1045 o For a reference identifier of type SRV-ID, the DNS domain name 1046 portion is the Name and the service type portion is the Service. 1047 As an example, an SRV-ID of "_imaps.example.net" would be split 1048 into a DNS domain name portion of "example.net" and a service type 1049 portion of "imaps" (mapping to an application protocol of IMAP as 1050 explained in [EMAIL-SRV]). 1052 o For a reference identifier of type URI-ID, the DNS domain name 1053 portion is the "reg-name" part of the "authority" component and 1054 the service type portion is the service type associated with the 1055 scheme name matching the [ABNF] "scheme" rule from [URI] (not 1056 including the ':' separator). As previously mentioned, this 1057 document specifies that a URI-ID always contains an "authority" 1058 component whose "host" subcomponent contains a "reg-name". 1060 (Matching only the "reg-name" rule from [URI] limits verification 1061 to DNS domain names, thereby differentiating a URI-ID from a 1062 uniformResourceIdentifier entry that contains an IP address or a 1063 mere host name, or that does not contain an "authority" component 1064 at all.). Furthermore, note that extraction of the "reg-name" 1065 might necessitate normalization of the URI (as explained in 1066 [URI]). As an example, a URI-ID of "sip:voice.example.edu" would 1067 be split into a DNS domain name portion of "voice.example.edu" and 1068 a service type of "sip" (associated with an application protocol 1069 of SIP as explained in [SIP-CERTS]). 1071 Detailed comparison rules for matching the DNS domain name portion 1072 and service type portion of the reference identifier are provided in 1073 the following sections. 1075 4.4. Matching the DNS Domain Name Portion 1077 The client MUST match the DNS domain name portion of a reference 1078 identifier according to the following rules (and SHOULD also check 1079 the service type as described under Section 4.5). The rules differ 1080 depending on whether the domain to be checked is a "traditional 1081 domain name" or an "internationalized domain name" (as defined under 1082 Section 2.2). Furthermore, to meet the needs of clients that support 1083 presented identifiers containing the wildcard character '*', we 1084 define a supplemental rule for so-called "wildcard certificates". 1085 Finally, we also specify the circumstances under which it is 1086 acceptable to check the "CN-ID" identifier type. 1088 4.4.1. Checking of Traditional Domain Names 1090 If the DNS domain name portion of a reference identifier is a 1091 "traditional domain name", then matching of the reference identifier 1092 against the presented identifier is performed by comparing the set of 1093 domain name labels using a case-insensitive ASCII comparison, as 1094 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 1095 to "www.example.com" for comparison purposes). Each label MUST match 1096 in order for the names to be considered to match, except as 1097 supplemented by the rule about checking of wildcard labels 1098 (Section 4.4.3). 1100 4.4.2. Checking of Internationalized Domain Names 1102 If the DNS domain name portion of a reference identifier is an 1103 internationalized domain name, then an implementation MUST convert 1104 any U-labels [IDNA-DEFS] in the domain name to A-labels before 1105 checking the domain name. In accordance with [IDNA-PROTO], A-labels 1106 MUST be compared as case-insensitive ASCII. Each label MUST match in 1107 order for the domain names to be considered to match, except as 1108 supplemented by the rule about checking of wildcard labels 1109 (Section 4.4.3; but see also Section 5.2 regarding wildcards in 1110 internationalized domain names). 1112 4.4.3. Checking of Wildcard Certificates 1114 A client employing this specification's rules MAY match the reference 1115 identifier against a presented identifier whose DNS domain name 1116 portion contains the wildcard character '*' as part or all of a label 1117 (following the definition of "label" from [DNS-CONCEPTS]). 1119 For information regarding the security characteristics of wildcard 1120 certificates, see Section 5.2. 1122 If a client matches the reference identifier against a presented 1123 identifier whose DNS domain name portion contains the wildcard 1124 character '*', the following rules apply: 1126 1. The client SHOULD NOT attempt to match a presented identifier in 1127 which the wildcard character comprises a label other than the 1128 left-most label (e.g., do not match bar.*.example.net). 1130 2. If the wildcard character is the only character of the left-most 1131 label in the presented identifier, the client SHOULD NOT compare 1132 against anything but the left-most label of the reference 1133 identifier (e.g., *.example.com would match foo.example.com but 1134 not bar.foo.example.com or example.com). 1136 3. The client MAY match a presented identifier in which the wildcard 1137 character is not the only character of the label (e.g., 1138 baz*.example.net and *baz.example.net and b*z.example.net would 1139 be taken to match baz1.example.net and foobaz.example.net and 1140 buzz.example.net, respectively). However, the client SHOULD NOT 1141 attempt to match a presented identifier where the wildcard 1142 character is embedded within an A-label or U-label [IDNA-DEFS] of 1143 an internationalized domain name [IDNA-PROTO]. 1145 4.4.4. Checking of Common Names 1147 As noted, a client MUST NOT seek a match for a reference identifier 1148 of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, 1149 URI-ID, or any application-specific identifier types supported by the 1150 client. 1152 Therefore, if and only if the presented identifiers do not include a 1153 DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types 1154 supported by the client, then the client MAY as a last resort check 1155 for a string whose form matches that of a fully-qualified DNS domain 1156 name in a Common Name field of the subject field (i.e., a CN-ID). If 1157 the client chooses to compare a reference identifier of type CN-ID 1158 against that string, it MUST follow the comparison rules for the DNS 1159 domain name portion of an identifier of type DNS-ID, SRV-ID, or 1160 URI-ID, as described under Section 4.4.1, Section 4.4.2, and 1161 Section 4.4.3. 1163 4.5. Matching the Application Type Portion 1165 When checking identifiers of type SRV-ID and URI-ID, a client SHOULD 1166 check not only the domain name but also the service type of the 1167 application service with which it communicates. This is a best 1168 practice because typically a client is not designed to communicate 1169 with all kinds of services using all possible application protocols, 1170 but instead is designed to communicate with one kind of service, such 1171 as websites, email services, VoIP services, or IM services. 1173 The service type is verified by means of an SRV-ID or a URI-ID. 1175 4.5.1. SRV-ID 1177 The service name portion of an SRV-ID (e.g., "imaps") MUST be matched 1178 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 1179 that the "_" character is prepended to the service identifier in DNS 1180 SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to 1181 be included in any comparison. 1183 4.5.2. URI-ID 1185 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1186 a case-insensitive manner, in accordance with [URI]. Note that the 1187 ":" character is a separator between the scheme name and the rest of 1188 the URI, and thus does not need to be included in any comparison. 1190 4.6. Outcome 1192 The outcome of the matching procedure is one of the following cases. 1194 4.6.1. Case #1: Match Found 1196 If the client has found a presented identifier that matches a 1197 reference identifier, then the service identity check has succeeded. 1198 In this case, the client MUST use the matched reference identifier as 1199 the validated identity of the application service. 1201 4.6.2. Case #2: No Match Found, Pinned Certificate 1203 If the client does not find a presented identifier matching any of 1204 the reference identifiers but the client has previously pinned the 1205 application service's certificate to one of the reference identifiers 1206 in the list it constructed for this communication attempt (as 1207 "pinning" is explained under Section 1.5), and the presented 1208 certificate matches the pinned certificate (including the context as 1209 described under Section 5.1), then the service identity check has 1210 succeeded. 1212 4.6.3. Case #3: No Match Found, No Pinned Certificate 1214 If the client does not find a presented identifier matching any of 1215 the reference identifiers and the client has not previously pinned 1216 the certificate to one of the reference identifiers in the list it 1217 constructed for this communication attempt, then the client MUST 1218 proceed as described under Section 4.6.4. 1220 4.6.4. Fallback 1222 If the client is an interactive client that is directly controlled by 1223 a human user, then it SHOULD inform the user of the identity mismatch 1224 and automatically terminate the communication attempt with a bad 1225 certificate error; this behavior is preferable because it prevents 1226 users from inadvertently bypassing security protections in hostile 1227 situations. 1229 Security Warning: Some interactive clients give advanced users the 1230 option of proceeding with acceptance despite the identity 1231 mismatch, thereby "pinning" the certificate to one of the 1232 reference identifiers in the list constructed by the client for 1233 this communication attempt. Although this behavior can be 1234 appropriate in certain specialized circumstances, in general it 1235 ought to be exposed only to advanced users. Even then it needs to 1236 be handled with extreme caution, for example by first encouraging 1237 even an advanced user to terminate the communication attempt and, 1238 if the advanced user chooses to proceed anyway, by forcing the 1239 user to view the entire certification path and only then allowing 1240 the user to pin the certificate (on a temporary or permanent 1241 basis, at the user's option). 1243 Otherwise, if the client is an automated application not directly 1244 controlled by a human user, then it SHOULD terminate the 1245 communication attempt with a bad certificate error and log the error 1246 appropriately. An automated application MAY provide a configuration 1247 setting that disables this behavior, but MUST enable the behavior by 1248 default. 1250 5. Security Considerations 1252 5.1. Pinned Certificates 1254 As defined under Section 1.5, a certificate is said to be "pinned" to 1255 a DNS domain name when a user has explicitly chosen to associate a 1256 service's certificate with that DNS domain name despite the fact that 1257 the certificate contains some other DNS domain name (e.g., the user 1258 has explicitly approved "apps.example.net" as a domain associated 1259 with a source domain of "example.com"). The cached name association 1260 MUST take account of both the certificate presented and the context 1261 in which it was accepted or configured (where the "context" includes 1262 the chain of certificates from the presented certificate to the trust 1263 anchor, the source domain, the service type, the service's derived 1264 domain and port number, and any other relevant information provided 1265 by the user or associated by the client). 1267 5.2. Wildcard Certificates 1269 This document states that the wildcard character '*' SHOULD NOT be 1270 included in presented identifiers but MAY be checked by application 1271 clients (mainly for the sake of backward compatibility with deployed 1272 infrastructure); as a result, the rules provided in this document are 1273 more restrictive than the rules for many existing application 1274 technologies (such as those excerpted under Appendix A). Several 1275 security considerations justify tightening the rules: 1277 o Wildcard certificates automatically vouch for any and all host 1278 names within their domain. This can be convenient for 1279 administrators but also poses the risk of vouching for rogue or 1280 buggy hosts. See for example [Defeating-SSL] (beginning at slide 1281 91) and [HTTPSbytes] (slides 38-40). 1283 o Specifications for existing application technologies are not clear 1284 or consistent about the allowable location of the wildcard 1285 character, such as whether it can be: 1287 * only the complete left-most label (e.g., *.example.com) 1289 * some fragment of the left-most label (e.g., foo*.example.com, 1290 f*o.example.com, or *oo.example.com) 1292 * all or part of a label other than the left-most label (e.g., 1293 www.*.example.com or www.foo*.example.com) 1295 * all or part of a label that identifies a so-called "public 1296 suffix" (e.g., *.co.uk or *.com) 1298 * included more than once in a given label (e.g., 1299 f*b*r.example.com 1301 * included as all or part of more than one label (e.g., 1302 *.*.example.com) 1304 These ambiguities might introduce exploitable differences in 1305 identity checking behavior among client implementations and 1306 necessitate overly complex and inefficient identity checking 1307 algorithms. 1309 o There is no specification that defines how the wildcard character 1310 may be embedded within the A-labels or U-labels [IDNA-DEFS] of an 1311 internationalized domain name [IDNA-PROTO]; as a result, 1312 implementations are strongly discouraged from including or 1313 attempting to check for the wildcard character emdedded within 1314 A-labels and/or U-labels of an internationalized domain name. 1315 Note, however, that a presented domain name identifier MAY contain 1316 the wildcard character where it occupies the entire leftmost label 1317 position, and where some or all of the remaining labels are 1318 A-labels or U-labels. 1320 Notwithstanding the foregoing security considerations, specifications 1321 that re-use this one can legitimately encourage continued support for 1322 the wildcard character if they have good reasons to do so, such as 1323 backward compatibility with deployed infrastructure (see, for 1324 example, [EV-CERTS]). 1326 5.3. Internationalized Domain Names 1328 Allowing internationalized domain names can lead to the inclusion of 1329 visually similar (so-called "confusable") characters in certificates; 1330 for discussion, see for example [IDNA-DEFS]. 1332 5.4. Multiple Identifiers 1334 A given application service might be addressed by multiple DNS domain 1335 names for a variety of reasons, and a given deployment might service 1336 multiple domains (e.g., in so-called "virtual hosting" environments). 1337 In the default TLS handshake exchange, the client is not able to 1338 indicate the DNS domain name with which it wants to communicate, and 1339 the TLS server returns only one certificate for itself. Absent an 1340 extension to TLS, a typical workaround used to facilitate mapping an 1341 application service to multiple DNS domain names is to embed all of 1342 the domain names into a single certificate. 1344 A more recent approach, formally specified in [TLS-EXT], is for the 1345 client to use the TLS "Server Name Indication" (SNI) extension when 1346 sending the client_hello message, stipulating the DNS domain name it 1347 desires or expects of the service. The service can then return the 1348 appropriate certificate in its Certificate message, and that 1349 certificate can represent a single DNS domain name. 1351 To accommodate the workaround that was needed before the development 1352 of the SNI extension, this specification allows multiple DNS-IDs, 1353 SRV-IDs, or URI-IDs in a certificate; however, it explicitly 1354 discourages multiple CN-IDs. Although it would be preferable to 1355 forbid multiple CN-IDs entirely, there are several reasons at this 1356 time why this specification states that they SHOULD NOT (instead of 1357 MUST NOT) be included: 1359 o At least one significant technology community of interest 1360 explicitly allows multiple CN-IDs [EV-CERTS]. 1362 o At least one significant certification authority is known to issue 1363 certificates containing multiple CN-IDs. 1365 o Many service providers often deem inclusion of multiple CN-IDs 1366 necessary in virtual hosting environments because at least one 1367 widely-deployed operating system does not yet support the SNI 1368 extension. 1370 It is hoped that the recommendation regarding multiple CN-IDs can be 1371 further tightened in the future. 1373 6. IANA Considerations 1375 This document specifies no actions for the IANA. 1377 7. Contributors 1379 The following individuals made important contributions to the text of 1380 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 1382 8. Acknowledgements 1384 The editors and contributors wish to thank the following individuals 1385 for their feedback and suggestions: Bernard Aboba, Richard Barnes, 1386 Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott 1387 Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus 1388 Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno 1389 Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love 1390 Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Simon 1391 Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt 1392 McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig 1393 Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert 1394 Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan 1395 Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew 1396 Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, 1397 Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter. 1399 Thanks also to Barry Leiba and Ben Campbell for their reviews on 1400 behalf of the Security Directorate and the General Area Review Team, 1401 respectively. 1403 The responsible Area Director was Alexey Melnikov. 1405 9. References 1407 9.1. Normative References 1409 [DNS] Mockapetris, P., "Domain names - implementation and 1410 specification", STD 13, RFC 1035, November 1987. 1412 [DNS-CONCEPTS] 1413 Mockapetris, P., "Domain names - concepts and facilities", 1414 STD 13, RFC 1034, November 1987. 1416 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1417 specifying the location of services (DNS SRV)", RFC 2782, 1418 February 2000. 1420 [IDNA-DEFS] 1421 Klensin, J., "Internationalized Domain Names for 1422 Applications (IDNA): Definitions and Document Framework", 1423 RFC 5890, August 2010. 1425 [IDNA-PROTO] 1426 Klensin, J., "Internationalized Domain Names in 1427 Applications (IDNA): Protocol", RFC 5891, August 2010. 1429 [KEYWORDS] 1430 Bradner, S., "Key words for use in RFCs to Indicate 1431 Requirement Levels", BCP 14, RFC 2119, March 1997. 1433 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 1434 (LDAP): String Representation of Distinguished Names", 1435 RFC 4514, June 2006. 1437 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1438 Housley, R., and W. Polk, "Internet X.509 Public Key 1439 Infrastructure Certificate and Certificate Revocation List 1440 (CRL) Profile", RFC 5280, May 2008. 1442 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1443 Subject Alternative Name for Expression of Service Name", 1444 RFC 4985, August 2007. 1446 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1447 Resource Identifier (URI): Generic Syntax", STD 66, 1448 RFC 3986, January 2005. 1450 9.2. Informative References 1452 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1453 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1455 [HTTPSbytes] 1456 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1457 Dhabi, November 2010, . 1462 [Defeating-SSL] 1463 Marlinspike, M., "New Tricks for Defeating SSL in 1464 Practice", BlackHat DC, February 2009, . 1468 [DNS-CASE] 1469 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 1470 Clarification", RFC 4343, January 2006. 1472 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1473 Rose, "DNS Security Introduction and Requirements", 1474 RFC 4033, March 2005. 1476 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1477 Security", RFC 4347, April 2006. 1479 [EMAIL-SRV] 1480 Daboo, C., "Use of SRV Records for Locating Email 1481 Submission/Access services", draft-daboo-srv-email-05 1482 (work in progress), May 2010. 1484 [EV-CERTS] 1485 CA/Browser Forum, "Guidelines For The Issuance And 1486 Management Of Extended Validation Certificates", 1487 October 2009, 1488 . 1490 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1491 Signalling Transport", RFC 5971, October 2010. 1493 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1494 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1495 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1497 [HTTP-TLS] 1498 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1500 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1501 4rev1", RFC 3501, March 2003. 1503 [IDNA2003] 1504 Faltstrom, P., Hoffman, P., and A. Costello, 1505 "Internationalizing Domain Names in Applications (IDNA)", 1506 RFC 3490, March 2003. 1508 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1509 September 1981. 1511 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1512 (IPv6) Specification", RFC 2460, December 1998. 1514 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1515 Internet Protocol", RFC 4301, December 2005. 1517 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1518 (LDAP): The Protocol", RFC 4511, June 2006. 1520 [LDAP-AUTH] 1521 Harrison, R., "Lightweight Directory Access Protocol 1522 (LDAP): Authentication Methods and Security Mechanisms", 1523 RFC 4513, June 2006. 1525 [LDAP-SCHEMA] 1526 Sciberras, A., "Lightweight Directory Access Protocol 1527 (LDAP): Schema for User Applications", RFC 4519, 1528 June 2006. 1530 [LDAP-TLS] 1531 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1532 Directory Access Protocol (v3): Extension for Transport 1533 Layer Security", RFC 2830, May 2000. 1535 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1536 Part Three: The Domain Name System (DNS) Database", 1537 RFC 3403, October 2002. 1539 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1540 December 2006. 1542 [NETCONF-SSH] 1543 Wasserman, M. and T. Goddard, "Using the NETCONF 1544 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1545 December 2006. 1547 [NETCONF-TLS] 1548 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1549 RFC 5539, May 2009. 1551 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1552 RFC 3977, October 2006. 1554 [NNTP-TLS] 1555 Murchison, K., Vinocur, J., and C. Newman, "Using 1556 Transport Layer Security (TLS) with Network News Transfer 1557 Protocol (NNTP)", RFC 4642, October 2006. 1559 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1560 Adams, "X.509 Internet Public Key Infrastructure Online 1561 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1563 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1564 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1566 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1567 STD 53, RFC 1939, May 1996. 1569 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1570 E. Lear, "Address Allocation for Private Internets", 1571 BCP 5, RFC 1918, February 1996. 1573 [PKIX-OLD] 1574 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1575 X.509 Public Key Infrastructure Certificate and CRL 1576 Profile", RFC 2459, January 1999. 1578 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1579 Service Location Using SRV RRs and the Dynamic Delegation 1580 Discovery Service (DDDS)", RFC 3958, January 2005. 1582 [SECTERMS] 1583 Shirey, R., "Internet Security Glossary, Version 2", 1584 RFC 4949, August 2007. 1586 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1587 A., Peterson, J., Sparks, R., Handley, M., and E. 1588 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1589 June 2002. 1591 [SIP-CERTS] 1592 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1593 Certificates in the Session Initiation Protocol (SIP)", 1594 RFC 5922, June 2010. 1596 [SIP-SIPS] 1597 Audet, F., "The Use of the SIPS URI Scheme in the Session 1598 Initiation Protocol (SIP)", RFC 5630, October 2009. 1600 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1601 October 2008. 1603 [SMTP-AUTH] 1604 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1605 for Authentication", RFC 4954, July 2007. 1607 [SMTP-TLS] 1608 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1609 Transport Layer Security", RFC 3207, February 2002. 1611 [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An 1612 Architecture for Describing Simple Network Management 1613 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1614 December 2002. 1616 [SNMP-TLS] 1617 Hardaker, W., "Transport Layer Security (TLS) Transport 1618 Model for the Simple Network Management Protocol (SNMP)", 1619 RFC 5953, August 2010. 1621 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1623 [SYSLOG-DTLS] 1624 Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1625 "Datagram Transport Layer Security (DTLS) Transport 1626 Mapping for Syslog", RFC 6012, October 2010. 1628 [SYSLOG-TLS] 1629 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1630 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1631 March 2009. 1633 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1634 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1636 [TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions: 1637 Extension Definitions", draft-ietf-tls-rfc4366-bis-12 1638 (work in progress), September 2010. 1640 [US-ASCII] 1641 American National Standards Institute, "Coded Character 1642 Set - 7-bit American Standard Code for Information 1643 Interchange", ANSI X3.4, 1986. 1645 [USINGTLS] 1646 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1647 RFC 2595, June 1999. 1649 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1650 Interface Guidelines", World Wide Web Consortium 1651 LastCall WD-wsc-ui-20100309, March 2010, 1652 . 1654 [X.500] International Telecommunications Union, "Information 1655 Technology - Open Systems Interconnection - The Directory: 1656 Overview of concepts, models and services", ITU- 1657 T Recommendation X.500, ISO Standard 9594-1, August 2005. 1659 [X.501] International Telecommunications Union, "Information 1660 Technology - Open Systems Interconnection - The Directory: 1661 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1662 August 2005. 1664 [X.509] International Telecommunications Union, "Information 1665 Technology - Open Systems Interconnection - The Directory: 1666 Public-key and attribute certificate frameworks", ITU- 1667 T Recommendation X.509, ISO Standard 9594-8, August 2005. 1669 [X.520] International Telecommunications Union, "Information 1670 Technology - Open Systems Interconnection - The Directory: 1671 Selected attribute types", ITU-T Recommendation X.509, 1672 ISO Standard 9594-6, August 2005. 1674 [X.690] International Telecommunications Union, "Information 1675 Technology - ASN.1 encoding rules: Specification of Basic 1676 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1677 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1678 X.690, ISO Standard 8825-1, August 2008. 1680 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1681 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-19 (work 1682 in progress), November 2010. 1684 [XMPP-OLD] 1685 Saint-Andre, P., Ed., "Extensible Messaging and Presence 1686 Protocol (XMPP): Core", RFC 3920, October 2004. 1688 Appendix A. Prior Art 1690 (This section is non-normative.) 1692 The recommendations in this document are an abstraction from 1693 recommendations in specifications for a wide range of application 1694 protocols. For the purpose of comparison and to delineate the 1695 history of thinking about application service identity verification 1696 within the IETF, this informative section gathers together prior art 1697 by including the exact text from various RFCs (the only modifications 1698 are changes to the names of several references to maintain coherence 1699 with the main body of this document, and the elision of irrelevant 1700 text as marked by the characters "[...]"). 1702 A.1. IMAP, POP3, and ACAP (1999) 1704 In 1999, [USINGTLS] specified the following text regarding 1705 application service identity verification in IMAP, POP3, and ACAP: 1707 ###### 1709 2.4. Server Identity Check 1711 During the TLS negotiation, the client MUST check its understanding 1712 of the server hostname against the server's identity as presented in 1713 the server Certificate message, in order to prevent man-in-the-middle 1714 attacks. Matching is performed according to these rules: 1716 o The client MUST use the server hostname it used to open the 1717 connection as the value to compare against the server name as 1718 expressed in the server certificate. The client MUST NOT use any 1719 form of the server hostname derived from an insecure remote source 1720 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1721 o If a subjectAltName extension of type dNSName is present in the 1722 certificate, it SHOULD be used as the source of the server's 1723 identity. 1724 o Matching is case-insensitive. 1726 o A "*" wildcard character MAY be used as the left-most name 1727 component in the certificate. For example, *.example.com would 1728 match a.example.com, foo.example.com, etc. but would not match 1729 example.com. 1730 o If the certificate contains multiple names (e.g. more than one 1731 dNSName field), then a match with any one of the fields is 1732 considered acceptable. 1734 If the match fails, the client SHOULD either ask for explicit user 1735 confirmation, or terminate the connection and indicate the server's 1736 identity is suspect. 1738 ###### 1740 A.2. HTTP (2000) 1742 In 2000, [HTTP-TLS] specified the following text regarding 1743 application service identity verification in HTTP: 1745 ###### 1747 3.1. Server Identity 1749 In general, HTTP/TLS requests are generated by dereferencing a URI. 1750 As a consequence, the hostname for the server is known to the client. 1751 If the hostname is available, the client MUST check it against the 1752 server's identity as presented in the server's Certificate message, 1753 in order to prevent man-in-the-middle attacks. 1755 If the client has external information as to the expected identity of 1756 the server, the hostname check MAY be omitted. (For instance, a 1757 client may be connecting to a machine whose address and hostname are 1758 dynamic but the client knows the certificate that the server will 1759 present.) In such cases, it is important to narrow the scope of 1760 acceptable certificates as much as possible in order to prevent man 1761 in the middle attacks. In special cases, it may be appropriate for 1762 the client to simply ignore the server's identity, but it must be 1763 understood that this leaves the connection open to active attack. 1765 If a subjectAltName extension of type dNSName is present, that MUST 1766 be used as the identity. Otherwise, the (most specific) Common Name 1767 field in the Subject field of the certificate MUST be used. Although 1768 the use of the Common Name is existing practice, it is deprecated and 1769 Certification Authorities are encouraged to use the dNSName instead. 1771 Matching is performed using the matching rules specified by 1772 [PKIX-OLD]. If more than one identity of a given type is present in 1773 the certificate (e.g., more than one dNSName name, a match in any one 1774 of the set is considered acceptable.) Names may contain the wildcard 1775 character * which is considered to match any single domain name 1776 component or component fragment. E.g., *.a.com matches foo.a.com but 1777 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1779 In some cases, the URI is specified as an IP address rather than a 1780 hostname. In this case, the iPAddress subjectAltName must be present 1781 in the certificate and must exactly match the IP in the URI. 1783 If the hostname does not match the identity in the certificate, user 1784 oriented clients MUST either notify the user (clients MAY give the 1785 user the opportunity to continue with the connection in any case) or 1786 terminate the connection with a bad certificate error. Automated 1787 clients MUST log the error to an appropriate audit log (if available) 1788 and SHOULD terminate the connection (with a bad certificate error). 1789 Automated clients MAY provide a configuration setting that disables 1790 this check, but MUST provide a setting which enables it. 1792 Note that in many cases the URI itself comes from an untrusted 1793 source. The above-described check provides no protection against 1794 attacks where this source is compromised. For example, if the URI 1795 was obtained by clicking on an HTML page which was itself obtained 1796 without using HTTP/TLS, a man in the middle could have replaced the 1797 URI. In order to prevent this form of attack, users should carefully 1798 examine the certificate presented by the server to determine if it 1799 meets their expectations. 1801 ###### 1803 A.3. LDAP (2000/2006) 1805 In 2000, [LDAP-TLS] specified the following text regarding 1806 application service identity verification in LDAP: 1808 ###### 1810 3.6. Server Identity Check 1812 The client MUST check its understanding of the server's hostname 1813 against the server's identity as presented in the server's 1814 Certificate message, in order to prevent man-in-the-middle attacks. 1816 Matching is performed according to these rules: 1818 o The client MUST use the server hostname it used to open the LDAP 1819 connection as the value to compare against the server name as 1820 expressed in the server's certificate. The client MUST NOT use 1821 the server's canonical DNS name or any other derived form of name. 1823 o If a subjectAltName extension of type dNSName is present in the 1824 certificate, it SHOULD be used as the source of the server's 1825 identity. 1826 o Matching is case-insensitive. 1827 o The "*" wildcard character is allowed. If present, it applies 1828 only to the left-most name component. 1830 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 1831 bar.com. If more than one identity of a given type is present in the 1832 certificate (e.g. more than one dNSName name), a match in any one of 1833 the set is considered acceptable. 1835 If the hostname does not match the dNSName-based identity in the 1836 certificate per the above check, user-oriented clients SHOULD either 1837 notify the user (clients MAY give the user the opportunity to 1838 continue with the connection in any case) or terminate the connection 1839 and indicate that the server's identity is suspect. Automated 1840 clients SHOULD close the connection, returning and/or logging an 1841 error indicating that the server's identity is suspect. 1843 Beyond the server identity checks described in this section, clients 1844 SHOULD be prepared to do further checking to ensure that the server 1845 is authorized to provide the service it is observed to provide. The 1846 client MAY need to make use of local policy information. 1848 ###### 1850 In 2006, [LDAP-AUTH] specified the following text regarding 1851 application service identity verification in LDAP: 1853 ###### 1855 3.1.3. Server Identity Check 1857 In order to prevent man-in-the-middle attacks, the client MUST verify 1858 the server's identity (as presented in the server's Certificate 1859 message). In this section, the client's understanding of the 1860 server's identity (typically the identity used to establish the 1861 transport connection) is called the "reference identity". 1863 The client determines the type (e.g., DNS name or IP address) of the 1864 reference identity and performs a comparison between the reference 1865 identity and each subjectAltName value of the corresponding type 1866 until a match is produced. Once a match is produced, the server's 1867 identity has been verified, and the server identity check is 1868 complete. Different subjectAltName types are matched in different 1869 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 1870 various subjectAltName types. 1872 The client may map the reference identity to a different type prior 1873 to performing a comparison. Mappings may be performed for all 1874 available subjectAltName types to which the reference identity can be 1875 mapped; however, the reference identity should only be mapped to 1876 types for which the mapping is either inherently secure (e.g., 1877 extracting the DNS name from a URI to compare with a subjectAltName 1878 of type dNSName) or for which the mapping is performed in a secure 1879 manner (e.g., using [DNSSEC], or using user- or admin-configured 1880 host-to-address/address-to-host lookup tables). 1882 The server's identity may also be verified by comparing the reference 1883 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 1884 Relative Distinguished Name (RDN) of the subject field of the 1885 server's certificate (where "last" refers to the DER-encoded order, 1886 not the order of presentation in a string representation of DER- 1887 encoded data). This comparison is performed using the rules for 1888 comparison of DNS names in Section 3.1.3.1, below, with the exception 1889 that no wildcard matching is allowed. Although the use of the Common 1890 Name value is existing practice, it is deprecated, and Certification 1891 Authorities are encouraged to provide subjectAltName values instead. 1892 Note that the TLS implementation may represent DNs in certificates 1893 according to X.500 or other conventions. For example, some X.500 1894 implementations order the RDNs in a DN using a left-to-right (most 1895 significant to least significant) convention instead of LDAP's right- 1896 to-left convention. 1898 If the server identity check fails, user-oriented clients SHOULD 1899 either notify the user (clients may give the user the opportunity to 1900 continue with the LDAP session in this case) or close the transport 1901 connection and indicate that the server's identity is suspect. 1902 Automated clients SHOULD close the transport connection and then 1903 return or log an error indicating that the server's identity is 1904 suspect or both. 1906 Beyond the server identity check described in this section, clients 1907 should be prepared to do further checking to ensure that the server 1908 is authorized to provide the service it is requested to provide. The 1909 client may need to make use of local policy information in making 1910 this determination. 1912 3.1.3.1. Comparison of DNS Names 1914 If the reference identity is an internationalized domain name, 1915 conforming implementations MUST convert it to the ASCII Compatible 1916 Encoding (ACE) format as specified in Section 4 of RFC 3490 1917 [IDNA2003] before comparison with subjectAltName values of type 1918 dNSName. Specifically, conforming implementations MUST perform the 1919 conversion operation specified in Section 4 of RFC 3490 as follows: 1921 o in step 1, the domain name SHALL be considered a "stored string"; 1922 o in step 3, set the flag called "UseSTD3ASCIIRules"; 1923 o in step 4, process each label with the "ToASCII" operation; and 1924 o in step 5, change all label separators to U+002E (full stop). 1926 After performing the "to-ASCII" conversion, the DNS labels and names 1927 MUST be compared for equality according to the rules specified in 1928 Section 3 of RFC3490. 1930 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 1931 values of type dNSName, and then only as the left-most (least 1932 significant) DNS label in that value. This wildcard matches any 1933 left-most DNS label in the server name. That is, the subject 1934 *.example.com matches the server names a.example.com and 1935 b.example.com, but does not match example.com or a.b.example.com. 1937 3.1.3.2. Comparison of IP Addresses 1939 When the reference identity is an IP address, the identity MUST be 1940 converted to the "network byte order" octet string representation 1941 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 1942 string will contain exactly four octets. For IP Version 6, as 1943 specified in RFC 2460, the octet string will contain exactly sixteen 1944 octets. This octet string is then compared against subjectAltName 1945 values of type iPAddress. A match occurs if the reference identity 1946 octet string and value octet strings are identical. 1948 3.1.3.3. Comparison of Other subjectName Types 1950 Client implementations MAY support matching against subjectAltName 1951 values of other types as described in other documents. 1953 ###### 1955 A.4. SMTP (2002/2007) 1957 In 2002, [SMTP-TLS] specified the following text regarding 1958 application service identity verification in SMTP: 1960 ###### 1962 4.1 Processing After the STARTTLS Command 1964 [...] 1966 The decision of whether or not to believe the authenticity of the 1967 other party in a TLS negotiation is a local matter. However, some 1968 general rules for the decisions are: 1970 o A SMTP client would probably only want to authenticate an SMTP 1971 server whose server certificate has a domain name that is the 1972 domain name that the client thought it was connecting to. 1974 [...] 1976 ###### 1978 In 2006, [SMTP-AUTH] specified the following text regarding 1979 application service identity verification in SMTP: 1981 ###### 1983 14. Additional Requirements When Using SASL PLAIN over TLS 1985 [...] 1987 After a successful [TLS] negotiation, the client MUST check its 1988 understanding of the server hostname against the server's identity as 1989 presented in the server Certificate message, in order to prevent man- 1990 in-the-middle attacks. If the match fails, the client MUST NOT 1991 attempt to authenticate using the SASL PLAIN mechanism. Matching is 1992 performed according to the following rules: 1994 The client MUST use the server hostname it used to open the 1995 connection as the value to compare against the server name as 1996 expressed in the server certificate. The client MUST NOT use any 1997 form of the server hostname derived from an insecure remote source 1998 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1999 If a subjectAltName extension of type dNSName is present in the 2000 certificate, it SHOULD be used as the source of the server's 2001 identity. 2002 Matching is case-insensitive. 2003 A "*" wildcard character MAY be used as the leftmost name 2004 component in the certificate. For example, *.example.com would 2005 match a.example.com, foo.example.com, etc., but would not match 2006 example.com. 2007 If the certificate contains multiple names (e.g., more than one 2008 dNSName field), then a match with any one of the fields is 2009 considered acceptable. 2011 ###### 2013 A.5. XMPP (2004) 2015 In 2004, [XMPP-OLD] specified the following text regarding 2016 application service identity verification in XMPP: 2018 ###### 2020 14.2. Certificate Validation 2022 When an XMPP peer communicates with another peer securely, it MUST 2023 validate the peer's certificate. There are three possible cases: 2025 Case #1: The peer contains an End Entity certificate which appears 2026 to be certified by a certification path terminating in a trust 2027 anchor (as described in Section 6.1 of [PKIX]). 2028 Case #2: The peer certificate is certified by a Certificate 2029 Authority not known to the validating peer. 2030 Case #3: The peer certificate is self-signed. 2032 In Case #1, the validating peer MUST do one of two things: 2033 1. Verify the peer certificate according to the rules of [PKIX]. 2034 The certificate SHOULD then be checked against the expected 2035 identity of the peer following the rules described in [HTTP-TLS], 2036 except that a subjectAltName extension of type "xmpp" MUST be 2037 used as the identity if present. If one of these checks fails, 2038 user-oriented clients MUST either notify the user (clients MAY 2039 give the user the opportunity to continue with the connection in 2040 any case) or terminate the connection with a bad certificate 2041 error. Automated clients SHOULD terminate the connection (with a 2042 bad certificate error) and log the error to an appropriate audit 2043 log. Automated clients MAY provide a configuration setting that 2044 disables this check, but MUST provide a setting that enables it. 2045 2. The peer SHOULD show the certificate to a user for approval, 2046 including the entire certification path. The peer MUST cache the 2047 certificate (or some non-forgeable representation such as a 2048 hash). In future connections, the peer MUST verify that the same 2049 certificate was presented and MUST notify the user if it has 2050 changed. 2052 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 2054 ###### 2056 Although [XMPP-OLD] defined its own rules, [XMPP] re-uses the rules 2057 in this document regarding application service identity verification 2058 in XMPP. 2060 A.6. NNTP (2006) 2062 In 2006, [NNTP-TLS] specified the following text regarding 2063 application service identity verification in NNTP: 2065 ###### 2066 5. Security Considerations 2068 [...] 2070 During the TLS negotiation, the client MUST check its understanding 2071 of the server hostname against the server's identity as presented in 2072 the server Certificate message, in order to prevent man-in-the-middle 2073 attacks. Matching is performed according to these rules: 2075 o The client MUST use the server hostname it used to open the 2076 connection (or the hostname specified in TLS "server_name" 2077 extension [TLS]) as the value to compare against the server name 2078 as expressed in the server certificate. The client MUST NOT use 2079 any form of the server hostname derived from an insecure remote 2080 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2081 done. 2082 o If a subjectAltName extension of type dNSName is present in the 2083 certificate, it SHOULD be used as the source of the server's 2084 identity. 2085 o Matching is case-insensitive. 2086 o A "*" wildcard character MAY be used as the left-most name 2087 component in the certificate. For example, *.example.com would 2088 match a.example.com, foo.example.com, etc., but would not match 2089 example.com. 2090 o If the certificate contains multiple names (e.g., more than one 2091 dNSName field), then a match with any one of the fields is 2092 considered acceptable. 2094 If the match fails, the client SHOULD either ask for explicit user 2095 confirmation or terminate the connection with a QUIT command and 2096 indicate the server's identity is suspect. 2098 Additionally, clients MUST verify the binding between the identity of 2099 the servers to which they connect and the public keys presented by 2100 those servers. Clients SHOULD implement the algorithm in Section 6 2101 of [PKIX] for general certificate validation, but MAY supplement that 2102 algorithm with other validation methods that achieve equivalent 2103 levels of verification (such as comparing the server certificate 2104 against a local store of already-verified certificates and identity 2105 bindings). 2107 ###### 2109 A.7. NETCONF (2006/2009) 2111 In 2006, [NETCONF-SSH] specified the following text regarding 2112 application service identity verification in NETCONF: 2114 ###### 2116 6. Security Considerations 2118 The identity of the server MUST be verified and authenticated by the 2119 client according to local policy before password-based authentication 2120 data or any configuration or state data is sent to or received from 2121 the server. The identity of the client MUST also be verified and 2122 authenticated by the server according to local policy to ensure that 2123 the incoming client request is legitimate before any configuration or 2124 state data is sent to or received from the client. Neither side 2125 should establish a NETCONF over SSH connection with an unknown, 2126 unexpected, or incorrect identity on the opposite side. 2128 ###### 2130 In 2009, [NETCONF-TLS] specified the following text regarding 2131 application service identity verification in NETCONF: 2133 ###### 2135 3.1. Server Identity 2137 During the TLS negotiation, the client MUST carefully examine the 2138 certificate presented by the server to determine if it meets the 2139 client's expectations. Particularly, the client MUST check its 2140 understanding of the server hostname against the server's identity as 2141 presented in the server Certificate message, in order to prevent man- 2142 in-the-middle attacks. 2144 Matching is performed according to the rules below (following the 2145 example of [NNTP-TLS]): 2147 o The client MUST use the server hostname it used to open the 2148 connection (or the hostname specified in the TLS "server_name" 2149 extension [TLS]) as the value to compare against the server name 2150 as expressed in the server certificate. The client MUST NOT use 2151 any form of the server hostname derived from an insecure remote 2152 source (e.g., insecure DNS lookup). CNAME canonicalization is not 2153 done. 2154 o If a subjectAltName extension of type dNSName is present in the 2155 certificate, it MUST be used as the source of the server's 2156 identity. 2157 o Matching is case-insensitive. 2158 o A "*" wildcard character MAY be used as the leftmost name 2159 component in the certificate. For example, *.example.com would 2160 match a.example.com, foo.example.com, etc., but would not match 2161 example.com. 2163 o If the certificate contains multiple names (e.g., more than one 2164 dNSName field), then a match with any one of the fields is 2165 considered acceptable. 2167 If the match fails, the client MUST either ask for explicit user 2168 confirmation or terminate the connection and indicate the server's 2169 identity is suspect. 2171 Additionally, clients MUST verify the binding between the identity of 2172 the servers to which they connect and the public keys presented by 2173 those servers. Clients SHOULD implement the algorithm in Section 6 2174 of [PKIX] for general certificate validation, but MAY supplement that 2175 algorithm with other validation methods that achieve equivalent 2176 levels of verification (such as comparing the server certificate 2177 against a local store of already-verified certificates and identity 2178 bindings). 2180 If the client has external information as to the expected identity of 2181 the server, the hostname check MAY be omitted. 2183 ###### 2185 A.8. Syslog (2009) 2187 In 2009, [SYSLOG-TLS] specified the following text regarding 2188 application service identity verification in Syslog: 2190 ###### 2192 5.2. Subject Name Authorization 2194 Implementations MUST support certification path validation [PKIX]. 2195 In addition, they MUST support specifying the authorized peers using 2196 locally configured host names and matching the name against the 2197 certificate as follows. 2199 o Implementations MUST support matching the locally configured host 2200 name against a dNSName in the subjectAltName extension field and 2201 SHOULD support checking the name against the common name portion 2202 of the subject distinguished name. 2203 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 2204 the subjectAltName extension (and in common name, if used to store 2205 the host name), but only as the left-most (least significant) DNS 2206 label in that value. This wildcard matches any left-most DNS 2207 label in the server name. That is, the subject *.example.com 2208 matches the server names a.example.com and b.example.com, but does 2209 not match example.com or a.b.example.com. Implementations MUST 2210 support wildcards in certificates as specified above, but MAY 2211 provide a configuration option to disable them. 2212 o Locally configured names MAY contain the wildcard character to 2213 match a range of values. The types of wildcards supported MAY be 2214 more flexible than those allowed in subject names, making it 2215 possible to support various policies for different environments. 2216 For example, a policy could allow for a trust-root-based 2217 authorization where all credentials issued by a particular CA 2218 trust root are authorized. 2219 o If the locally configured name is an internationalized domain 2220 name, conforming implementations MUST convert it to the ASCII 2221 Compatible Encoding (ACE) format for performing comparisons, as 2222 specified in Section 7 of [PKIX]. 2223 o Implementations MAY support matching a locally configured IP 2224 address against an iPAddress stored in the subjectAltName 2225 extension. In this case, the locally configured IP address is 2226 converted to an octet string as specified in [PKIX], Section 2227 4.2.1.6. A match occurs if this octet string is equal to the 2228 value of iPAddress in the subjectAltName extension. 2230 ###### 2232 A.9. SIP (2010) 2234 In 2010, [SIP-CERTS] specified the following text regarding 2235 application service identity verification in SIP: 2237 ###### 2239 7.2. Comparing SIP Identities 2241 When an implementation (either client or server) compares two values 2242 as SIP domain identities: 2243 Implementations MUST compare only the DNS name component of each 2244 SIP domain identifier; an implementation MUST NOT use any scheme 2245 or parameters in the comparison. 2246 Implementations MUST compare the values as DNS names, which means 2247 that the comparison is case insensitive as specified by 2248 [DNS-CASE]. Implementations MUST handle Internationalized Domain 2249 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 2250 Implementations MUST match the values in their entirety: 2251 Implementations MUST NOT match suffixes. For example, 2252 "foo.example.com" does not match "example.com". 2253 Implemenations MUST NOT match any form of wildcard, such as a 2254 leading "." or "*." with any other DNS label or sequence of 2255 labels. For example, "*.example.com" matches only 2256 "*.example.com" but not "foo.example.com". Similarly, 2257 ".example.com" matches only ".example.com", and does not match 2258 "foo.example.com." 2260 [HTTP-TLS] allows the dNSName component to contain a 2261 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 2262 disallowing this explicitly, leaves the interpretation of 2263 wildcards to the individual specification. [SIP] does not 2264 provide any guidelines on the presence of wildcards in 2265 certificates. Through the rule above, this document 2266 prohibits such wildcards in certificates for SIP domains. 2268 ###### 2270 A.10. SNMP (2010) 2272 In 2010, [SNMP-TLS] specified the following text regarding 2273 application service identity verification in SNMP: 2275 ###### 2277 If the server's presented certificate has passed certification path 2278 validation [PKIX] to a configured trust anchor, and an active row 2279 exists with a zero-length snmpTlstmAddrServerFingerprint value, then 2280 the snmpTlstmAddrServerIdentity column contains the expected host 2281 name. This expected host name is then compared against the server's 2282 certificate as follows: 2284 o Implementations MUST support matching the expected host name 2285 against a dNSName in the subjectAltName extension field and MAY 2286 support checking the name against the CommonName portion of the 2287 subject distinguished name. 2289 o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName 2290 of the subjectAltName extension (and in common name, if used to 2291 store the host name), but only as the left-most (least 2292 significant) DNS label in that value. This wildcard matches any 2293 left-most DNS label in the server name. That is, the subject 2294 *.example.com matches the server names a.example.com and 2295 b.example.com, but does not match example.com or a.b.example.com. 2296 Implementations MUST support wildcards in certificates as 2297 specified above, but MAY provide a configuration option to disable 2298 them. 2300 o If the locally configured name is an internationalized domain 2301 name, conforming implementations MUST convert it to the ASCII 2302 Compatible Encoding (ACE) format for performing comparisons, as 2303 specified in Section 7 of [PKIX]. 2305 If the expected host name fails these conditions then the connection 2306 MUST be closed. 2308 ###### 2310 A.11. GIST (2010) 2312 In 2010, [GIST] specified the following text regarding application 2313 service identity verification in the General Internet Signalling 2314 Transport: 2316 ###### 2318 5.7.3.1. Identity Checking in TLS 2320 After TLS authentication, a node MUST check the identity presented by 2321 the peer in order to avoid man-in-the-middle attacks, and verify that 2322 the peer is authorised to take part in signalling at the GIST layer. 2323 The authorisation check is carried out by comparing the presented 2324 identity with each Authorised Peer Database (APD) entry in turn, as 2325 discussed in Section 4.4.2. This section defines the identity 2326 comparison algorithm for a single APD entry. 2328 For TLS authentication with X.509 certificates, an identity from the 2329 DNS namespace MUST be checked against each subjectAltName extension 2330 of type dNSName present in the certificate. If no such extension is 2331 present, then the identity MUST be compared to the (most specific) 2332 Common Name in the Subject field of the certificate. When matching 2333 DNS names against dNSName or Common Name fields, matching is case- 2334 insensitive. Also, a "*" wildcard character MAY be used as the left- 2335 most name component in the certificate or identity in the APD. For 2336 example, *.example.com in the APD would match certificates for 2337 a.example.com, foo.example.com, *.example.com, etc., but would not 2338 match example.com. Similarly, a certificate for *.example.com would 2339 be valid for APD identities of a.example.com, foo.example.com, 2340 *.example.com, etc., but not example.com. 2342 Additionally, a node MUST verify the binding between the identity of 2343 the peer to which it connects and the public key presented by that 2344 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 2345 for general certificate validation, but MAY supplement that algorithm 2346 with other validation methods that achieve equivalent levels of 2347 verification (such as comparing the server certificate against a 2348 local store of already-verified certificates and identity bindings). 2350 For TLS authentication with pre-shared keys, the identity in the 2351 psk_identity_hint (for the server identity, i.e. the Responding node) 2352 or psk_identity (for the client identity, i.e. the Querying node) 2353 MUST be compared to the identities in the APD. 2355 ###### 2357 Authors' Addresses 2359 Peter Saint-Andre 2360 Cisco 2361 1899 Wyknoop Street, Suite 600 2362 Denver, CO 80202 2363 USA 2365 Phone: +1-303-308-3282 2366 Email: psaintan@cisco.com 2368 Jeff Hodges 2369 PayPal 2370 2211 North First Street 2371 San Jose, California 95131 2372 US 2374 Email: Jeff.Hodges@PayPal.com