idnits 2.17.00 (12 Aug 2021) /tmp/idnits1265/draft-saintandre-tls-server-id-check-11.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 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 (November 17, 2010) is 4202 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-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 (~~), 4 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: May 21, 2011 PayPal 6 November 17, 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-11 13 Abstract 15 Many application technologies enable a secure connection 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 May 21, 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 1.6. Contributors . . . . . . . . . . . . . . . . . . . . . . . 12 64 1.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13 65 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 2.1. Naming Application Services . . . . . . . . . . . . . . . 13 67 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 68 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 69 3. Representation of Server Identity . . . . . . . . . . . . . . 17 70 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 4. Verification of Service Identity . . . . . . . . . . . . . . . 19 73 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 4.2. Constructing a List of Reference Identifiers . . . . . . . 19 75 4.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 21 77 4.3. Preparing to Seeking a Match . . . . . . . . . . . . . . . 21 78 4.4. Verifying the DNS Domain Name Portion . . . . . . . . . . 23 79 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 23 80 4.4.2. Checking of Internationalized Domain Names . . . . . . 23 81 4.4.3. Checking of Wildcard Certificates . . . . . . . . . . 23 82 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 24 83 4.5. Verifying the Application Type Portion . . . . . . . . . . 24 84 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 25 85 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 25 86 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 25 88 4.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 25 89 4.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 25 90 4.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 25 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 92 5.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 26 93 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 26 94 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 27 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 28 99 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 33 100 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 33 101 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 34 102 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 35 103 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 39 104 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 40 105 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 41 106 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 42 107 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 43 108 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 44 109 A.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 45 110 A.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 46 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 113 1. Introduction 115 1.1. Motivation 117 The visible face of the Internet consists of services that employ a 118 client-server architecture in which an interactive or automated 119 client connects to an application service in order to retrieve or 120 upload information, communicate with other entities, or access a 121 broader network of services. When a client connects to an 122 application service using Transport Layer Security [TLS] or Datagram 123 Transport Layer Security [DTLS], it references some conception of the 124 server's identity while attempting to establish a secure connection 125 (e.g., "the website at example.com"). Likewise, during TLS 126 negotiation the server presents its conception of the service's 127 identity in the form of a public-key certificate that was issued by a 128 certification authority (CA) in the context of the Internet Public 129 Key Infrastructure using X.509 [PKIX]. Informally, we can think of 130 these identities as the client's "reference identity" and the 131 server's "presented identity" (these rough ideas are defined more 132 precisely later in this document through the concept of particular 133 identifiers). In general, a client needs to verify that the server's 134 presented identity matches its reference identity so it can be sure 135 that the certificate can legitimately be used to authenticate the 136 connection. 138 Many application technologies adhere to the pattern just outlined, 139 including but not limited to the following: 141 o The Internet Message Access Protocol [IMAP] and the Post Office 142 Protocol [POP3], for which see also [USINGTLS] 144 o The Hypertext Transfer Protocol [HTTP], for which see also 145 [HTTP-TLS] 147 o The Lightweight Directory Access Protocol [LDAP], for which see 148 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 150 o The Simple Mail Transfer Protocol [SMTP], for which see also 151 [SMTP-AUTH] and [SMTP-TLS] 153 o The Extensible Messaging and Presence Protocol [XMPP], for which 154 see also [XMPP-OLD] 156 o The Network News Transfer Protocol [NNTP], for which see also 157 [NNTP-TLS] 159 o The NETCONF Configuration Protocol [NETCONF], for which see also 160 [NETCONF-SSH] and [NETCONF-TLS] 162 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] and 163 [SYSLOG-DTLS] 165 o The Session Initiation Protocol [SIP], for which see also 166 [SIP-CERTS] 168 o The Simple Network Management Protocol [SNMP], for which see also 169 [SNMP-TLS] 171 o The General Internet Signalling Transport [GIST] 173 Application protocols have traditionally specified their own rules 174 for representing and verifying application service identity. 175 Unfortunately, this divergence of approaches has caused some 176 confusion among certification authorities, application developers, 177 and protocol designers. 179 Therefore, to codify best current practices regarding the 180 implementation and deployment of secure PKIX-based authentication, 181 this document specifies recommended procedures for representing and 182 verifying application service identity in certificates intended for 183 use in applications employing TLS. 185 1.2. Applicability and Audience 187 This document does not supersede the rules for certificate issuance 188 or validation provided in [PKIX], which governs any certificate- 189 related topic on which this document is silent (e.g., certificate 190 syntax, certificate extensions such as name constraints and extended 191 key usage, and handling of certification paths). Specifically, in 192 order to ensure proper authentication, application clients need to 193 verify the entire certification path, because this document addresses 194 only name forms in the leaf server certificate, not any name forms in 195 the chain of certificates used to validate the server certificate. 197 This document also does not supersede the rules for verifying service 198 identity provided in specifications for existing application 199 protocols, such as those mentioned under Appendix A. However, the 200 best current practices described here can be referenced by future 201 specifications, including updates to specifications for existing 202 application protocols if the relevant technology communities agree to 203 do so. It is also expected that this document will be updated or 204 obsoleted in the future as best practices for issuance and 205 verification of PKIX certificates continue to evolve through more 206 widespread implementation and deployment of TLS-protected application 207 services over the Internet. 209 The primary audience for this document consists of application 210 protocol designers, who might reference this document instead of 211 defining their own rules for the representation and verification of 212 application service identity. Secondarily, the audience consists of 213 certification authorities, client developers, service providers, and 214 other members of technology communities that might re-use or 215 "profile" the recommendations in this document when defining 216 certificate issuance policies, writing software algorithms for 217 identity matching, generating certificate signing requests, etc. 219 1.3. Overview of Recommendations 221 To orient the reader, this section provides an informational overview 222 of the recommendations contained in this document. 224 For the primary audience of application protocol designers, based on 225 best current practices this document provides recommended procedures 226 for representation and verification of application service identity 227 within PKIX certificates used in the context of TLS. 229 For the secondary audiences, in essence this document encourages 230 certification authorities, application service providers, and 231 application client developers to coalesce on the following best 232 current practices: 234 o Move away from including and checking strings that look like 235 domain names in the subject's Common Name. 237 o Move toward including and checking DNS domain names via the 238 subjectAlternativeName extension designed for that purpose: 239 dNSName. 241 o Move toward including and checking even more specific 242 subjectAlternativeName extensions where appropriate for the using 243 protocol (e.g., uniformResourceIdentifier and the otherName form 244 SRVName). 246 o Move away from the issuance of so-called wildcard certificates 247 (e.g., a certificate containing an identifier for 248 "*.example.com"). 250 These suggestions are not entirely consistent with all practices that 251 are currently followed by certification authorities, client 252 developers, and service providers. However, they reflect the best 253 aspects of current practices and are expected to become more widely 254 adopted in the coming years. 256 1.4. Scope 258 1.4.1. In Scope 260 This document applies only to service identities associated with 261 fully-qualified DNS domain names, only to TLS and DTLS (or the older 262 Secure Sockets Layer (SSL) technology), and only to PKIX-based 263 systems. As a result, the scenarios described in the following 264 section are out of scope for this specification (although they might 265 be addressed by future specifications). 267 1.4.2. Out of Scope 269 The following topics are out of scope for this specification: 271 o Client or end-user identities. 273 Certificates representing client or end-user identities (e.g., the 274 rfc822Name identifier) can be used for mutual authentication 275 between a client and server or between two clients, thus enabling 276 stronger client-server security or end-to-end security. However, 277 certification authorities, application developers, and service 278 operators have less experience with client certificates than with 279 server certificates, thus gives us fewer models from which to 280 generalize and a less solid basis for defining best practices. 282 o Identifiers other than fully-qualified DNS domain names. 284 Some certification authorities issue server certificates based on 285 IP addresses, but preliminary evidence indicates that such 286 certificates are a very small percentage (less than 1%) of issued 287 certificates. Furthermore, IP addresses are not necessarily 288 reliable identifiers for application services because of the 289 existence of private internets [PRIVATE], host mobility, multiple 290 interfaces on a given host, Network Address Translators (NATs) 291 resulting in different addresses for a host from different 292 locations on the network, the practice of grouping many hosts 293 together behind a single IP address, etc. Most fundamentally, 294 most users find DNS domain names much easier to work with than IP 295 addresses, which is why the domain name system was designed in the 296 first place. We prefer to define best practices for the much more 297 common use case and not to complicate the rules in this 298 specification. 300 Furthermore, we focus here on application service identities, not 301 specific resources located at such services, e.g., a specific web 302 page that can be accessed at a particular Uniform Resource 303 Identifier [URI] whose authority component is the DNS domain name 304 of the application service. We also do not address identifiers 305 derived from Naming Authority Pointer (NAPTR) DNS resource records 306 [NAPTR] and related technologies such as [S-NAPTR], since such 307 identifiers cannot be validated in a trusted manner in the absence 308 of [DNSSEC]. 310 Finally, we do not discuss attributes unrelated to DNS domain 311 names, such as those defined in [X.520] and other such 312 specifications (e.g., organizational attributes, geographical 313 attributes, company logos, and the like). 315 o Security protocols other than [TLS], [DTLS], or the older Secure 316 Sockets Layer (SSL) technology. 318 Although other secure, lower-layer protocols exist and even employ 319 PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases 320 can differ from those of TLS-based and DTLS-based application 321 technologies. Furthermore, application technologies have less 322 experience with IPsec than with TLS, thus making it more difficult 323 to gather feedback on proposed best practices. 325 o Keys or certificates employed outside the context of PKIX-based 326 systems. 328 Some deployed application technologies use a web of trust model 329 based on or similar to OpenPGP [OPENPGP], or use self-signed 330 certificates, or are deployed on networks that are not directly 331 connected to the public Internet and therefore cannot depend on 332 Certificate Revocation Lists (CRLs) or the Online Certificate 333 Status Protocol [OCSP] to check CA-issued certificates. However, 334 the syntax of OpenPGP differs essentially from that of X.509, the 335 data in self-signed certificates has not been certified by a third 336 party in any way, and checking of CA-issued certificates via CRLs 337 or OSCP is critically important to maintaining the security of 338 PKIX-based systems. Attempting to define best practices for such 339 technologies would unduly complicate the rules defined in this 340 specification. 342 Furthermore, this document also does not address various 343 certification authority policies, such as: 345 o What types or "classes" of certificates to issue and whether to 346 apply different policies for them (e.g., allow the wildcard 347 character in certificates issued to individuals who have provided 348 proof of identity but do not allow the wildcard character in 349 "Extended Validation" certificates [EV-CERTS]). 351 o Whether to issue certificates based on IP addresses (or some other 352 form, such as relative domain names) in addition to fully- 353 qualified DNS domain names. 355 o Which identifiers to include (e.g., whether to include SRV-IDs or 356 URI-IDs as defined in the body of this specification). 358 o How to certify or validate fully-qualified domain names and 359 application service types. 361 o How to certify or validate other kinds of information that might 362 be included in a certificate (e.g., organization name). 364 Finally, this specification is mostly silent about user interface 365 issues, which in general are properly the responsibility of client 366 software developers and standards development organizations dedicated 367 to particular application technologies (see for example [WSC-UI]). 369 1.5. Terminology 371 Because many concepts related to "identity" are often too vague to be 372 actionable in application protocols, we define a set of more concrete 373 terms for use in this specification. (Following the convention from 374 [SECTERMS], each entry is preceded by a dollar sign ($) and a space.) 376 application service: A service on the Internet that enables 377 interactive and automated clients to connect for the purpose of 378 retrieving or uploading information, communicating with other 379 entities, or connecting to a broader network of services. 381 application service provider: An organization or individual that 382 hosts or deploys an application service. 384 attribute-type-and-value pair: A colloquial name for the ASN.1-based 385 construction comprising a Relative Distinguished Name (RDN), which 386 itself is a building-block component of Distinguished Names. See 387 Section 2 of [LDAP-DN]. 389 automated client: A software agent or device that is not directly 390 controlled by a human user. 392 delegated domain: A domain name or host name that is explicitly 393 configured for connecting to the source domain, by either (a) the 394 human user controlling an interactive client or (b) a trusted 395 administrator. In case (a), one example of delegation is an 396 account setup that specifies the domain name of a particular host 397 to be used for retrieving information or connecting to a network, 398 which might be different from the server portion of the user's 399 account name (e.g., a server at mailhost.example.com for 400 connecting to an IMAP server hosting an email address of 401 juliet@example.com). In case (b), one example of delegation is an 402 admin-configured host-to-address/address-to-host lookup table. 404 derived domain: A domain name or host name that a client has derived 405 from the source domain in an automated fashion (e.g., by means of 406 a [DNS-SRV] lookup). 408 identifier: A particular instance of an identifier type that is 409 either presented by a server in a certificate or referenced by a 410 client for matching purposes. 412 identifier type: A formally defined category of identifier that can 413 be included in a certificate and therefore that can also be used 414 for matching purposes; the types covered in this specification 415 are: 417 * CN-ID = a Relative Distinguished Name (RDN) in the certificate 418 subject field that contains one and only one attribute-type- 419 and-value pair of type Common Name (CN), where the value 420 matches the overall form of a domain name (informally, dot- 421 separated letter-digit-hyphen labels); see [PKIX] and also 422 [LDAP-SCHEMA] 424 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 426 * SRV-ID = a subjectAltName entry of type otherName whose name 427 form is SRVName; see [SRVNAME] 429 * URI-ID = a subjectAltName entry of type 430 uniformResourceIdentifier, where the value includes both (i) a 431 "scheme" and (ii) an "authority" component whose "host" 432 subcomponent matches the "reg-name" rule (where the quoted 433 terms represent the associated [ABNF] rules from [URI]); see 434 [PKIX] 436 interactive client: A software agent or device that is directly 437 controlled by a human user. (Other specifications related to 438 security and application protocols, such as [WSC-UI], often refer 439 to this entity as a "user agent"; however that term is neither 440 entirely accurate nor consistent with the terminology of common 441 application protocols such as [HTTP].) 443 pinning: The act of establishing a cached name association between 444 the application service's certificate and one of the client's 445 reference identifiers, despite the fact that none of the presented 446 identifiers matches the given reference identifier. Pinning is 447 accomplished by allowing a human user to positively accept the 448 mismatch during an attempt to connect to the application service. 449 Once a cached name association is established, the certificate is 450 said to be pinned to the reference identifier and in future 451 connection attempts the client simply verifies that the service's 452 presented certificate matches the pinned certificate, as described 453 under Section 4.6.2. (A similar definition of "pinning" is 454 provided in [WSC-UI].) 456 PKIX: PKIX is a short name for the Internet Public Key 457 Infrastructure using X.509 defined in RFC 5280 [PKIX], which 458 comprises a profile of the X.509v3 certificate specifications and 459 X.509v2 certificate revocation list (CRL) specifications for use 460 in the Internet. 462 PKIX-based system: A software implementation or deployed service 463 that makes use of X.509v3 certificates and X.509v2 certificate 464 revocation lists (CRLs). 466 PKIX certificate: An X.509v3 certificate generated and employed in 467 the context of PKIX. 469 presented identifier: An identifier that is presented by a server to 470 a client within the server's PKIX certificate when the client 471 attempts to establish a secure connection with the server; the 472 certificate can include one or more presented identifiers of 473 different types. 475 reference identifier: An identifier, constructed from a source 476 domain and optionally a service type, used by the client for 477 matching purposes when examining presented identifiers. 479 service type: A formal identifier for the application protocol used 480 to provide a particular kind of service at a domain; the service 481 type typically takes the form of a Uniform Resource Identifier 482 scheme [URI] or a DNS SRV Service [DNS-SRV]. 484 source domain: The fully-qualified DNS domain name that a client 485 expects an application service to present in the certificate 486 (e.g., "www.example.com"), typically input by a human user, 487 configured into a client, or provided by reference such as in a 488 hyperlink. The combination of a source domain and, optionally, a 489 service type enables a client to construct one or more reference 490 identifiers. 492 subjectAltName entry: An identifier placed in a subjectAltName 493 extension. 495 subjectAltName extension: A standard PKIX certificate extension 496 [PKIX] enabling identifiers of various types to be bound to the 497 certificate subject -- in addition to, or in place of, identifiers 498 that may be embedded in or provided as a certificate's subject 499 field. 501 subject field: The subject field of a PKIX certificate identifies 502 the entity associated with the public key stored in the subject 503 public key field (see Section 4.1.2.6 of [PKIX]). 505 subject name: In an overall sense, a subject's name(s) can be 506 represented by or in the subject field, the subjectAltName 507 extension, or both (see [PKIX] for details). More specifically, 508 the term often refers to the composite name of a PKIX 509 certificate's subject, encoded as the X.501 type Name and conveyed 510 in a certificate's subject field (see Section 4.1.2.6 of [PKIX]). 512 TLS client: An entity that assumes the role of a client in a 513 Transport Layer Security [TLS] negotiation; in this specification 514 we generally assume that the TLS client is an (interactive or 515 automated) application client, however in application protocols 516 that enable server-to-server communication the TLS client could be 517 a peer application service. 519 TLS server: An entity that assumes the role of a server in a 520 Transport Layer Security [TLS] negotiation; in this specfication 521 we assume that the TLS server is an application service. 523 Most security-related terms in this document are to be understood in 524 the sense defined in [SECTERMS]; such terms include, but are not 525 limited to, "attack", "authentication", "authorization", 526 "certification authority", "certification path", "certificate", 527 "credential", "identity", "self-signed certificate", "trust", "trust 528 anchor", "trust chain", "validate", and "verify". 530 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 531 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 532 "OPTIONAL" in this document are to be interpreted as described in 533 [KEYWORDS]. 535 1.6. Contributors 537 The following individuals made important contributions to the text of 538 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 540 1.7. Acknowledgements 542 The editors and contributors wish to thank the following individuals 543 for their feedback and suggestions: Bernard Aboba, Richard Barnes, 544 Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Ben 545 Campbell, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave 546 Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip 547 Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul 548 Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey 549 Hutzelman, Simon Josefsson, Geoff Keating, John Klensin, Scott 550 Lawrence, Matt McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, 551 Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea, 552 Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan 553 Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew 554 Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, 555 Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter. 557 2. Names 559 This section discusses naming of application services on the 560 Internet, followed by a brief tutorial about subject naming in PKIX. 562 2.1. Naming Application Services 564 This specification assumes that the name of an application service is 565 based on a DNS domain name (e.g., "example.com") -- supplemented in 566 some circumstances by a service type (e.g., "the IMAP server at 567 example.com"). 569 From the perspective of the application client or user, some names 570 are direct because they are provided directly by a human user (e.g., 571 via runtime input, prior configuration, or explicit acceptance of a 572 client connection attempt) whereas other names are indirect because 573 they are automatially resolved by the client based on user input 574 (e.g., a target name resolved from a source name using DNS SRV 575 records). This dimension matters most for certificate consumption, 576 specifically verification as discussed in this document. 578 From the perspective of the application service, some names are 579 unrestricted because they can be used in any type of service (e.g., a 580 certificate might be re-used for both the HTTP service and the IMAP 581 service at example.com) whereas other names are restricted because 582 they can be used in only one type of service (e.g., a special-purpose 583 certificate that can be used only for an IMAP service). This 584 dimension matters most for certificate issuance. 586 Therefore: 588 o A CN-ID is direct and unrestricted. 590 o A DNS-ID is direct and unrestricted. 592 o An SRV-ID can be either direct or (more typically) indirect, and 593 is restricted. 595 o A URI-ID is direct and restricted. 597 We summarize this taxonomy in the following table. 599 +-----------+-----------+---------------+ 600 | | Direct | Restricted | 601 +-----------+-----------+---------------+ 602 | CN-ID | Yes | No | 603 +-----------+-----------+---------------+ 604 | DNS-ID | Yes | No | 605 +-----------+-----------+---------------+ 606 | SRV-ID | Either | Yes | 607 +-----------+-----------+---------------+ 608 | URI-ID | Yes | Yes | 609 +-----------+-----------+---------------+ 611 When implementing software, deploying services, and issuing 612 certificates for secure PKIX-based authentication, it is important to 613 keep these distinctions in mind. In particular, best practices 614 differ somewhat for application server implementations, application 615 client implementations, application service providers, and 616 certification authorities. Ideally, protocol specifications that 617 reference this document will specify which identifiers are mandatory- 618 to-implement by servers and clients, which identifiers ought to be 619 supported by certificate issuers, and which identifiers ought to be 620 requested by application service providers. Because these 621 requirements differ across applications, it is impossible to 622 categorically stipulate universal rules (e.g., that all software 623 implementations, service providers, and certification authorities for 624 all application protocols need to use or support DNS-IDs as a 625 baseline for the purpose of interoperability). However, it is 626 preferable that each application protocol will at least define a 627 baseline that applies to the community of software developers, 628 application service providers, and CAs actively using or supporting 629 that technology (one such community, the CA/Browser Forum, has 630 codified such a baseline for "Extended Validation Certificates" in 631 [EV-CERTS]). 633 2.2. DNS Domain Names 635 For the purposes of this specification, the name of an application 636 service is a DNS domain name that conforms to one of the following 637 forms: 639 1. A "traditional domain name", i.e., a fully-qualified domain name 640 or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 641 labels" as defined in [IDNA-DEFS]. Informally, such labels are 642 constrained to [US-ASCII] letters, digits, and the hyphen, with 643 the hyphen prohibited in the first character position. 644 Additional qualifications apply (please refer to the above- 645 referenced specifications for details) but they are not relevant 646 to this specification. 648 2. An "internationalized domain name", i.e., a DNS domain name that 649 conforms to the overall form of a domain name (informally, dot- 650 separated letter-digit-hyphen labels) but that can include 651 appropriately encoded Unicode code points outside the traditional 652 US-ASCII range (more precisely, either U-labels or A-labels as 653 described in [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 of 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 subjectAltName extension that includes at 686 least one subjectAltName entry, because the subject alternative name 687 ("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 is identified by a name or 693 names carried in the subject field and/or in one of the following 694 identifier types: 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 ("www.example.com", "mail.example.net", and 705 "im.example.org" 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, the Common Name might contain a human-readable string for 714 the service, rather than a string whose form matches that of a fully- 715 qualified DNS domain name: 717 CN=A Free Chat Service,O=Example Org,C=GB 719 In general, this specification recommends and prefers use of 720 subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the 721 subject field (CN-ID) where possible, as more completely described in 722 the following sections. However, profiles of this specification can 723 legitimately encourage continued support for the CN-ID identifier 724 type if they have good reasons to do so, such as backward 725 compatibility with deployed infrastructure. 727 Implementation Note: Confusion sometimes arises from different 728 renderings or encodings of the hierarchical information contained 729 in a certificate. Certificates are binary objects and are encoded 730 using the Distinguished Encoding Rules (DER) specified in [X.690]. 731 However, some implementations generate displayable (a.k.a. 732 printable) renderings of the certificate issuer, subject field, 733 and subjectAltName extension, and these renderings convert the 734 DER-encoded sequences into a "string representation" before being 735 displayed. Because a Distinguished Name (DN) is an ordered 736 sequence, order is typically preserved in the DN string 737 representations, although the two most prevalent DN string 738 representations differ in employing left-to-right vs. right-to- 739 left ordering. However, because a Relative Distinguished Name 740 (RDN) is an unordered group of attribute-type-and-value pairs, the 741 string representation of an RDN can differ from the canonical DER 742 encoding (and the order of attribute-type-and-value pairs can 743 differ in the RDN string representations or display orders 744 provided by various implementations). Furthermore, various 745 specifications refer to the order of RDNs using terminology that 746 is not directly related to the information hierarchy, such as 747 "most specific" vs. "least specific", "left-most" vs. "right- 748 most", "first" vs. "last", or "most significant" vs. "least 749 significant" (see for example [LDAP-DN]). To reduce confusion, in 750 this specification we avoid such terms and instead use the terms 751 provided under Section 1.5; in particular, we do not use the term 752 "(most specific) Common Name field in the subject field" from 753 [HTTP-TLS] and instead state that a CN-ID is a Relative 754 Distinguished Name (RDN) in the certificate subject that contains 755 one and only one attribute-type-and-value pair of type Common Name 756 (thus removing the possibility that an RDN might contain multiple 757 AVAs of type CN, one of which would be considered "most 758 specific"). Finally, although theoretically some consider the 759 order of AVAs within an RDN to have meaning, in practice that rule 760 is not observed, so we consider an AVA of type CN to be valid at 761 any position within the subject field. 763 3. Representation of Server Identity 765 3.1. Rules 767 When a certification authority issues a certificate based on the 768 fully-qualified DNS domain name at which the application service 769 provider will provide the relevant application, the following rules 770 apply to the representation of application service identities. 772 1. The certificate SHOULD include a "DNS-ID" if possible as a 773 baseline for interoperability. 775 2. If the service using the certificate deploys a technology in 776 which a server is discovered by means of DNS SRV records 777 [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate 778 SHOULD include an "SRV-ID". 780 3. If the service using the certificate deploys a technology in 781 which a server is typically associated with a URI (e.g., this is 782 true of [SIP]), then the certificate SHOULD include a URI-ID; the 783 scheme SHALL be that of the protocol associated with the service 784 type and the authority component SHALL be the fully-qualified DNS 785 domain name of the service. 787 4. The certificate MAY include other application-specific 788 identifiers for types that were defined before publication of 789 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names 790 or URI schemes do not exist; however, such application-specific 791 identifiers are not applicable to all application technologies 792 and therefore are out of scope for this specification. 794 5. Even though many deployed clients still check for the CN-ID 795 within the certificate subject field, the certificate SHOULD NOT 796 represent the server's fully-qualified DNS domain name in a CN-ID 797 unless a profile of this specification encourages continued 798 support for the CN-ID identifier type. 800 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or 801 URI-ID (but SHOULD NOT contain more than one CN-ID). 803 7. Unless a profile of this specification allows continued support 804 for the wildcard character '*', the fully-qualified DNS domain 805 name portion of a presented identifier SHOULD NOT contain the 806 wildcard character, whether as the complete left-most label 807 within the identifier (following the definition of "label" from 808 [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., 809 *oo.example.com, f*o.example.com, or foo*.example.com). For 810 details, see Section 5.2. 812 3.2. Examples 814 A certificate for the website at "www.example.com" might include only 815 a DNS-ID of "www.example.com" (and, strictly as a fallback for 816 existing client software, a CN-ID of "www.example.com"). 818 A certificate for the IMAP-accessible email server at 819 "mail.example.net" might include SRV-IDs of "_imap.mail.example.net" 820 and "_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of 821 "mail.example.net". 823 A certificate for the XMPP-compatible instant messaging server at 824 "im.example.org" might include SRV-IDs of "_xmpp- 825 client.im.example.org" and "_xmpp-server.im.example.org" (see 826 [XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific 827 "XmppAddr" of "im.example.org" (see [XMPP]). 829 4. Verification of Service Identity 831 4.1. Overview 833 At a high level, the client verifies the application service's 834 identity by performing the actions listed below (which are defined in 835 the following subsections of this document): 837 1. The client constructs a list of acceptable reference identifiers 838 based on the source domain and, optionally, the type of service 839 to which the client is connecting. 841 2. The server provides its identifiers in the form of a PKIX 842 certificate. 844 3. The client checks each of its reference identifiers against the 845 presented identifiers for the purpose of finding a match. 847 4. When checking a reference identifier against a presented 848 identifier, the client matches the source domain of the 849 identifiers and, optionally, their service type. 851 Naturally, in addition to checking identifiers, a client might 852 complete further checks to ensure that the server is authorized to 853 provide the requested service. However, such checking is not a 854 matter of verifying the application service identity presented in a 855 certificate, and therefore methods for doing so (e.g., consulting 856 local policy information) are out of scope for this document. 858 4.2. Constructing a List of Reference Identifiers 860 4.2.1. Rules 862 The client MUST construct a list of acceptable reference identifiers, 863 and MUST do so independently of the identifiers presented by the 864 service. 866 The inputs used by the client to construct its list of reference 867 identifiers might be a URI that a user has typed into an interface 868 (e.g., an HTTPS URL for a web site), configured account information 869 (e.g., the domain name of a particular host or URI used for 870 retrieving information or connecting to a network, which might be 871 different from the server portion of the user's account name), a 872 hyperlink in a web page that triggers a browser to retrieve a media 873 object or script, or some other combination of information that can 874 yield a source domain and a service type. 876 The client might need to extract the source domain and service type 877 from the input(s) it has received. The extracted data MUST include 878 only information that can be securely parsed out of the inputs (e.g., 879 extracting the fully-qualified DNS domain name from the authority 880 component of a URI or extracting the service type from the scheme of 881 a URI) or information for which the extraction is performed in a 882 manner that is not subject to subversion by network attackers (e.g., 883 pulling the data from a delegated domain that is explicitly 884 established via client or system configuration, resolving the data 885 via [DNSSEC], or obtaining the data from a third-party domain mapping 886 service in which a human user has explicitly placed trust and with 887 which the client communicates over a connection that provides both 888 mutual authentication and integrity checking). 890 Each reference identifier in the list SHOULD be based on the source 891 domain and SHOULD NOT be based on a derived domain (e.g., a host name 892 or domain name discovered through DNS resolution of the source 893 domain). This rule is important because only a match between the 894 user inputs and a presented identifier enables the client to be sure 895 that the certificate can legitimately be used to secure the 896 connection. There is only one scenario in which it is acceptable for 897 an interactive client to override the recommendation in this rule and 898 therefore connect to a domain name other than the source domain: 899 because a human user has "pinned" the application service's 900 certificate to the alternative domain name as further discussed under 901 Section 4.6.4 and Section 5.1. In this case, the inputs used by the 902 client to construct its list of reference identifiers might include 903 more than one fully-qualified DNS domain name, i.e., both (a) the 904 source domain and (b) the alternative domain contained in the pinned 905 certificate. 907 Using the combination of fully-qualified DNS domain name(s) and 908 service type, the client constructs a list of reference identifiers 909 in accordance with the following rules: 911 o The list MUST include a DNS-ID. A reference identifier of type 912 DNS-ID can be directly constructed from a fully-qualified DNS 913 domain name that is (a) contained in or securely derived from the 914 inputs (i.e., the source domain), or (b) explicitly associated 915 with the source domain by means of user configuration (i.e., a 916 derived domain). 918 o If a server for the service type is typically discovered by means 919 of DNS SRV records, then the list SHOULD include an SRV-ID. 921 o If a server for the service type is typically associated with a 922 URI, then the list SHOULD include a URI-ID. 924 o The list MAY include a CN-ID, mainly for the sake of backward 925 compatibility with existing infrastructure. 927 The client does not need to construct the foregoing identifiers in 928 the actual formats found in a certificate (e.g., as ASN.1 types), it 929 only needs to construct the functional equivalent of such identifiers 930 for matching purposes. 932 Security Note: A client MUST NOT construct a reference identifier 933 corresponding to Relative Distinguished Names (RDNs) other than 934 those of type Common Name and MUST NOT check for RDNs other than 935 those of type Common Name in the presented identifiers. 937 4.2.2. Examples 939 A web browser that is connecting via HTTPS to the website at 940 "www.example.com" might have two reference identifiers: a DNS-ID of 941 "www.example.com" and, as a fallback, a CN-ID of "www.example.com". 943 A mail user agent that is connecting via IMAP to the email service at 944 "mail.example.net" might have two reference identifiers: an SRV-ID of 945 "_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of 946 "mail.example.net". 948 An instant messaging (IM) client that is connecting via XMPP to the 949 IM service at "im.example.org" might have three reference 950 identifiers: an SRV-ID of "_xmpp.im.example.org", a DNS-ID of 951 "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" 952 (see [XMPP]). 954 4.3. Preparing to Seeking a Match 956 Once the client has constructed its list of reference identifiers and 957 has received the server's presented identifiers in the form of a PKIX 958 certificate, the client checks its reference identifiers against the 959 presented identifiers for the purpose of finding a match. The search 960 fails if the client exhausts its list of reference identifiers 961 without finding a match. The search succeeds if any presented 962 identifier matches one of the reference identifiers, at which point 963 the client SHOULD stop the search. 965 Implementation Note: A client might be configured to perform 966 multiple searches, i.e., to match more than one reference 967 identifier; although such behavior is not forbidden by this 968 document, rules for matching multiple reference identifiers are a 969 matter for implementation or future specification. 971 Security Note: A client MUST NOT seek a match for a reference 972 identifier of CN-ID if the presented identifiers include a DNS-ID, 973 SRV-ID, URI-ID, or any application-specific identifier types 974 supported by the client. 976 Before applying the comparison rules provided in the following 977 sections, the client might need to split the reference identifier 978 into its DNS domain name portion and its application type portion, as 979 follows: 981 o A reference identifier of type DNS-ID does not include an 982 application type portion and thus can be used directly as the DNS 983 domain name for comparison purposes. 985 o A reference identifier of type CN-ID also does not include an 986 application type portion and thus can be used directly as the DNS 987 domain name for comparison purposes; note that this document 988 specifies that a CN-ID always contains a string whose form matches 989 that of a DNS domain name (thus differentiating a CN-ID from a 990 Common Name containing a human-friendly name). 992 o For a reference identifier of type SRV-ID, the DNS domain name 993 portion is the Name and the application type portion is the 994 Service. 996 o For a reference identifier of type URI-ID, the DNS domain name 997 portion is the reg-name part of the authority component and the 998 application type portion is the scheme name matching the [ABNF] 999 "scheme" rule from [URI] (not including the ':' separator); note 1000 that this document specifies that a URI-ID always contains an 1001 authority component whose host subcomponent contains a reg-name 1002 (thus differentiating a URI-ID from a uniformResourceIdentifier 1003 entry that contains an IP address or that does not contain an 1004 authority component), and that extraction of the reg-name might 1005 necessitate normalization of the URI (as explained in [URI]). 1007 Detailed comparison rules for matching the DNS domain name portion 1008 and application type portion of the reference identifier are provided 1009 in the following sections. 1011 4.4. Verifying the DNS Domain Name Portion 1013 The client MUST match the DNS domain name portion of a reference 1014 identifier according to the following rules (and SHOULD also check 1015 the service type as described under Section 4.5). The rules differ 1016 depending on whether the domain to be checked is a "traditional 1017 domain name" or an "internationalized domain name" (as defined under 1018 Section 2.2). Furthermore, if the client supports presented 1019 identifiers that contain the wildcard character '*', we define a 1020 supplemental rule for so-called "wildcard certificates". We also 1021 specify the circumstances under which it is acceptable to check the 1022 "CN-ID" identifier type. 1024 4.4.1. Checking of Traditional Domain Names 1026 If the DNS domain name portion of a reference identifier is a 1027 "traditional domain name", then matching of the reference identifier 1028 against the presented identifier is performed by comparing the set of 1029 domain name components using a case-insensitive ASCII comparison, as 1030 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 1031 to "www.example.com" for comparison purposes). Each label MUST match 1032 in order for the names to be considered to match, except as 1033 supplemented by the rule about checking of wildcard labels 1034 (Section 4.4.3). 1036 4.4.2. Checking of Internationalized Domain Names 1038 If the DNS domain name portion of a reference identifier is an 1039 internationalized domain name, then an implementation MUST convert 1040 every label in the domain name to an A-label (as described in 1041 [IDNA-DEFS]) before checking the domain name. In accordance with 1042 [IDNA-PROTO], a pair of A-labels MUST be compared as case-insensitive 1043 ASCII. Each label MUST match in order for the names to be considered 1044 to match, except as supplemented by the rule about checking of 1045 wildcard labels (Section 4.4.3). 1047 4.4.3. Checking of Wildcard Certificates 1049 A client employing this specification's rules MAY match the reference 1050 identifier against a presented identifier whose DNS domain name 1051 portion contains the wildcard character '*' as part or all of a label 1052 (following the definition of "label" from [DNS]). For information 1053 regarding the security characteristics of wildcard certificates, see 1054 Section 5.2. 1056 If a client matches the reference identifier against a presented 1057 identifier whose DNS domain name portion contains the wildcard 1058 character '*', the following rules apply: 1060 1. The client SHOULD NOT attempt to match a presented identifier in 1061 which the wildcard character comprises a label other than the 1062 left-most label (e.g., do not match bar.*.example.net). 1064 2. If the wildcard character is the only character of the left-most 1065 label in the presented identifier, the client SHOULD NOT compare 1066 against anything but the left-most label of the reference 1067 identifier (e.g., *.example.com would match foo.example.com but 1068 not bar.foo.example.com or example.com). 1070 3. The client MAY match a presented identifier in which the wildcard 1071 character is not the only character of the label (e.g., 1072 baz*.example.net and *baz.example.net and b*z.example.net would 1073 be taken to match baz1.example.net and foobaz.example.net and 1074 buzz.example.net, respectively). 1076 4.4.4. Checking of Common Names 1078 As noted, a client MUST NOT seek a match for a reference identifier 1079 of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, 1080 URI-ID, or any application-specific identifier types supported by the 1081 client. 1083 Therefore, if and only if the presented identifiers do not include a 1084 DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types 1085 supported by the client, then the client MAY as a last resort check 1086 for a string whose form matches that of a fully-qualified DNS domain 1087 name in the CN-ID. If the client chooses to compare a reference 1088 identifier of type CN-ID against that string, it MUST follow the 1089 comparison rules for the DNS domain name portion of an identifier of 1090 type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4.1, 1091 Section 4.4.2, and Section 4.4.3. 1093 4.5. Verifying the Application Type Portion 1095 When checking identifiers of type SRV-ID and URI-ID, a client SHOULD 1096 check not only the domain name but also the service type of the 1097 service to which it connects. This is a best practice because 1098 typically a client is not designed to connect to all kinds of 1099 services using all possible application protocols, but instead is 1100 designed to connect to one kind of service, such as websites, email 1101 services, or instant messaging services. 1103 The service type is verified by means of either an SRV-ID or URI-ID. 1105 4.5.1. SRV-ID 1107 The service name portion of an SRV-ID (e.g., "xmpp") MUST be matched 1108 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 1109 that the "_" character is prepended to the service identifier in DNS 1110 SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to 1111 be included in any comparison. 1113 4.5.2. URI-ID 1115 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1116 a case-insensitive manner, in accordance with [URI]. Note that the 1117 ":" character is a separator between the scheme name and the rest of 1118 the URI, and thus does not need to be included in any comparison. 1120 4.6. Outcome 1122 The outcome of the checking procedure is one of the following cases. 1124 4.6.1. Case #1: Match Found 1126 If the client has found a presented identifier that matches a 1127 reference identifier, matching has succeeded. In this case, the 1128 client MUST use the matched reference identifier as the validated 1129 identity of the application service. 1131 4.6.2. Case #2: No Match Found, Pinned Certificate 1133 If the client does not find a presented identifier matching any of 1134 the reference identifiers but the client has previously pinned the 1135 application service's certificate to one of the reference identifiers 1136 in the list it constructed for this connection attempt (as "pinning" 1137 is explained under Section 1.5), and the presented certificate 1138 matches the pinned certificate (including the context as described 1139 under Section 5.1), then the service identity check succeeds. 1141 4.6.3. Case #3: No Match Found, No Pinned Certificate 1143 If the client does not find a presented identifier matching any of 1144 the reference identifiers and the client has not previously pinned 1145 the certificate to one of the reference identifiers in the list it 1146 constructed for this connection attempt, then the client MUST proceed 1147 as described under Section 4.6.4. 1149 4.6.4. Fallback 1151 If the client is an interactive client that is directly controlled by 1152 a human user, then it SHOULD inform the user of the identity mismatch 1153 and automatically terminate the connection with a bad certificate 1154 error; this behavior is preferable because it prevents users from 1155 inadvertently bypassing security protections in hostile situations. 1157 Security Note: Some interactive clients give advanced users the 1158 option of proceeding with acceptance despite the identity 1159 mismatch, thereby "pinning" the certificate to one of the 1160 reference identifiers in the list constructed by the client for 1161 this connection attempt. Although this behavior can be 1162 appropriate in certain specialized circumstances, in general it 1163 ought to be exposed only to advanced users. Even then it needs to 1164 be handled with extreme caution, for example by first encouraging 1165 even an advanced user to terminate the connection and, if the 1166 advanced user chooses to proceed anyway, by forcing the user to 1167 view the entire certification path and only then allowing the user 1168 to pin the certificate (on a temporary or permanent basis, at the 1169 user's option). 1171 Otherwise, if the client is an automated application not directly 1172 controlled by a human user, then it SHOULD terminate the connection 1173 with a bad certificate error and log the error appropriately. An 1174 automated application MAY provide a configuration setting that 1175 disables this behavior, but MUST enable the behavior by default. 1177 5. Security Considerations 1179 5.1. Pinned Certificates 1181 As defined under Section 1.5, a certificate is said to be "pinned" to 1182 a DNS domain name when a user has explicitly chosen to associate a 1183 service's certificate with the that domain name despite the fact that 1184 the certificate contains some other DNS domain name (e.g., the user 1185 has explicitly approved "apps.example.net" as a domain associated 1186 with a source domain of "example.com"). The cached name association 1187 MUST take account of both the certificate presented and the context 1188 in which it was accepted or configured (where the "context" includes 1189 the chain of certificates from the presented certificate to the trust 1190 anchor, the source domain, the service type, the service's derived 1191 domain and port number, and any other relevant information provided 1192 by the user or associated by the client). 1194 5.2. Wildcard Certificates 1196 This document states that the wildcard character '*' SHOULD NOT be 1197 included in presented identifiers but MAY be checked by application 1198 clients (mainly for the sake of backward compatibility with existing 1199 infrastructure); as a result, the rules provided in this document are 1200 more restrictive than the rules for many existing application 1201 technologies (see Appendix A). Several security considerations 1202 justify tightening the rules: 1204 o The inclusion of the wildcard character in certificates has led to 1205 homograph attacks involving non-ASCII characters that look similar 1206 to characters commonly included in HTTPS URLs, such as "/" and 1207 "?"; for discussion, see for example [Defeating-SSL] (beginning at 1208 slide 91). 1210 o The ability to obtain a certificate containing the wildcard 1211 character might broaden the range of applications services that an 1212 attacker could forge, thus increasing (a) the chances that 1213 attackers would attempt to steal credentials needed for obtaining 1214 certificates and (b) the potential damage that would result from a 1215 successful attack. 1217 o Specifications for existing application technologies are not clear 1218 about whether the wildcard character is allowed only as the 1219 complete left-most label (e.g., *.example.com), some fragment of 1220 the left-most label (e.g., foo*.example.com, f*o.example.com, or 1221 *oo.example.com), or even all or part of a label other than the 1222 left-most label (e.g., www.*.example.com or www.foo*.example.com); 1223 nor are they clear about whether a presented identifier can 1224 include more than one instance of the wildcard character (e.g., 1225 f*b*r.example.com or *.*.example.com). These ambiguities might 1226 introduce exploitable differences in identity checking behavior 1227 among client implementations and necessitate overly complex and 1228 inefficient identity checking algorithms. 1230 Notwithstanding the foregoing security considerations, profiles of 1231 this specification can legitimately encourage continued support for 1232 the wildcard character if they have good reasons to do so, such as 1233 backward compatibility with deployed infrastructure. 1235 5.3. Internationalized Domain Names 1237 Allowing internationalized domain names can lead to the inclusion of 1238 visually similar (so-called "confusable") characters in certificates; 1239 for discussion, see for example [IDNA-DEFS]. 1241 6. IANA Considerations 1243 This document specifies no actions for the IANA. 1245 7. References 1246 7.1. Normative References 1248 [DNS] Mockapetris, P., "Domain names - implementation and 1249 specification", STD 13, RFC 1035, November 1987. 1251 [DNS-CONCEPTS] 1252 Mockapetris, P., "Domain names - concepts and facilities", 1253 STD 13, RFC 1034, November 1987. 1255 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1256 specifying the location of services (DNS SRV)", RFC 2782, 1257 February 2000. 1259 [IDNA-DEFS] 1260 Klensin, J., "Internationalized Domain Names for 1261 Applications (IDNA): Definitions and Document Framework", 1262 RFC 5890, August 2010. 1264 [IDNA-PROTO] 1265 Klensin, J., "Internationalized Domain Names in 1266 Applications (IDNA): Protocol", RFC 5891, August 2010. 1268 [KEYWORDS] 1269 Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, March 1997. 1272 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 1273 (LDAP): String Representation of Distinguished Names", 1274 RFC 4514, June 2006. 1276 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1277 Housley, R., and W. Polk, "Internet X.509 Public Key 1278 Infrastructure Certificate and Certificate Revocation List 1279 (CRL) Profile", RFC 5280, May 2008. 1281 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1282 Subject Alternative Name for Expression of Service Name", 1283 RFC 4985, August 2007. 1285 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1286 Resource Identifier (URI): Generic Syntax", STD 66, 1287 RFC 3986, January 2005. 1289 7.2. Informative References 1291 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1292 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1294 [Defeating-SSL] 1295 Marlinspike, M., "New Tricks for Defeating SSL in 1296 Practice", February 2009, . 1300 [DNS-CASE] 1301 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 1302 Clarification", RFC 4343, January 2006. 1304 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1305 Rose, "DNS Security Introduction and Requirements", 1306 RFC 4033, March 2005. 1308 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1309 Security", RFC 4347, April 2006. 1311 [EMAIL-SRV] 1312 Daboo, C., "Use of SRV Records for Locating Email 1313 Submission/Access services", draft-daboo-srv-email-05 1314 (work in progress), May 2010. 1316 [EV-CERTS] 1317 CA/Browser Forum, "Guidelines For The Issuance And 1318 Management Of Extended Validation Certificates", 1319 October 2009, 1320 . 1322 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General Internet 1323 Signalling Transport", RFC 5971, October 2010. 1325 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1326 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1327 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1329 [HTTP-TLS] 1330 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1332 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1333 4rev1", RFC 3501, March 2003. 1335 [IDNA2003] 1336 Faltstrom, P., Hoffman, P., and A. Costello, 1337 "Internationalizing Domain Names in Applications (IDNA)", 1338 RFC 3490, March 2003. 1340 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1341 September 1981. 1343 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1344 (IPv6) Specification", RFC 2460, December 1998. 1346 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1347 Internet Protocol", RFC 4301, December 2005. 1349 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 1350 (LDAP): The Protocol", RFC 4511, June 2006. 1352 [LDAP-AUTH] 1353 Harrison, R., "Lightweight Directory Access Protocol 1354 (LDAP): Authentication Methods and Security Mechanisms", 1355 RFC 4513, June 2006. 1357 [LDAP-SCHEMA] 1358 Sciberras, A., "Lightweight Directory Access Protocol 1359 (LDAP): Schema for User Applications", RFC 4519, 1360 June 2006. 1362 [LDAP-TLS] 1363 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 1364 Directory Access Protocol (v3): Extension for Transport 1365 Layer Security", RFC 2830, May 2000. 1367 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1368 Part Three: The Domain Name System (DNS) Database", 1369 RFC 3403, October 2002. 1371 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1372 December 2006. 1374 [NETCONF-SSH] 1375 Wasserman, M. and T. Goddard, "Using the NETCONF 1376 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 1377 December 2006. 1379 [NETCONF-TLS] 1380 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1381 RFC 5539, May 2009. 1383 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1384 RFC 3977, October 2006. 1386 [NNTP-TLS] 1387 Murchison, K., Vinocur, J., and C. Newman, "Using 1388 Transport Layer Security (TLS) with Network News Transfer 1389 Protocol (NNTP)", RFC 4642, October 2006. 1391 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1392 Adams, "X.509 Internet Public Key Infrastructure Online 1393 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1395 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1396 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1398 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1399 STD 53, RFC 1939, May 1996. 1401 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1402 E. Lear, "Address Allocation for Private Internets", 1403 BCP 5, RFC 1918, February 1996. 1405 [PKIX-OLD] 1406 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1407 X.509 Public Key Infrastructure Certificate and CRL 1408 Profile", RFC 2459, January 1999. 1410 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1411 Service Location Using SRV RRs and the Dynamic Delegation 1412 Discovery Service (DDDS)", RFC 3958, January 2005. 1414 [SECTERMS] 1415 Shirey, R., "Internet Security Glossary, Version 2", 1416 RFC 4949, August 2007. 1418 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1419 A., Peterson, J., Sparks, R., Handley, M., and E. 1420 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1421 June 2002. 1423 [SIP-CERTS] 1424 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1425 Certificates in the Session Initiation Protocol (SIP)", 1426 RFC 5922, June 2010. 1428 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1429 October 2008. 1431 [SMTP-AUTH] 1432 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1433 for Authentication", RFC 4954, July 2007. 1435 [SMTP-TLS] 1436 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1437 Transport Layer Security", RFC 3207, February 2002. 1439 [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An 1440 Architecture for Describing Simple Network Management 1441 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1442 December 2002. 1444 [SNMP-TLS] 1445 Hardaker, W., "Transport Layer Security (TLS) Transport 1446 Model for the Simple Network Management Protocol (SNMP)", 1447 RFC 5953, August 2010. 1449 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1451 [SYSLOG-DTLS] 1452 Salowey, J., Petch, T., Gerhards, R., and H. Feng, 1453 "Datagram Transport Layer Security (DTLS) Transport 1454 Mapping for Syslog", RFC 6012, October 2010. 1456 [SYSLOG-TLS] 1457 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1458 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1459 March 2009. 1461 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1462 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1464 [US-ASCII] 1465 American National Standards Institute, "Coded Character 1466 Set - 7-bit American Standard Code for Information 1467 Interchange", ANSI X3.4, 1986. 1469 [USINGTLS] 1470 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1471 RFC 2595, June 1999. 1473 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1474 Interface Guidelines", World Wide Web Consortium 1475 LastCall WD-wsc-ui-20100309, March 2010, 1476 . 1478 [X.500] International Telecommunications Union, "Information 1479 Technology - Open Systems Interconnection - The Directory: 1480 Overview of concepts, models and services", ITU- 1481 T Recommendation X.500, ISO Standard 9594-1, August 2005. 1483 [X.501] International Telecommunications Union, "Information 1484 Technology - Open Systems Interconnection - The Directory: 1485 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1486 August 2005. 1488 [X.509] International Telecommunications Union, "Information 1489 Technology - Open Systems Interconnection - The Directory: 1490 Public-key and attribute certificate frameworks", ITU- 1491 T Recommendation X.509, ISO Standard 9594-8, August 2005. 1493 [X.520] International Telecommunications Union, "Information 1494 Technology - Open Systems Interconnection - The Directory: 1495 Selected attribute types", ITU-T Recommendation X.509, 1496 ISO Standard 9594-6, August 2005. 1498 [X.690] International Telecommunications Union, "Information 1499 Technology - ASN.1 encoding rules: Specification of Basic 1500 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1501 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1502 X.690, ISO Standard 8825-1, August 2008. 1504 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1505 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-19 (work 1506 in progress), November 2010. 1508 [XMPP-OLD] 1509 Saint-Andre, P., Ed., "Extensible Messaging and Presence 1510 Protocol (XMPP): Core", RFC 3920, October 2004. 1512 Appendix A. Prior Art 1514 (This section is non-normative.) 1516 The recommendations in this document are an abstraction from 1517 recommendations in specifications for a wide range of application 1518 protocols. For the purpose of comparison and to delineate the 1519 history of thinking about application service identity verification 1520 within the IETF, this informative section gathers together prior art 1521 by including the exact text from various RFCs (the only modifications 1522 are changes to the names of several references to maintain coherence 1523 with the main body of this document, and the elision of irrelevant 1524 text as marked by the characters "[...]"). 1526 A.1. IMAP, POP3, and ACAP (1999) 1528 In 1999, [USINGTLS] specified the following text regarding 1529 application service identity verification in IMAP, POP3, and ACAP: 1531 ###### 1533 2.4. Server Identity Check 1534 During the TLS negotiation, the client MUST check its understanding 1535 of the server hostname against the server's identity as presented in 1536 the server Certificate message, in order to prevent man-in-the-middle 1537 attacks. Matching is performed according to these rules: 1539 o The client MUST use the server hostname it used to open the 1540 connection as the value to compare against the server name as 1541 expressed in the server certificate. The client MUST NOT use any 1542 form of the server hostname derived from an insecure remote source 1543 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1544 o If a subjectAltName extension of type dNSName is present in the 1545 certificate, it SHOULD be used as the source of the server's 1546 identity. 1547 o Matching is case-insensitive. 1548 o A "*" wildcard character MAY be used as the left-most name 1549 component in the certificate. For example, *.example.com would 1550 match a.example.com, foo.example.com, etc. but would not match 1551 example.com. 1552 o If the certificate contains multiple names (e.g. more than one 1553 dNSName field), then a match with any one of the fields is 1554 considered acceptable. 1556 If the match fails, the client SHOULD either ask for explicit user 1557 confirmation, or terminate the connection and indicate the server's 1558 identity is suspect. 1560 ###### 1562 A.2. HTTP (2000) 1564 In 2000, [HTTP-TLS] specified the following text regarding 1565 application service identity verification in HTTP: 1567 ###### 1569 3.1. Server Identity 1571 In general, HTTP/TLS requests are generated by dereferencing a URI. 1572 As a consequence, the hostname for the server is known to the client. 1573 If the hostname is available, the client MUST check it against the 1574 server's identity as presented in the server's Certificate message, 1575 in order to prevent man-in-the-middle attacks. 1577 If the client has external information as to the expected identity of 1578 the server, the hostname check MAY be omitted. (For instance, a 1579 client may be connecting to a machine whose address and hostname are 1580 dynamic but the client knows the certificate that the server will 1581 present.) In such cases, it is important to narrow the scope of 1582 acceptable certificates as much as possible in order to prevent man 1583 in the middle attacks. In special cases, it may be appropriate for 1584 the client to simply ignore the server's identity, but it must be 1585 understood that this leaves the connection open to active attack. 1587 If a subjectAltName extension of type dNSName is present, that MUST 1588 be used as the identity. Otherwise, the (most specific) Common Name 1589 field in the Subject field of the certificate MUST be used. Although 1590 the use of the Common Name is existing practice, it is deprecated and 1591 Certification Authorities are encouraged to use the dNSName instead. 1593 Matching is performed using the matching rules specified by 1594 [PKIX-OLD]. If more than one identity of a given type is present in 1595 the certificate (e.g., more than one dNSName name, a match in any one 1596 of the set is considered acceptable.) Names may contain the wildcard 1597 character * which is considered to match any single domain name 1598 component or component fragment. E.g., *.a.com matches foo.a.com but 1599 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1601 In some cases, the URI is specified as an IP address rather than a 1602 hostname. In this case, the iPAddress subjectAltName must be present 1603 in the certificate and must exactly match the IP in the URI. 1605 If the hostname does not match the identity in the certificate, user 1606 oriented clients MUST either notify the user (clients MAY give the 1607 user the opportunity to continue with the connection in any case) or 1608 terminate the connection with a bad certificate error. Automated 1609 clients MUST log the error to an appropriate audit log (if available) 1610 and SHOULD terminate the connection (with a bad certificate error). 1611 Automated clients MAY provide a configuration setting that disables 1612 this check, but MUST provide a setting which enables it. 1614 Note that in many cases the URI itself comes from an untrusted 1615 source. The above-described check provides no protection against 1616 attacks where this source is compromised. For example, if the URI 1617 was obtained by clicking on an HTML page which was itself obtained 1618 without using HTTP/TLS, a man in the middle could have replaced the 1619 URI. In order to prevent this form of attack, users should carefully 1620 examine the certificate presented by the server to determine if it 1621 meets their expectations. 1623 ###### 1625 A.3. LDAP (2000/2006) 1627 In 2000, [LDAP-TLS] specified the following text regarding 1628 application service identity verification in LDAP: 1630 ###### 1632 3.6. Server Identity Check 1634 The client MUST check its understanding of the server's hostname 1635 against the server's identity as presented in the server's 1636 Certificate message, in order to prevent man-in-the-middle attacks. 1638 Matching is performed according to these rules: 1640 o The client MUST use the server hostname it used to open the LDAP 1641 connection as the value to compare against the server name as 1642 expressed in the server's certificate. The client MUST NOT use 1643 the server's canonical DNS name or any other derived form of name. 1644 o If a subjectAltName extension of type dNSName is present in the 1645 certificate, it SHOULD be used as the source of the server's 1646 identity. 1647 o Matching is case-insensitive. 1648 o The "*" wildcard character is allowed. If present, it applies 1649 only to the left-most name component. 1651 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 1652 bar.com. If more than one identity of a given type is present in the 1653 certificate (e.g. more than one dNSName name), a match in any one of 1654 the set is considered acceptable. 1656 If the hostname does not match the dNSName-based identity in the 1657 certificate per the above check, user-oriented clients SHOULD either 1658 notify the user (clients MAY give the user the opportunity to 1659 continue with the connection in any case) or terminate the connection 1660 and indicate that the server's identity is suspect. Automated 1661 clients SHOULD close the connection, returning and/or logging an 1662 error indicating that the server's identity is suspect. 1664 Beyond the server identity checks described in this section, clients 1665 SHOULD be prepared to do further checking to ensure that the server 1666 is authorized to provide the service it is observed to provide. The 1667 client MAY need to make use of local policy information. 1669 ###### 1671 In 2006, [LDAP-AUTH] specified the following text regarding 1672 application service identity verification in LDAP: 1674 ###### 1676 3.1.3. Server Identity Check 1677 In order to prevent man-in-the-middle attacks, the client MUST verify 1678 the server's identity (as presented in the server's Certificate 1679 message). In this section, the client's understanding of the 1680 server's identity (typically the identity used to establish the 1681 transport connection) is called the "reference identity". 1683 The client determines the type (e.g., DNS name or IP address) of the 1684 reference identity and performs a comparison between the reference 1685 identity and each subjectAltName value of the corresponding type 1686 until a match is produced. Once a match is produced, the server's 1687 identity has been verified, and the server identity check is 1688 complete. Different subjectAltName types are matched in different 1689 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 1690 various subjectAltName types. 1692 The client may map the reference identity to a different type prior 1693 to performing a comparison. Mappings may be performed for all 1694 available subjectAltName types to which the reference identity can be 1695 mapped; however, the reference identity should only be mapped to 1696 types for which the mapping is either inherently secure (e.g., 1697 extracting the DNS name from a URI to compare with a subjectAltName 1698 of type dNSName) or for which the mapping is performed in a secure 1699 manner (e.g., using [DNSSEC], or using user- or admin-configured 1700 host-to-address/address-to-host lookup tables). 1702 The server's identity may also be verified by comparing the reference 1703 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 1704 Relative Distinguished Name (RDN) of the subject field of the 1705 server's certificate (where "last" refers to the DER-encoded order, 1706 not the order of presentation in a string representation of DER- 1707 encoded data). This comparison is performed using the rules for 1708 comparison of DNS names in Section 3.1.3.1, below, with the exception 1709 that no wildcard matching is allowed. Although the use of the Common 1710 Name value is existing practice, it is deprecated, and Certification 1711 Authorities are encouraged to provide subjectAltName values instead. 1712 Note that the TLS implementation may represent DNs in certificates 1713 according to X.500 or other conventions. For example, some X.500 1714 implementations order the RDNs in a DN using a left-to-right (most 1715 significant to least significant) convention instead of LDAP's right- 1716 to-left convention. 1718 If the server identity check fails, user-oriented clients SHOULD 1719 either notify the user (clients may give the user the opportunity to 1720 continue with the LDAP session in this case) or close the transport 1721 connection and indicate that the server's identity is suspect. 1722 Automated clients SHOULD close the transport connection and then 1723 return or log an error indicating that the server's identity is 1724 suspect or both. 1726 Beyond the server identity check described in this section, clients 1727 should be prepared to do further checking to ensure that the server 1728 is authorized to provide the service it is requested to provide. The 1729 client may need to make use of local policy information in making 1730 this determination. 1732 3.1.3.1. Comparison of DNS Names 1734 If the reference identity is an internationalized domain name, 1735 conforming implementations MUST convert it to the ASCII Compatible 1736 Encoding (ACE) format as specified in Section 4 of RFC 3490 1737 [IDNA2003] before comparison with subjectAltName values of type 1738 dNSName. Specifically, conforming implementations MUST perform the 1739 conversion operation specified in Section 4 of RFC 3490 as follows: 1741 o in step 1, the domain name SHALL be considered a "stored string"; 1742 o in step 3, set the flag called "UseSTD3ASCIIRules"; 1743 o in step 4, process each label with the "ToASCII" operation; and 1744 o in step 5, change all label separators to U+002E (full stop). 1746 After performing the "to-ASCII" conversion, the DNS labels and names 1747 MUST be compared for equality according to the rules specified in 1748 Section 3 of RFC3490. 1750 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 1751 values of type dNSName, and then only as the left-most (least 1752 significant) DNS label in that value. This wildcard matches any 1753 left-most DNS label in the server name. That is, the subject 1754 *.example.com matches the server names a.example.com and 1755 b.example.com, but does not match example.com or a.b.example.com. 1757 3.1.3.2. Comparison of IP Addresses 1759 When the reference identity is an IP address, the identity MUST be 1760 converted to the "network byte order" octet string representation 1761 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 1762 string will contain exactly four octets. For IP Version 6, as 1763 specified in RFC 2460, the octet string will contain exactly sixteen 1764 octets. This octet string is then compared against subjectAltName 1765 values of type iPAddress. A match occurs if the reference identity 1766 octet string and value octet strings are identical. 1768 3.1.3.3. Comparison of Other subjectName Types 1770 Client implementations MAY support matching against subjectAltName 1771 values of other types as described in other documents. 1773 ###### 1775 A.4. SMTP (2002/2007) 1777 In 2002, [SMTP-TLS] specified the following text regarding 1778 application service identity verification in SMTP: 1780 ###### 1782 4.1 Processing After the STARTTLS Command 1784 [...] 1786 The decision of whether or not to believe the authenticity of the 1787 other party in a TLS negotiation is a local matter. However, some 1788 general rules for the decisions are: 1790 o A SMTP client would probably only want to authenticate an SMTP 1791 server whose server certificate has a domain name that is the 1792 domain name that the client thought it was connecting to. 1794 [...] 1796 ###### 1798 In 2006, [SMTP-AUTH] specified the following text regarding 1799 application service identity verification in SMTP: 1801 ###### 1803 14. Additional Requirements When Using SASL PLAIN over TLS 1805 [...] 1807 After a successful [TLS] negotiation, the client MUST check its 1808 understanding of the server hostname against the server's identity as 1809 presented in the server Certificate message, in order to prevent man- 1810 in-the-middle attacks. If the match fails, the client MUST NOT 1811 attempt to authenticate using the SASL PLAIN mechanism. Matching is 1812 performed according to the following rules: 1814 The client MUST use the server hostname it used to open the 1815 connection as the value to compare against the server name as 1816 expressed in the server certificate. The client MUST NOT use any 1817 form of the server hostname derived from an insecure remote source 1818 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1819 If a subjectAltName extension of type dNSName is present in the 1820 certificate, it SHOULD be used as the source of the server's 1821 identity. 1823 Matching is case-insensitive. 1824 A "*" wildcard character MAY be used as the leftmost name 1825 component in the certificate. For example, *.example.com would 1826 match a.example.com, foo.example.com, etc., but would not match 1827 example.com. 1828 If the certificate contains multiple names (e.g., more than one 1829 dNSName field), then a match with any one of the fields is 1830 considered acceptable. 1832 ###### 1834 A.5. XMPP (2004) 1836 In 2004, [XMPP-OLD] specified the following text regarding 1837 application service identity verification in XMPP: 1839 ###### 1841 14.2. Certificate Validation 1843 When an XMPP peer communicates with another peer securely, it MUST 1844 validate the peer's certificate. There are three possible cases: 1846 Case #1: The peer contains an End Entity certificate which appears 1847 to be certified by a certification path terminating in a trust 1848 anchor (as described in Section 6.1 of [PKIX]). 1849 Case #2: The peer certificate is certified by a Certificate 1850 Authority not known to the validating peer. 1851 Case #3: The peer certificate is self-signed. 1853 In Case #1, the validating peer MUST do one of two things: 1854 1. Verify the peer certificate according to the rules of [PKIX]. 1855 The certificate SHOULD then be checked against the expected 1856 identity of the peer following the rules described in [HTTP-TLS], 1857 except that a subjectAltName extension of type "xmpp" MUST be 1858 used as the identity if present. If one of these checks fails, 1859 user-oriented clients MUST either notify the user (clients MAY 1860 give the user the opportunity to continue with the connection in 1861 any case) or terminate the connection with a bad certificate 1862 error. Automated clients SHOULD terminate the connection (with a 1863 bad certificate error) and log the error to an appropriate audit 1864 log. Automated clients MAY provide a configuration setting that 1865 disables this check, but MUST provide a setting that enables it. 1866 2. The peer SHOULD show the certificate to a user for approval, 1867 including the entire certification path. The peer MUST cache the 1868 certificate (or some non-forgeable representation such as a 1869 hash). In future connections, the peer MUST verify that the same 1870 certificate was presented and MUST notify the user if it has 1871 changed. 1873 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 1875 ###### 1877 At the time of this writing, [XMPP] refers to this document for rules 1878 regarding application service identity verification in XMPP. 1880 A.6. NNTP (2006) 1882 In 2006, [NNTP-TLS] specified the following text regarding 1883 application service identity verification in NNTP: 1885 ###### 1887 5. Security Considerations 1889 [...] 1891 During the TLS negotiation, the client MUST check its understanding 1892 of the server hostname against the server's identity as presented in 1893 the server Certificate message, in order to prevent man-in-the-middle 1894 attacks. Matching is performed according to these rules: 1896 o The client MUST use the server hostname it used to open the 1897 connection (or the hostname specified in TLS "server_name" 1898 extension [TLS]) as the value to compare against the server name 1899 as expressed in the server certificate. The client MUST NOT use 1900 any form of the server hostname derived from an insecure remote 1901 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1902 done. 1903 o If a subjectAltName extension of type dNSName is present in the 1904 certificate, it SHOULD be used as the source of the server's 1905 identity. 1906 o Matching is case-insensitive. 1907 o A "*" wildcard character MAY be used as the left-most name 1908 component in the certificate. For example, *.example.com would 1909 match a.example.com, foo.example.com, etc., but would not match 1910 example.com. 1911 o If the certificate contains multiple names (e.g., more than one 1912 dNSName field), then a match with any one of the fields is 1913 considered acceptable. 1915 If the match fails, the client SHOULD either ask for explicit user 1916 confirmation or terminate the connection with a QUIT command and 1917 indicate the server's identity is suspect. 1919 Additionally, clients MUST verify the binding between the identity of 1920 the servers to which they connect and the public keys presented by 1921 those servers. Clients SHOULD implement the algorithm in Section 6 1922 of [PKIX] for general certificate validation, but MAY supplement that 1923 algorithm with other validation methods that achieve equivalent 1924 levels of verification (such as comparing the server certificate 1925 against a local store of already-verified certificates and identity 1926 bindings). 1928 ###### 1930 A.7. NETCONF (2006/2009) 1932 In 2006, [NETCONF-SSH] specified the following text regarding 1933 application service identity verification in NETCONF: 1935 ###### 1937 6. Security Considerations 1939 The identity of the server MUST be verified and authenticated by the 1940 client according to local policy before password-based authentication 1941 data or any configuration or state data is sent to or received from 1942 the server. The identity of the client MUST also be verified and 1943 authenticated by the server according to local policy to ensure that 1944 the incoming client request is legitimate before any configuration or 1945 state data is sent to or received from the client. Neither side 1946 should establish a NETCONF over SSH connection with an unknown, 1947 unexpected, or incorrect identity on the opposite side. 1949 ###### 1951 In 2009, [NETCONF-TLS] specified the following text regarding 1952 application service identity verification in NETCONF: 1954 ###### 1956 3.1. Server Identity 1958 During the TLS negotiation, the client MUST carefully examine the 1959 certificate presented by the server to determine if it meets the 1960 client's expectations. Particularly, the client MUST check its 1961 understanding of the server hostname against the server's identity as 1962 presented in the server Certificate message, in order to prevent man- 1963 in-the-middle attacks. 1965 Matching is performed according to the rules below (following the 1966 example of [NNTP-TLS]): 1968 o The client MUST use the server hostname it used to open the 1969 connection (or the hostname specified in the TLS "server_name" 1970 extension [TLS]) as the value to compare against the server name 1971 as expressed in the server certificate. The client MUST NOT use 1972 any form of the server hostname derived from an insecure remote 1973 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1974 done. 1975 o If a subjectAltName extension of type dNSName is present in the 1976 certificate, it MUST be used as the source of the server's 1977 identity. 1978 o Matching is case-insensitive. 1979 o A "*" wildcard character MAY be used as the leftmost name 1980 component in the certificate. For example, *.example.com would 1981 match a.example.com, foo.example.com, etc., but would not match 1982 example.com. 1983 o If the certificate contains multiple names (e.g., more than one 1984 dNSName field), then a match with any one of the fields is 1985 considered acceptable. 1987 If the match fails, the client MUST either ask for explicit user 1988 confirmation or terminate the connection and indicate the server's 1989 identity is suspect. 1991 Additionally, clients MUST verify the binding between the identity of 1992 the servers to which they connect and the public keys presented by 1993 those servers. Clients SHOULD implement the algorithm in Section 6 1994 of [PKIX] for general certificate validation, but MAY supplement that 1995 algorithm with other validation methods that achieve equivalent 1996 levels of verification (such as comparing the server certificate 1997 against a local store of already-verified certificates and identity 1998 bindings). 2000 If the client has external information as to the expected identity of 2001 the server, the hostname check MAY be omitted. 2003 ###### 2005 A.8. Syslog (2009) 2007 In 2009, [SYSLOG-TLS] specified the following text regarding 2008 application service identity verification in Syslog: 2010 ###### 2012 5.2. Subject Name Authorization 2014 Implementations MUST support certification path validation [PKIX]. 2015 In addition, they MUST support specifying the authorized peers using 2016 locally configured host names and matching the name against the 2017 certificate as follows. 2019 o Implementations MUST support matching the locally configured host 2020 name against a dNSName in the subjectAltName extension field and 2021 SHOULD support checking the name against the common name portion 2022 of the subject distinguished name. 2023 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 2024 the subjectAltName extension (and in common name, if used to store 2025 the host name), but only as the left-most (least significant) DNS 2026 label in that value. This wildcard matches any left-most DNS 2027 label in the server name. That is, the subject *.example.com 2028 matches the server names a.example.com and b.example.com, but does 2029 not match example.com or a.b.example.com. Implementations MUST 2030 support wildcards in certificates as specified above, but MAY 2031 provide a configuration option to disable them. 2032 o Locally configured names MAY contain the wildcard character to 2033 match a range of values. The types of wildcards supported MAY be 2034 more flexible than those allowed in subject names, making it 2035 possible to support various policies for different environments. 2036 For example, a policy could allow for a trust-root-based 2037 authorization where all credentials issued by a particular CA 2038 trust root are authorized. 2039 o If the locally configured name is an internationalized domain 2040 name, conforming implementations MUST convert it to the ASCII 2041 Compatible Encoding (ACE) format for performing comparisons, as 2042 specified in Section 7 of [PKIX]. 2043 o Implementations MAY support matching a locally configured IP 2044 address against an iPAddress stored in the subjectAltName 2045 extension. In this case, the locally configured IP address is 2046 converted to an octet string as specified in [PKIX], Section 2047 4.2.1.6. A match occurs if this octet string is equal to the 2048 value of iPAddress in the subjectAltName extension. 2050 ###### 2052 A.9. SIP (2010) 2054 In 2010, [SIP-CERTS] specified the following text regarding 2055 application service identity verification in SIP: 2057 ###### 2059 7.2. Comparing SIP Identities 2061 When an implementation (either client or server) compares two values 2062 as SIP domain identities: 2064 Implementations MUST compare only the DNS name component of each 2065 SIP domain identifier; an implementation MUST NOT use any scheme 2066 or parameters in the comparison. 2067 Implementations MUST compare the values as DNS names, which means 2068 that the comparison is case insensitive as specified by 2069 [DNS-CASE]. Implementations MUST handle Internationalized Domain 2070 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 2071 Implementations MUST match the values in their entirety: 2072 Implementations MUST NOT match suffixes. For example, 2073 "foo.example.com" does not match "example.com". 2074 Implemenations MUST NOT match any form of wildcard, such as a 2075 leading "." or "*." with any other DNS label or sequence of 2076 labels. For example, "*.example.com" matches only 2077 "*.example.com" but not "foo.example.com". Similarly, 2078 ".example.com" matches only ".example.com", and does not match 2079 "foo.example.com." 2080 [HTTP-TLS] allows the dNSName component to contain a 2081 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 2082 disallowing this explicitly, leaves the interpretation of 2083 wildcards to the individual specification. [SIP] does not 2084 provide any guidelines on the presence of wildcards in 2085 certificates. Through the rule above, this document 2086 prohibits such wildcards in certificates for SIP domains. 2088 ###### 2090 A.10. SNMP (2010) 2092 In 2010, [SNMP-TLS] specified the following text regarding 2093 application service identity verification in SNMP: 2095 ###### 2097 If the server's presented certificate has passed certification path 2098 validation [PKIX] to a configured trust anchor, and an active row 2099 exists with a zero-length snmpTlstmAddrServerFingerprint value, then 2100 the snmpTlstmAddrServerIdentity column contains the expected host 2101 name. This expected host name is then compared against the server's 2102 certificate as follows: 2104 o Implementations MUST support matching the expected host name 2105 against a dNSName in the subjectAltName extension field and MAY 2106 support checking the name against the CommonName portion of the 2107 subject distinguished name. 2109 o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName 2110 of the subjectAltName extension (and in common name, if used to 2111 store the host name), but only as the left-most (least 2112 significant) DNS label in that value. This wildcard matches any 2113 left-most DNS label in the server name. That is, the subject 2114 *.example.com matches the server names a.example.com and 2115 b.example.com, but does not match example.com or a.b.example.com. 2116 Implementations MUST support wildcards in certificates as 2117 specified above, but MAY provide a configuration option to disable 2118 them. 2120 o If the locally configured name is an internationalized domain 2121 name, conforming implementations MUST convert it to the ASCII 2122 Compatible Encoding (ACE) format for performing comparisons, as 2123 specified in Section 7 of [PKIX]. 2125 If the expected host name fails these conditions then the connection 2126 MUST be closed. 2128 ###### 2130 A.11. GIST (2010) 2132 In 2010, [GIST] specified the following text regarding application 2133 service identity verification in the General Internet Signalling 2134 Transport: 2136 ###### 2138 5.7.3.1. Identity Checking in TLS 2140 After TLS authentication, a node MUST check the identity presented by 2141 the peer in order to avoid man-in-the-middle attacks, and verify that 2142 the peer is authorised to take part in signalling at the GIST layer. 2143 The authorisation check is carried out by comparing the presented 2144 identity with each Authorised Peer Database (APD) entry in turn, as 2145 discussed in Section 4.4.2. This section defines the identity 2146 comparison algorithm for a single APD entry. 2148 For TLS authentication with X.509 certificates, an identity from the 2149 DNS namespace MUST be checked against each subjectAltName extension 2150 of type dNSName present in the certificate. If no such extension is 2151 present, then the identity MUST be compared to the (most specific) 2152 Common Name in the Subject field of the certificate. When matching 2153 DNS names against dNSName or Common Name fields, matching is case- 2154 insensitive. Also, a "*" wildcard character MAY be used as the left- 2155 most name component in the certificate or identity in the APD. For 2156 example, *.example.com in the APD would match certificates for 2157 a.example.com, foo.example.com, *.example.com, etc., but would not 2158 match example.com. Similarly, a certificate for *.example.com would 2159 be valid for APD identities of a.example.com, foo.example.com, 2160 *.example.com, etc., but not example.com. 2162 Additionally, a node MUST verify the binding between the identity of 2163 the peer to which it connects and the public key presented by that 2164 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 2165 for general certificate validation, but MAY supplement that algorithm 2166 with other validation methods that achieve equivalent levels of 2167 verification (such as comparing the server certificate against a 2168 local store of already-verified certificates and identity bindings). 2170 For TLS authentication with pre-shared keys, the identity in the 2171 psk_identity_hint (for the server identity, i.e. the Responding node) 2172 or psk_identity (for the client identity, i.e. the Querying node) 2173 MUST be compared to the identities in the APD. 2175 ###### 2177 Authors' Addresses 2179 Peter Saint-Andre 2180 Cisco 2181 1899 Wyknoop Street, Suite 600 2182 Denver, CO 80202 2183 USA 2185 Phone: +1-303-308-3282 2186 Email: psaintan@cisco.com 2188 Jeff Hodges 2189 PayPal 2190 2211 North First Street 2191 San Jose, California 95131 2192 US 2194 Email: Jeff.Hodges@PayPal.com