idnits 2.17.00 (12 Aug 2021) /tmp/idnits12719/draft-saintandre-tls-server-id-check-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 3, 2010) is 4369 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 normative reference: RFC 3490 (ref. 'IDNA2003') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: draft-ietf-idnabis-protocol has been published as RFC 5891 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 -- 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) == Outdated reference: draft-ietf-idnabis-defs has been published as RFC 5890 -- 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) == Outdated reference: draft-ietf-sip-domain-certs has been published as RFC 5922 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) == Outdated reference: draft-ietf-xmpp-3920bis has been published as RFC 6120 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre, Ed. 3 Internet-Draft Cisco 4 Intended status: BCP J. Hodges, Ed. 5 Expires: December 5, 2010 PayPal 6 June 3, 2010 8 Representation and Verification of Domain-Based Application Server 9 Identity in Certificates Used with Transport Layer Security 10 draft-saintandre-tls-server-id-check-05 12 Abstract 14 Many application technologies enable a secure connection between two 15 entities using certificates in the context of Transport Layer 16 Security (TLS). This document specifies best current practices for 17 representing and verifying the identity of application servers in 18 such interactions. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 5, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 9 61 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 62 1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 63 2. Representation of Server Identity . . . . . . . . . . . . . . 9 64 2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 9 65 2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 10 66 3. Verification of Server Identity . . . . . . . . . . . . . . . 11 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.2. Constructing an Ordered List of Reference Identifiers . . 12 69 3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 14 70 3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 15 71 3.4.1. Checking of Traditional Domain Names . . . . . . . . . 15 72 3.4.2. Checking of Internationalized Domain Names . . . . . . 15 73 3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 16 74 3.4.4. Checking of DNS Domain Names in Common Names . . . . . 16 75 3.5. Verifying an Application Type . . . . . . . . . . . . . . 17 76 3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 17 77 3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 17 78 3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 18 80 3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 18 81 3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 18 82 3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 18 83 3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 19 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 19 86 4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 19 87 4.3. Internationalized Doman Names . . . . . . . . . . . . . . 20 88 4.4. Domain Components . . . . . . . . . . . . . . . . . . . . 20 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 92 6.2. Informative References . . . . . . . . . . . . . . . . . . 21 93 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 25 94 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 25 95 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 26 96 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 27 97 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 30 98 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 32 99 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 33 100 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 34 101 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 35 102 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 36 103 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 37 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 106 1. Introduction 108 1.1. Motivation 110 The visible face of the Internet consists of services that employ a 111 client-server architecture in which an interactive or automated 112 client connects to an application server in order to retrieve or 113 upload information, communicate with other entities, or access a 114 broader network of services. When a client connects to an 115 application server using Transport Layer Security [TLS] (or, less 116 commonly, [DTLS]), it references some conception of the server's 117 identity while attempting to establish a secure connection (e.g., 118 "the web site at example.com"). Likewise, during TLS negotiation the 119 server presents its conception of the server's identity in the form 120 of a public-key certificate that was issued by a certification 121 authority in the context of the Internet Public Key Infrastructure 122 using X.509 [PKIX]. Informally, we can think of these identities as 123 the client's "reference identity" and the server's "presented 124 identity" (these rough ideas are defined more precisely later in this 125 document through the concept of particular identifiers). In general, 126 a client needs to verify that the server's presented identity matches 127 its reference identity so that it can be sure that the certificate 128 can legitimately be used to authenticate the connection. 130 Many application technologies adhere to the pattern outlined here, 131 including but not limited to the following: 133 o The Internet Message Access Protocol [IMAP] and the Post Office 134 Protocol [POP3], for which see also [USINGTLS] 136 o The Hypertext Transfer Protocol [HTTP], for which see also 137 [HTTP-TLS] 139 o The Lightweight Directory Access Protocol [LDAP], for which see 140 also [LDAP-AUTH] and its predecessor [LDAP-TLS] 142 o The Simple Mail Transfer Protocol [SMTP], for which see also 143 [SMTP-AUTH] and [SMTP-TLS] 145 o The Extensible Messaging and Presence Protocol [XMPP], for which 146 see also [XMPPBIS] 148 o The Network News Transfer Protocol [NNTP], for which see also 149 [NNTP-TLS] 151 o The NETCONF Configuration Protocol [NETCONF], for which see also 152 [NETCONF-SSH] and [NETCONF-TLS] 154 o The Syslog Protocol [SYSLOG], for which see also [SYSLOG-TLS] 156 o The Session Initiation Protocol [SIP], for which see also 157 [SIP-CERTS] 159 o The General Internet Signalling Transport [GIST] 161 Application protocols have traditionally specified their own rules 162 for representing and verifying server identities. Unfortunately, 163 this divergence of approaches has caused some confusion among 164 certification authorities, application developers, and protocol 165 designers. 167 To codify best current practices regarding the implementation and 168 deployment of secure PKIX-based authentication, this document 169 specifies recommended procedures for representing and verifying 170 server identities in certificates intended for use in applications 171 employing TLS. 173 1.2. Scope 175 1.2.1. In Scope 177 This document applies only to server identities associated with DNS 178 domain names, only to TLS, and only to PKIX-based systems. As a 179 result, the scenarios described in the following section are out of 180 scope for this specification (although they might be addressed by 181 future specifications). 183 1.2.2. Out of Scope 185 o Client or end-user identities. 187 Certificates representing client or end-user identities (e.g., the 188 rfc822Name identifier) can be used for mutual authentication 189 between a client and server or between two clients, thus enabling 190 stronger client-server security or end-to-end security. However, 191 certification authorities, application developers, and service 192 operators have less experience with client certificates than with 193 server certificates, thus gives us fewer models from which to 194 generalize and a less solid basis for defining best practices. 196 o Identifiers other than DNS domain names (e.g., IP addresses). 198 Some certification authorities issue server certificates based on 199 IP addresses, but preliminary evidence indicates that such 200 certificates are a very small percentage of issued certificates 201 (e.g., less than 1%). Furthermore, IP addresses are not 202 necessarily reliable identifiers for application servers because 203 of the existence of private internets [PRIVATE], host mobility, 204 multiple interfaces on a given host, Network Address Translators 205 (NATs) resulting in different addresses for a host from different 206 locations on the network, the practice of grouping many hosts 207 together behind a single IP address, etc. Most fundamentally, 208 most users find DNS domain names much easier to work with than IP 209 addresses, which is why the domain name system was designed in the 210 first place. We prefer to define best practices for the much more 211 common use case and not to complicate the rules in this 212 specification. 214 o Security protocols other than [TLS] or [DTLS]. 216 Although other secure, lower-layer protocols exist and also at 217 times employ PKIX certificates, e.g. [IPSEC], their use cases can 218 differ from those of TLS-based or DTLS-based application 219 technologies. Furtermore, application technologies have less 220 experience with IPsec than with TLS, thus making it more difficult 221 to gather feedback on proposed best practices. 223 o Keys or certificates employed outside the context of PKIX-based 224 systems. 226 Some deployed application technologies use a web of trust model 227 based on or similar to [OPENPGP], or use self-signed certificates, 228 or are deployed on networks are not directly connected to the 229 public Internet and therefore cannot depend on Certificate 230 Revocation Lists (CRLs) or the Online Certificate Status Protocol 231 [OCSP] to check CA-issued certificates. However, the syntax of 232 OpenPGP keys differs significantly from X.509 certificates, the 233 data in self-signed certificates has not been certified by a 234 third-party in any way, and checking of CA-issued certificates via 235 CRLs or OSCP is critically important to maintaining the security 236 of PKIX-based systems. Attempting to define best practices for 237 such technologies would unduly complicate the rules defined in 238 this specification. 240 Furthermore, this document also does not address various 241 certification authority policies, such as: 243 o What classes and types of certificates to issue and whether to 244 apply different policies for them (e.g., allow the wildcard 245 character in Class 2 certificates but not in Class 1 or Extended 246 Validation certificates). 248 o Whether to issue certificates based on IP addresses in addition to 249 DNS domain names. 251 o Which identifiers to include (e.g., whether to include the SRVName 252 and uniformResourceIdentifier extensions). 254 o How to certify or validate the information contained in a 255 certificate. 257 Finally, this specification is mostly silent about user interface 258 issues, which in general are properly the responsibility of client 259 software developers and standards development organizations dedicated 260 to particular application technologies (see for example [WSC-UI]. 262 1.3. Terminology 264 Because the concept of "identity" is too vague to be actionable in 265 application protocols, we define a set of more concrete terms: 267 application server: A service on the Internet that enables 268 interactive clients and automated clients to connect for the 269 purpose of retrieving or uploading information, communicate with 270 other entities, or connect to a broader network of services. 272 automated client: A software agent or device that is not directly 273 controlled by a natural person. 275 identifier: A particular instance of an identifier type that is 276 either presented by a server in a certificate or referenced by a 277 client for matching purposes. 279 identifier type: A formally defined category of identifier that can 280 be included in a certificate and therefore also used for matching 281 purposes; the types covered in this specification are: 283 * CN-ID = a Relative Distinguished Name (RDN) of type Common Name 284 (CN) 286 * DNS-ID = a subjectAltName identifier of type dNSName 288 * SRV-ID = the SRVName form of otherName from the GeneralName 289 structure in SubjectAltName 291 * URI-ID = a subjectAltName identifier of type 292 uniformResourceIdentifier 294 interactive client: A software agent or device that is directly 295 controlled by a natural person. (Other specifications related to 296 security and application protocols often refer to this as a "user 297 agent", e.g., [WSC-UI].) 299 PKIX certificate: An X.509v3 certificate generated and employed in 300 the context of the Internet Public Key Infrastructure using X.509 301 [PKIX]. 303 presented identifier: An identifier that is presented by a server to 304 a client within the server's PKIX certificate when the client 305 attempts to establish a secure connection with the server; the 306 certificate can include one or more presented identifiers of 307 different types. 309 reference identifier: An identifier that is used by the client for 310 matching purposes when checking the presented identifiers; the 311 client can attempt to match multiple reference identifiers of 312 different types. 314 service type: A formal identifier for the application protocol used 315 to provide a particular kind of service at a domain; the service 316 type typically takes the form of a URI scheme or a DNS SRV 317 Service. 319 source domain: The DNS domain name that a client expects an 320 application server to present in the certificate. 322 target domain: A domain name or host name that a client has derived 323 from the soruce domain in an automated fashion (e.g., by means of 324 a [DNS-SRV] lookup) or that a natural person directly controlling 325 an interactive client has explicitly configured for connecting to 326 the source domain. 328 Most security-related terms in this document are to be understood in 329 the sense defined in [SECTERMS]; such terms include, but are not 330 limited to, "attack", "authentication", "authorization", 331 "certification authority", "certificate", "credential", "identity", 332 "self-signed certificate", "trust", "trust anchor", "trust chain", 333 "validate", and "verify". 335 The following capitalized keywords are to be interpreted as described 336 in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; 337 "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", 338 "OPTIONAL". 340 1.4. Contributors 342 The following individuals made significant contributions to the text 343 of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. 345 1.5. Acknowledgements 347 The editors and contributors wish to thank the following individuals 348 for their feedback and suggestions: Nelson Bolyard, Scott Cantor, 349 Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Bruno 350 Harbulot, David Harrington, Paul Hoffman, Harry Hotz, Geoff Keating, 351 Scott Lawrence, Matt McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig 352 Nussel, Joe Orton, Tom Petch, Yngven Pettersen, Tim Polk, Eric 353 Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Rob Stradling, Peter 354 Sylvester, Dan Wing, and Dan Winship. 356 1.6. Discussion Venue 358 [[ RFC Editor: please remove this section. ]] 360 The editors are actively seeking input from certification 361 authorities, application developers, and protocol designers regarding 362 the recommendations in this document. Please send feedback to the 363 editors directly or post to the mailing list, for 364 which archives and subscription information are available at 365 . 367 2. Representation of Server Identity 369 This section enumerates the rules for representing application server 370 identity in PKIX certificates. First we provide a brief tutorial 371 about subject naming, then we provide the rules. 373 2.1. Subject Naming in PKIX Certificates 375 The application server is the subject of a server certificate. As 376 [PKIX] says, "[the] subject field identifies the entity associated 377 with the public key stored in the subject public key field." 379 The application server is identified by a name or names carried in 380 the subject field and/or the subjectAltName extension of the 381 certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details. 382 This section only briefly introduces distinguished names and their 383 components, as well as subjectAltNames and the particular 384 subjectAltName extension types explicitly mentioned in this 385 specification. 387 The subject field of a PKIX certificate is defined as an X.501 type 388 Name and known as a Distinguished Name (DN) -- see [X.501] and 389 [PKIX]. A DN is an ordered sequence of Relative Distinguished Name 390 (RDNs), where an RDN is a set (i.e., an unordered group) of type-and- 391 value pairs or "attribute value assertions" (AVAs) [LDAP-DN], each of 392 which asserts some attribute about the subject of the certificate. 393 In practice, the RDNs can be ordered in the DN sequence from most 394 general to most specific or most specific to general, and the order 395 cannot be relied upon. When creating DNs, care must be taken in 396 order to be sure that the desired order of the RDN sequence is 397 enforced, because in DN encoding the first element is the most 398 significant for the decoding party. 400 Note that certificates are binary objects -- they are encoded using 401 distinguished encoding rules (DER). Thus, displayable (a.k.a. 402 printable) renderings of certificate subject (and issuer) names means 403 that the DER-encoded sequences are decoded and converted into a 404 "string representation" of a DN before being rendered. Often such a 405 DN string representation is ordered from left-to-right, most specific 406 to most general. See [LDAP-AUTH] for details. 408 Certificate subjects may also have "alternative" names. These are 409 represented within certificates using the SubjectAltName field. This 410 field is a sequence of typed fields, where each type is a distinct 411 type of identifier. For example, the subjectAltName identifier types 412 noted in this specification are: 414 o dNSName -- a DNS domain name [PKIX] 415 o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME] 416 o uniformResourceIdentifier -- a Uniform Resource Identifier [URI] 417 [PKIX] 419 2.2. PKIX Certificate Name Rules 421 When a certification authority issues a certificate based on the DNS 422 domain name at which the server will provide the relevant service, 423 the following rules apply to the representation of application server 424 identities. 426 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName 427 identifier of type dNSName). 429 2. If the service using the certificate deploys a technology in 430 which a server is discovered by means of DNS SRV records 431 [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate 432 SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form 433 of otherName from the GeneralName structure in the subjectAltName 434 as specified in [SRVNAME]). 436 3. If the service using the certificate deploys a technology in 437 which a server is typically associated with a URI (e.g., this is 438 true of [SIP]), then the certificate SHOULD include an URI-ID 439 (i.e., a subjectAltName identifier of type 440 uniformResourceIdentifier); the scheme SHALL be that of the 441 protocol associated with the application type and the authority 442 component SHALL be the DNS domain name of the service. 444 4. The certificate MAY include other application-specific 445 identifiers for types that were defined before specification of 446 the SRVName extension (e.g., XmppAddr for [XMPP]) or for which 447 service names or URI schemes do not exist; however, such 448 application-specific identifiers are not generally applicable and 449 therefore are out of scope for this specification. 451 5. The DNS domain name portion of any identifier type MAY contain 452 one instance of the wildcard character '*' (see [DNS-WILD]) but 453 only as the left-most label of the DNS domain name component of 454 the identifier (following the definition of "label" from [DNS]). 455 Specifications that profile the rules defined in this document 456 MUST specify whether the wildcard character is or is not allowed 457 in certificates issued under that profile; by default wildcard 458 certificates SHOULD NOT be allowed. 460 6. The certificate SHOULD NOT represent the server's DNS domain name 461 in a Relative Distinguished Name (RDN) of type Common Name (CN) 462 (see [LDAP-SCHEMA]), even though we recognize that many deployed 463 clients still check for this legacy identifier configuration 464 within certificate subjectName. However, if this legacy 465 identifer configuration is employed, then the server's DNS domain 466 name MUST be placed in the last (most specific) RDN within the 467 RDN sequence making up the certificate's subjectName, as the 468 order of RDNs is determined by the DER-encoded Name within the 469 server's PKIX certificate. Furthermore, the certificate SHOULD 470 NOT contain more than one Common Name attribute. 472 7. The certificate MUST NOT represent the server's DNS domain name 473 by means of a series of Domain Component (DC) attributes (because 474 the order of Domain Components is not guaranteed, certain attacks 475 are possible if DC attributes are included; see under Section 4). 477 3. Verification of Server Identity 478 3.1. Overview 480 At a high level, the client verifies the server's identity by 481 performing the following actions: 483 1. Before connecting to the server, the client constructs an ordered 484 list of reference identifiers against which to check the 485 presented identifiers. 487 2. The server provides its identifiers in the form of a PKIX 488 certificate. 490 3. The client checks each of its reference identifiers against the 491 presented identifiers for the purpose of finding a match. 493 4. When checking a reference identifier against a presented 494 identifier, the client (a) MUST match the source domain of the 495 identifiers and (b) MAY also match the service type of the 496 identifiers. 498 Implementation Note: Naturally, in addition to checking 499 identifiers, a client might complete further checks to ensure that 500 the server is authorized to provide the requested service. 501 However, such checking is not a matter of verifying the server 502 identity presented in a certificate, and therefore methods for 503 doing so (e.g., consulting local policy information) are out of 504 scope for this document. 506 3.2. Constructing an Ordered List of Reference Identifiers 508 Before connecting to the server, the client MUST construct an ordered 509 list of acceptable reference identifiers. 511 The inputs here might be a URI that a user has typed into an 512 interface (e.g., an HTTP URL for a web site), configured account 513 information (e.g., the username of an IMAP or POP3 account for 514 retrieving email), or some other combination of information that can 515 yield a source domain and an application type. 517 The client might need to derive the source domain and application 518 type from the input(s) it has received. The derived data MUST 519 include only information that can be securely parsed out of the 520 inputs (e.g., extracting the DNS domain name from the authority 521 component of a URI or extracting the application type from the scheme 522 of a URI) or information for which the derivation is performed in a 523 secure manner (e.g., using [DNSSEC]). 525 In some cases the inputs might include more than one DNS domain name, 526 because a user might have explicitly configured the client to 527 associate a target domain with the source domain. Such delegation 528 can occur by means of user-approved DNS SRV records (e.g., _xmpp- 529 server._tcp.im.example.com might yield a hostname of 530 hosting.example.net) or a user-configured lookup table for host-to- 531 address or address-to-host translations (e.g., the Unix "hosts" 532 file). See under Section 4 for further discussion of service 533 delegation. 535 Using the combination of DNS domain name(s) and application type, the 536 client constructs a list of reference identifiers in accordance with 537 the following rules: 539 o The list MUST include a DNS-ID. A reference identifier of type 540 DNS-ID can be directly constructed from a DNS domain name that is 541 (a) contained in or derived from the inputs (i.e., the source 542 domain), or (b) explicitly associated with the source domain by 543 means of user configuration (i.e., a target domain). 545 o If a server for the application type is typically discovered by 546 means of DNS SRV records, then the list SHOULD include an SRV-ID. 548 o If a server for the application type is typically associated with 549 a URI, then the list SHOULD include a URI-ID 551 o The list SHOULD NOT include a CN-ID; however, the CN-ID (if 552 included) MUST be constructed only from the source domain and 553 never from a target domain. 555 Implementation Note: The client does not need to actually 556 construct the foregoing identifiers in the formats found in a 557 certificate (e.g., as ASN.1 object identifiers), only the 558 functional equivalent of such identifiers for matching purposes. 560 Security Note: A client MUST NOT construct a reference identifier 561 corresponding to Relative Distinguished Names (RDNs) other than 562 the Common Name and MUST NOT check for such RDNs in the presented 563 identifiers. In particular, this means that a client MUST NOT 564 check a series of Domain Component (DC) attributes if included in 565 the certificate (because the order of Domain Components is not 566 guaranteed, certain attacks are possible if DC attributes are 567 checked). 569 The client then orders the list in accordance with the following 570 rules: 572 o Reference identifiers that include the source domain MUST be 573 preferred over reference identifiers that include a target domain 574 (if any). 576 o Reference identifiers that include both a DNS domain name and an 577 application type MUST be preferred over reference identifiers that 578 include only a DNS domain name. Therefore an SRV-ID or URI-ID is 579 to be preferred over a DNS-ID. 581 o Notwithstanding any of the foregoing rules, reference identifiers 582 of type CN-ID (if included) MUST always be the lowest-priority 583 reference identifiers in the list. 585 To illustrate the ordering rules, consider the case where the inputs 586 are a source domain of "im.example.com" and an application type of 587 "XMPP" (for which application servers are discovered via DNS SRV 588 records) and the user of the client has also explicitly configured a 589 target domain of "hosting.example.net". In this case, the ordered 590 list would be: 592 1. SRV-ID of "_xmpp.im.example.com" 593 2. DNS-ID of "im.example.com" 594 3. SRV-ID of "_xmpp.hosting.example.net" 595 4. DNS-ID of "hosting.example.net" 596 5. CN-ID of "im.example.com" 598 3.3. Seeking a Match 600 Once the client has constructed its order list of reference 601 identifiers and has received the server's presented identifiers in 602 the form of an PKIX certificate, the client checks its reference 603 identifiers against the presented identifiers for the purpose of 604 finding a match. It does so by seeking a match in preference order 605 and aborting the search if any presented identifier matches one of 606 its reference identifiers. The search fails if the client exhausts 607 its list of reference identifiers without finding a match. Detailed 608 comparison rules for finding a match are provided in the following 609 sections. 611 Security Note: A client MUST NOT seek a match for a reference 612 identifier of CN-ID if the presented identifiers include an 613 SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName 614 extensions, and MUST NOT check a Common Name in the certificate if 615 it is other than the last Relative Distinguished Name (RDN) in 616 within the sequence of RDNs making up the Distinguished Name 617 within the certificate's subjectName. (The term "last" refers to 618 the DER order, which is often not the string order presented to a 619 user; the order that is applied here MUST be the DER order.) 621 3.4. Verifying a Domain Name 623 This document assumes that each reference identifier contains a DNS 624 domain name that is a "traditional domain name" or an 625 "internationalized domain name". The client MUST match the source 626 domain of a reference identifier according to the following rules. 628 3.4.1. Checking of Traditional Domain Names 630 The term "traditional domain name" is a contraction of this more 631 formal and accurate name: "traditional US-ASCII letter-digit-hyphen 632 DNS domain name". Traditional domain names are defined in 633 [DNS-CONCEPTS] and [DNS] in conjunction with [HOSTS] as further 634 explained in [IDNA2003]. In essence, a traditional domain name 635 consists of a set of one or more labels, with the labels usually 636 shown separated by dots. Labels nominally consist of only [US-ASCII] 637 uppercase and lowercase letters, digits, and hyphen. There are 638 additional qualifications (please refer to the above-referenced 639 specifications for details) but they are not germane to this 640 specification. 642 If the source domain of a reference identifier is a "traditional 643 domain name", then matching of the reference identifier against the 644 presented identifier is performed by comparing the set of domain 645 components using a case-insensitive ASCII comparison (as clarified by 646 [DNS-CASE]). Each label MUST match in order for the names to be 647 considered to match. 649 3.4.2. Checking of Internationalized Domain Names 651 [[ Editorial Note: This section needs to be updated to reflect 652 [IDNA2008]. ]] 654 The term "internationalized domain name" refers to a DNS domain name 655 that conforms to the overall form of a domain name (dot-separated 656 labels) but that can include Unicode code points outside the 657 traditional US-ASCII range, as explained by [IDNA2003] and 658 [IDNA2008]. 660 If the source domain of a reference identifier is an 661 internationalized domain name, then an implementation MUST convert 662 the domain name to the ASCII Compatible Encoding (ACE) format as 663 specified in Section 4 of [IDNA2003] before comparison; specifically, 664 the conversion operation specified in Section 4 of [IDNA2003] MUST be 665 performed as follows: 667 o In step 1, the domain name SHALL be considered a "stored string". 668 o In step 3, set the flag called "UseSTD3ASCIIRules". 669 o In step 4, process each label with the "ToASCII" operation. 670 o In step 5, change all label separators to U+002E (full stop). 672 After performing the "to-ASCII" conversion with regard to an 673 internationalized domain name, the DNS labels and names MUST be 674 compared for equality according to the rules specified in Section 3 675 of [IDNA2003], i.e. once all label separators are replaced with 676 U+002E (dot) they are compared in a case-insensitive manner. 678 3.4.3. Checking of Wildcard Labels 680 Unless forbidden by a specification that profiles the best practices 681 defined herein, a client employing this specification's rules MAY 682 match the reference identifier against a presented identifier 683 containing one instance of the wildcard character '*' (see 684 [DNS-WILD]) as the left-most label of the domain name, e.g. 685 *.example.com (following the definition of "label" from [DNS]). 687 If such a wildcard identifier is presented, the wildcard MUST be used 688 to match only the one position-wise corresponding label (thus 689 *.example.com matches foo.example.com but not bar.foo.example.com or 690 example.com). The client MUST fail to match a presented identifier 691 in which the wildcard character is contained within a label fragment 692 (e.g., baz*.example.net is not allowed and MUST NOT be taken to match 693 baz1.example.net and baz2.example.net), or in which the wildcard 694 character does not comprise the left-most label in the presented 695 identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net 696 are allowed). 698 3.4.4. Checking of DNS Domain Names in Common Names 700 As noted, a client MUST NOT seek a match for a reference identifier 701 of CN-ID if the presented identifiers include an SRV-ID, URI-ID, 702 DNS-ID, or any application-specific subjectAltName extensions. 704 Therefore, if and only if the identity set does not include 705 subjectAltName extensions of type dNSName, SRVName, or 706 uniformResourceIdentifier (or any application-specific subjectAltName 707 extensions), the client MAY as a fallback check for a DNS domain name 708 in the value of the last Relative Distinguished Name (RDN), if it is 709 of type Common Name (CN), within the sequence of RDNs making up the 710 Distinguished Name within the certificate's subjectName. (The term 711 "last" refers to the DER order, which is often not the string order 712 presented to a user; the order that is applied here MUST be the DER 713 order.) 714 In existing certificates, the CN is often used for representing a DNS 715 domain name; for example, consider the following subjectName, where 716 the last RDN is a Common Name that is intended to represent a DNS 717 domain name: 719 ou=Web Services, c=GB, cn=www.example.com 721 Here the Common Name is "www.example.com" (a string whose form 722 matches that of a DNS domain name) and the client could choose to 723 compare a reference identifier of type CN-ID against that string. 724 When doing so, the client MUST follow the comparison rules for the 725 source domain of an identifier of type DNS-ID, SRV-ID, or URI-ID, as 726 described under Section 3.4. 728 3.5. Verifying an Application Type 730 As specified under the ordering rules for reference identifiers, a 731 client SHOULD check not only the domain name but also the application 732 type of the service to which it connects. This is a best practice 733 because typically a client is not designed to connect to all kinds of 734 services using all possible application protocols, but instead is 735 designed to connect to a specific kind of service, such as a web 736 site, an email service, or an instant messaging service. 738 The application type is verified by means of either an SRV-ID or 739 URI-ID. 741 3.5.1. SRV-ID 743 The service name portion of an SRV-ID (e.g., "xmpp") MUST be matched 744 in a case-insensitive manner, in accordance with [DNS-SRV]. Note 745 that the "_" character is prepended to the service identifier in DNS 746 SRV records. 748 3.5.2. URI-ID 750 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 751 a case-insensitive manner, in accordance with [URI]. Note that the 752 ":" character is a separator between the scheme name and the rest of 753 the URI, and therefore does not need to be included in any 754 comparison. 756 3.6. Outcome 758 The outcome of the checking procedure is one of the following cases. 760 3.6.1. Case #1: Match Found 762 If the client has found a presented identifier that matches a 763 reference identifier, matching has succeeded. In this case, the 764 client MUST use the matched reference identifier as the validated 765 identity of the server. 767 3.6.2. Case #2: No Match Found, Cached Certificate 769 If the client finds no presented identifier that matches any of the 770 reference identifiers but a natural person has permanently accepted 771 the certificate during a previous connection attempt, the certificate 772 is cached. In this case, the client MUST verify that the presented 773 certificate matches the cached certificate and MUST notify the user 774 if the certificate has changed since the last time a secure 775 connection was successfully negotiated. 777 3.6.3. Case #3: No Match Found, Uncached Certificate 779 If the client finds no presented identifier that matches any of the 780 reference identifiers and a human user has not permanently accepted 781 the certificate during a previous connection attempt, the client MUST 782 NOT consider the certificate to include a validated identity for the 783 application server. 785 Instead, the client MUST proceed as follows. 787 3.6.3.1. Interactive User Agent 789 If the client is an interactive client that is directly controlled by 790 a natural person, then it MUST either do one of the following: 792 1. Automatically terminate the connection with a bad certificate 793 error; or 795 2. Actively warn the user that the certificate is untrusted and 796 encourage the user to terminate the connection, but give advanced 797 users the option to (a) view the entire certificate chain, (b) 798 accept the certificate either temporarily (i.e., for this 799 connection attempt only) or permanently (i.e., for all future 800 connection attempts), and then (c) continue with the connection 801 attempt. 803 If a user permanently accepts a certificate (an action referred to in 804 [WSC-UI] as "pinning"), the client MUST cache the certificate (or 805 some non-forgeable representation such as a hash value) and in future 806 connection attempts MUST behave as in "Case #2: No Match Found, 807 Cached Certificate" Section 3.6.2. 809 Security Note: It is the responsibility of the human user to 810 verify the hash value or fingerprint of the certificate with the 811 server over a trusted communication layer. 813 Informational Note: The guidelines provided here are roughly 814 consistent with those provided for web browsers and other HTTP- 815 aware interactive clients in [WSC-UI]. 817 3.6.3.2. Automated Client 819 If the client is an automated application that is not directly 820 controlled by a natural person, then it SHOULD terminate the 821 connection with a bad certificate error and log the error to an 822 appropriate audit log. An automated application MAY provide a 823 configuration setting that disables this check, but MUST enable the 824 check by default. 826 4. Security Considerations 828 4.1. Service Delegation 830 When the connecting application is an interactive client, the source 831 domain name and application type MUST be provided by a human user 832 (e.g. when specifying the server portion of the user's account name 833 on the server or when explicitly configuring the client to connect to 834 a particular host or URI as in [SIP-LOC]) and MUST NOT be derived 835 from the user inputs in an automated fashion (e.g., a hostname 836 address discovered through DNS resolution of the source domain). 837 This rule is important because only a match between the user inputs 838 (in the form of a reference identifier) and a presented identifier 839 enables the client to be sure that the certificate can legitimately 840 be used to secure the connection. 842 However, an interactive client MAY provide a configuration setting 843 that enables a human user to explicitly specify a particular hostname 844 (called a "target domain") to be checked for connection purposes. 846 4.2. Wildcard Certificates 848 Allowing the wildcard character in certificates has led to homograph 849 attacks involving non-ASCII characters that look similar to 850 characters commonly included in HTTP URLs, such as "/" and "?"; for 851 discussion, see for example [Defeating-SSL]. 853 4.3. Internationalized Doman Names 855 In addition to the wildcard certificate attacks previously mentioned, 856 allowing internationalized domain names can lead to the inclusion of 857 visually similar (so-called "confusable") characters in certificates; 858 for discussion, see for example [IDNA-DEFS]. 860 4.4. Domain Components 862 Domain Components (DCs) are unordered. Therefore the following two 863 sets of DCs would be equivalent: 865 dc=com, dc=example, dc=cn 867 dc=cn, dc=example, dc=com 869 Because com.example.cn is presumably different from cn.example.com, 870 representing or verifying an application server's DNS domain name 871 based on domain components would open a serious security hole. As a 872 result, certificate issuers and application clients MUST NOT use DCs. 874 5. IANA Considerations 876 This document has no actions for the IANA. 878 6. References 880 6.1. Normative References 882 [DNS] Mockapetris, P., "Domain names - implementation and 883 specification", STD 13, RFC 1035, November 1987. 885 [DNS-CONCEPTS] 886 Mockapetris, P., "Domain names - concepts and facilities", 887 STD 13, RFC 1034, November 1987. 889 [IDNA2003] 890 Faltstrom, P., Hoffman, P., and A. Costello, 891 "Internationalizing Domain Names in Applications (IDNA)", 892 RFC 3490, March 2003. 894 [IDNA2008] 895 Klensin, J., "Internationalized Domain Names in 896 Applications (IDNA): Protocol", 897 draft-ietf-idnabis-protocol-18 (work in progress), 898 January 2010. 900 [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol 901 (LDAP): String Representation of Distinguished Names", 902 RFC 4514, June 2006. 904 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 905 Housley, R., and W. Polk, "Internet X.509 Public Key 906 Infrastructure Certificate and Certificate Revocation List 907 (CRL) Profile", RFC 5280, May 2008. 909 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 910 Subject Alternative Name for Expression of Service Name", 911 RFC 4985, August 2007. 913 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, March 1997. 916 6.2. Informative References 918 [Defeating-SSL] 919 Marlinspike, M., "New Tricks for Defeating SSL in 920 Practice", February 2009, . 924 [DNS-CASE] 925 Eastlake, D., "Domain Name System (DNS) Case Insensitivity 926 Clarification", RFC 4343, January 2006. 928 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 929 specifying the location of services (DNS SRV)", RFC 2782, 930 February 2000. 932 [DNS-WILD] 933 Lewis, E., "The Role of Wildcards in the Domain Name 934 System", RFC 4592, July 2006. 936 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 937 Rose, "DNS Security Introduction and Requirements", 938 RFC 4033, March 2005. 940 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 941 Security", RFC 4347, April 2006. 943 [GIST] Schulzrinne, H. and M. Stiemerling, "GIST: General 944 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 945 (work in progress), June 2009. 947 [HOSTS] Braden, R., "Requirements for Internet Hosts - Application 948 and Support", STD 3, RFC 1123, October 1989. 950 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 951 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 952 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 954 [HTTP-TLS] 955 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 957 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 958 4rev1", RFC 3501, March 2003. 960 [IDNA-DEFS] 961 Klensin, J., "Internationalized Domain Names for 962 Applications (IDNA): Definitions and Document Framework", 963 draft-ietf-idnabis-defs-13 (work in progress), 964 January 2010. 966 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 967 September 1981. 969 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 970 (IPv6) Specification", RFC 2460, December 1998. 972 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 973 Internet Protocol", RFC 4301, December 2005. 975 [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol 976 (LDAP): The Protocol", RFC 4511, June 2006. 978 [LDAP-AUTH] 979 Harrison, R., "Lightweight Directory Access Protocol 980 (LDAP): Authentication Methods and Security Mechanisms", 981 RFC 4513, June 2006. 983 [LDAP-SCHEMA] 984 Sciberras, A., "Lightweight Directory Access Protocol 985 (LDAP): Schema for User Applications", RFC 4519, 986 June 2006. 988 [LDAP-TLS] 989 Hodges, J., Morgan, R., and M. Wahl, "Lightweight 990 Directory Access Protocol (v3): Extension for Transport 991 Layer Security", RFC 2830, May 2000. 993 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 994 December 2006. 996 [NETCONF-SSH] 997 Wasserman, M. and T. Goddard, "Using the NETCONF 998 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 999 December 2006. 1001 [NETCONF-TLS] 1002 Badra, M., "NETCONF over Transport Layer Security (TLS)", 1003 RFC 5539, May 2009. 1005 [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", 1006 RFC 3977, October 2006. 1008 [NNTP-TLS] 1009 Murchison, K., Vinocur, J., and C. Newman, "Using 1010 Transport Layer Security (TLS) with Network News Transfer 1011 Protocol (NNTP)", RFC 4642, October 2006. 1013 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1014 Adams, "X.509 Internet Public Key Infrastructure Online 1015 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1017 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1018 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1020 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1021 STD 53, RFC 1939, May 1996. 1023 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1024 E. Lear, "Address Allocation for Private Internets", 1025 BCP 5, RFC 1918, February 1996. 1027 [PKIX-OLD] 1028 Housley, R., Ford, W., Polk, T., and D. Solo, "Internet 1029 X.509 Public Key Infrastructure Certificate and CRL 1030 Profile", RFC 2459, January 1999. 1032 [SECTERMS] 1033 Shirey, R., "Internet Security Glossary, Version 2", 1034 RFC 4949, August 2007. 1036 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1037 A., Peterson, J., Sparks, R., Handley, M., and E. 1038 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1039 June 2002. 1041 [SIP-CERTS] 1042 Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 1043 Certificates in the Session Initiation Protocol (SIP)", 1044 draft-ietf-sip-domain-certs-06 (work in progress), 1045 March 2010. 1047 [SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1048 Protocol (SIP): Locating SIP Servers", RFC 3263, 1049 June 2002. 1051 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1052 October 2008. 1054 [SMTP-AUTH] 1055 Siemborski, R. and A. Melnikov, "SMTP Service Extension 1056 for Authentication", RFC 4954, July 2007. 1058 [SMTP-TLS] 1059 Hoffman, P., "SMTP Service Extension for Secure SMTP over 1060 Transport Layer Security", RFC 3207, February 2002. 1062 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 1064 [SYSLOG-TLS] 1065 Miao, F., Ma, Y., and J. Salowey, "Transport Layer 1066 Security (TLS) Transport Mapping for Syslog", RFC 5425, 1067 March 2009. 1069 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1070 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1072 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1073 Resource Identifier (URI): Generic Syntax", STD 66, 1074 RFC 3986, January 2005. 1076 [US-ASCII] 1077 American National Standards Institute, "Coded Character 1078 Set - 7-bit American Standard Code for Information 1079 Interchange", ANSI X3.4, 1986. 1081 [USINGTLS] 1082 Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1083 RFC 2595, June 1999. 1085 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1086 Interface Guidelines", World Wide Web Consortium 1087 LastCall WD-wsc-ui-20100309, March 2010, 1088 . 1090 [X.501] International Telecommunications Union, "Information 1091 Technology - Open Systems Interconnection - The Directory: 1093 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1094 February 2001. 1096 [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1097 Protocol (XMPP): Core", RFC 3920, October 2004. 1099 [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence 1100 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work 1101 in progress), April 2010. 1103 Appendix A. Prior Art 1105 (This section is non-normative.) 1107 The recommendations in this document are an abstraction from 1108 recommendations in specifications for a wide range of application 1109 protocols. For the purpose of comparison and to delineate the 1110 history of thinking about server identity verification within the 1111 IETF, this informative section gathers together prior art by 1112 including the exact text from various RFCs (the only modifications 1113 are changes to the names of several references to maintain coherence 1114 with the main body of this document, and the elision of irrelevant 1115 text as marked by the characters "[...]"). 1117 A.1. IMAP, POP3, and ACAP (1999) 1119 In 1999, [USINGTLS] specified the following text regarding server 1120 identity verification in IMAP, POP3, and ACAP: 1122 ###### 1124 2.4. Server Identity Check 1126 During the TLS negotiation, the client MUST check its understanding 1127 of the server hostname against the server's identity as presented in 1128 the server Certificate message, in order to prevent man-in-the-middle 1129 attacks. Matching is performed according to these rules: 1131 o The client MUST use the server hostname it used to open the 1132 connection as the value to compare against the server name as 1133 expressed in the server certificate. The client MUST NOT use any 1134 form of the server hostname derived from an insecure remote source 1135 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1136 o If a subjectAltName extension of type dNSName is present in the 1137 certificate, it SHOULD be used as the source of the server's 1138 identity. 1140 o Matching is case-insensitive. 1141 o A "*" wildcard character MAY be used as the left-most name 1142 component in the certificate. For example, *.example.com would 1143 match a.example.com, foo.example.com, etc. but would not match 1144 example.com. 1145 o If the certificate contains multiple names (e.g. more than one 1146 dNSName field), then a match with any one of the fields is 1147 considered acceptable. 1149 If the match fails, the client SHOULD either ask for explicit user 1150 confirmation, or terminate the connection and indicate the server's 1151 identity is suspect. 1153 ###### 1155 A.2. HTTP (2000) 1157 In 2000, [HTTP-TLS] specified the following text regarding server 1158 identity verification in HTTP: 1160 ###### 1162 3.1. Server Identity 1164 In general, HTTP/TLS requests are generated by dereferencing a URI. 1165 As a consequence, the hostname for the server is known to the client. 1166 If the hostname is available, the client MUST check it against the 1167 server's identity as presented in the server's Certificate message, 1168 in order to prevent man-in-the-middle attacks. 1170 If the client has external information as to the expected identity of 1171 the server, the hostname check MAY be omitted. (For instance, a 1172 client may be connecting to a machine whose address and hostname are 1173 dynamic but the client knows the certificate that the server will 1174 present.) In such cases, it is important to narrow the scope of 1175 acceptable certificates as much as possible in order to prevent man 1176 in the middle attacks. In special cases, it may be appropriate for 1177 the client to simply ignore the server's identity, but it must be 1178 understood that this leaves the connection open to active attack. 1180 If a subjectAltName extension of type dNSName is present, that MUST 1181 be used as the identity. Otherwise, the (most specific) Common Name 1182 field in the Subject field of the certificate MUST be used. Although 1183 the use of the Common Name is existing practice, it is deprecated and 1184 Certification Authorities are encouraged to use the dNSName instead. 1186 Matching is performed using the matching rules specified by 1187 [PKIX-OLD]. If more than one identity of a given type is present in 1188 the certificate (e.g., more than one dNSName name, a match in any one 1189 of the set is considered acceptable.) Names may contain the wildcard 1190 character * which is considered to match any single domain name 1191 component or component fragment. E.g., *.a.com matches foo.a.com but 1192 not bar.foo.a.com. f*.com matches foo.com but not bar.com. 1194 In some cases, the URI is specified as an IP address rather than a 1195 hostname. In this case, the iPAddress subjectAltName must be present 1196 in the certificate and must exactly match the IP in the URI. 1198 If the hostname does not match the identity in the certificate, user 1199 oriented clients MUST either notify the user (clients MAY give the 1200 user the opportunity to continue with the connection in any case) or 1201 terminate the connection with a bad certificate error. Automated 1202 clients MUST log the error to an appropriate audit log (if available) 1203 and SHOULD terminate the connection (with a bad certificate error). 1204 Automated clients MAY provide a configuration setting that disables 1205 this check, but MUST provide a setting which enables it. 1207 Note that in many cases the URI itself comes from an untrusted 1208 source. The above-described check provides no protection against 1209 attacks where this source is compromised. For example, if the URI 1210 was obtained by clicking on an HTML page which was itself obtained 1211 without using HTTP/TLS, a man in the middle could have replaced the 1212 URI. In order to prevent this form of attack, users should carefully 1213 examine the certificate presented by the server to determine if it 1214 meets their expectations. 1216 ###### 1218 A.3. LDAP (2000/2006) 1220 In 2000, [LDAP-TLS] specified the following text regarding server 1221 identity verification in LDAP: 1223 ###### 1225 3.6. Server Identity Check 1227 The client MUST check its understanding of the server's hostname 1228 against the server's identity as presented in the server's 1229 Certificate message, in order to prevent man-in-the-middle attacks. 1231 Matching is performed according to these rules: 1233 o The client MUST use the server hostname it used to open the LDAP 1234 connection as the value to compare against the server name as 1235 expressed in the server's certificate. The client MUST NOT use 1236 the server's canonical DNS name or any other derived form of name. 1237 o If a subjectAltName extension of type dNSName is present in the 1238 certificate, it SHOULD be used as the source of the server's 1239 identity. 1240 o Matching is case-insensitive. 1241 o The "*" wildcard character is allowed. If present, it applies 1242 only to the left-most name component. 1244 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not 1245 bar.com. If more than one identity of a given type is present in the 1246 certificate (e.g. more than one dNSName name), a match in any one of 1247 the set is considered acceptable. 1249 If the hostname does not match the dNSName-based identity in the 1250 certificate per the above check, user-oriented clients SHOULD either 1251 notify the user (clients MAY give the user the opportunity to 1252 continue with the connection in any case) or terminate the connection 1253 and indicate that the server's identity is suspect. Automated 1254 clients SHOULD close the connection, returning and/or logging an 1255 error indicating that the server's identity is suspect. 1257 Beyond the server identity checks described in this section, clients 1258 SHOULD be prepared to do further checking to ensure that the server 1259 is authorized to provide the service it is observed to provide. The 1260 client MAY need to make use of local policy information. 1262 ###### 1264 In 2006, [LDAP-AUTH] specified the following text regarding server 1265 identity verification in LDAP: 1267 ###### 1269 3.1.3. Server Identity Check 1271 In order to prevent man-in-the-middle attacks, the client MUST verify 1272 the server's identity (as presented in the server's Certificate 1273 message). In this section, the client's understanding of the 1274 server's identity (typically the identity used to establish the 1275 transport connection) is called the "reference identity". 1277 The client determines the type (e.g., DNS name or IP address) of the 1278 reference identity and performs a comparison between the reference 1279 identity and each subjectAltName value of the corresponding type 1280 until a match is produced. Once a match is produced, the server's 1281 identity has been verified, and the server identity check is 1282 complete. Different subjectAltName types are matched in different 1283 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of 1284 various subjectAltName types. 1286 The client may map the reference identity to a different type prior 1287 to performing a comparison. Mappings may be performed for all 1288 available subjectAltName types to which the reference identity can be 1289 mapped; however, the reference identity should only be mapped to 1290 types for which the mapping is either inherently secure (e.g., 1291 extracting the DNS name from a URI to compare with a subjectAltName 1292 of type dNSName) or for which the mapping is performed in a secure 1293 manner (e.g., using [DNSSEC], or using user- or admin-configured 1294 host-to-address/address-to-host lookup tables). 1296 The server's identity may also be verified by comparing the reference 1297 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last 1298 Relative Distinguished Name (RDN) of the subjectName field of the 1299 server's certificate (where "last" refers to the DER-encoded order, 1300 not the order of presentation in a string representation of DER- 1301 encoded data). This comparison is performed using the rules for 1302 comparison of DNS names in Section 3.1.3.1, below, with the exception 1303 that no wildcard matching is allowed. Although the use of the Common 1304 Name value is existing practice, it is deprecated, and Certification 1305 Authorities are encouraged to provide subjectAltName values instead. 1306 Note that the TLS implementation may represent DNs in certificates 1307 according to X.500 or other conventions. For example, some X.500 1308 implementations order the RDNs in a DN using a left-to-right (most 1309 significant to least significant) convention instead of LDAP's right- 1310 to-left convention. 1312 If the server identity check fails, user-oriented clients SHOULD 1313 either notify the user (clients may give the user the opportunity to 1314 continue with the LDAP session in this case) or close the transport 1315 connection and indicate that the server's identity is suspect. 1316 Automated clients SHOULD close the transport connection and then 1317 return or log an error indicating that the server's identity is 1318 suspect or both. 1320 Beyond the server identity check described in this section, clients 1321 should be prepared to do further checking to ensure that the server 1322 is authorized to provide the service it is requested to provide. The 1323 client may need to make use of local policy information in making 1324 this determination. 1326 3.1.3.1. Comparison of DNS Names 1328 If the reference identity is an internationalized domain name, 1329 conforming implementations MUST convert it to the ASCII Compatible 1330 Encoding (ACE) format as specified in Section 4 of RFC 3490 1331 [IDNA2003] before comparison with subjectAltName values of type 1332 dNSName. Specifically, conforming implementations MUST perform the 1333 conversion operation specified in Section 4 of RFC 3490 as follows: 1335 o in step 1, the domain name SHALL be considered a "stored string"; 1336 o in step 3, set the flag called "UseSTD3ASCIIRules"; 1337 o in step 4, process each label with the "ToASCII" operation; and 1338 o in step 5, change all label separators to U+002E (full stop). 1340 After performing the "to-ASCII" conversion, the DNS labels and names 1341 MUST be compared for equality according to the rules specified in 1342 Section 3 of RFC3490. 1344 The '*' (ASCII 42) wildcard character is allowed in subjectAltName 1345 values of type dNSName, and then only as the left-most (least 1346 significant) DNS label in that value. This wildcard matches any 1347 left-most DNS label in the server name. That is, the subject 1348 *.example.com matches the server names a.example.com and 1349 b.example.com, but does not match example.com or a.b.example.com. 1351 3.1.3.2. Comparison of IP Addresses 1353 When the reference identity is an IP address, the identity MUST be 1354 converted to the "network byte order" octet string representation 1355 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet 1356 string will contain exactly four octets. For IP Version 6, as 1357 specified in RFC 2460, the octet string will contain exactly sixteen 1358 octets. This octet string is then compared against subjectAltName 1359 values of type iPAddress. A match occurs if the reference identity 1360 octet string and value octet strings are identical. 1362 3.1.3.3. Comparison of Other subjectName Types 1364 Client implementations MAY support matching against subjectAltName 1365 values of other types as described in other documents. 1367 ###### 1369 A.4. SMTP (2002/2007) 1371 In 2002, [SMTP-TLS] specified the following text regarding server 1372 identity verification in SMTP: 1374 ###### 1376 4.1 Processing After the STARTTLS Command 1378 [...] 1379 The decision of whether or not to believe the authenticity of the 1380 other party in a TLS negotiation is a local matter. However, some 1381 general rules for the decisions are: 1383 o A SMTP client would probably only want to authenticate an SMTP 1384 server whose server certificate has a domain name that is the 1385 domain name that the client thought it was connecting to. 1387 [...] 1389 ###### 1391 In 2006, [SMTP-AUTH] specified the following text regarding server 1392 identity verification in SMTP: 1394 ###### 1396 14. Additional Requirements When Using SASL PLAIN over TLS 1398 [...] 1400 After a successful [TLS] negotiation, the client MUST check its 1401 understanding of the server hostname against the server's identity as 1402 presented in the server Certificate message, in order to prevent man- 1403 in-the-middle attacks. If the match fails, the client MUST NOT 1404 attempt to authenticate using the SASL PLAIN mechanism. Matching is 1405 performed according to the following rules: 1407 The client MUST use the server hostname it used to open the 1408 connection as the value to compare against the server name as 1409 expressed in the server certificate. The client MUST NOT use any 1410 form of the server hostname derived from an insecure remote source 1411 (e.g., insecure DNS lookup). CNAME canonicalization is not done. 1412 If a subjectAltName extension of type dNSName is present in the 1413 certificate, it SHOULD be used as the source of the server's 1414 identity. 1415 Matching is case-insensitive. 1416 A "*" wildcard character MAY be used as the leftmost name 1417 component in the certificate. For example, *.example.com would 1418 match a.example.com, foo.example.com, etc., but would not match 1419 example.com. 1420 If the certificate contains multiple names (e.g., more than one 1421 dNSName field), then a match with any one of the fields is 1422 considered acceptable. 1424 ###### 1426 A.5. XMPP (2004) 1428 In 2004, [XMPP] specified the following text regarding server 1429 identity verification in XMPP: 1431 ###### 1433 14.2. Certificate Validation 1435 When an XMPP peer communicates with another peer securely, it MUST 1436 validate the peer's certificate. There are three possible cases: 1438 Case #1: The peer contains an End Entity certificate which appears 1439 to be certified by a chain of certificates terminating in a trust 1440 anchor (as described in Section 6.1 of [PKIX]). 1441 Case #2: The peer certificate is certified by a Certificate 1442 Authority not known to the validating peer. 1443 Case #3: The peer certificate is self-signed. 1445 In Case #1, the validating peer MUST do one of two things: 1446 1. Verify the peer certificate according to the rules of [PKIX]. 1447 The certificate SHOULD then be checked against the expected 1448 identity of the peer following the rules described in [HTTP-TLS], 1449 except that a subjectAltName extension of type "xmpp" MUST be 1450 used as the identity if present. If one of these checks fails, 1451 user-oriented clients MUST either notify the user (clients MAY 1452 give the user the opportunity to continue with the connection in 1453 any case) or terminate the connection with a bad certificate 1454 error. Automated clients SHOULD terminate the connection (with a 1455 bad certificate error) and log the error to an appropriate audit 1456 log. Automated clients MAY provide a configuration setting that 1457 disables this check, but MUST provide a setting that enables it. 1458 2. The peer SHOULD show the certificate to a user for approval, 1459 including the entire certificate chain. The peer MUST cache the 1460 certificate (or some non-forgeable representation such as a 1461 hash). In future connections, the peer MUST verify that the same 1462 certificate was presented and MUST notify the user if it has 1463 changed. 1465 In Case #2 and Case #3, implementations SHOULD act as in (2) above. 1467 ###### 1469 At the time of this writing, [XMPPBIS] refers to this document for 1470 rules regarding server identity verification in XMPP. 1472 A.6. NNTP (2006) 1474 In 2006, [NNTP-TLS] specified the following text regarding server 1475 identity verification in NNTP: 1477 ###### 1479 5. Security Considerations 1481 [...] 1483 During the TLS negotiation, the client MUST check its understanding 1484 of the server hostname against the server's identity as presented in 1485 the server Certificate message, in order to prevent man-in-the-middle 1486 attacks. Matching is performed according to these rules: 1488 o The client MUST use the server hostname it used to open the 1489 connection (or the hostname specified in TLS "server_name" 1490 extension [TLS]) as the value to compare against the server name 1491 as expressed in the server certificate. The client MUST NOT use 1492 any form of the server hostname derived from an insecure remote 1493 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1494 done. 1495 o If a subjectAltName extension of type dNSName is present in the 1496 certificate, it SHOULD be used as the source of the server's 1497 identity. 1498 o Matching is case-insensitive. 1499 o A "*" wildcard character MAY be used as the left-most name 1500 component in the certificate. For example, *.example.com would 1501 match a.example.com, foo.example.com, etc., but would not match 1502 example.com. 1503 o If the certificate contains multiple names (e.g., more than one 1504 dNSName field), then a match with any one of the fields is 1505 considered acceptable. 1507 If the match fails, the client SHOULD either ask for explicit user 1508 confirmation or terminate the connection with a QUIT command and 1509 indicate the server's identity is suspect. 1511 Additionally, clients MUST verify the binding between the identity of 1512 the servers to which they connect and the public keys presented by 1513 those servers. Clients SHOULD implement the algorithm in Section 6 1514 of [PKIX] for general certificate validation, but MAY supplement that 1515 algorithm with other validation methods that achieve equivalent 1516 levels of verification (such as comparing the server certificate 1517 against a local store of already-verified certificates and identity 1518 bindings). 1520 ###### 1522 A.7. NETCONF (2006/2009) 1524 In 2006, [NETCONF-SSH] specified the following text regarding server 1525 identity verification in NETCONF: 1527 ###### 1529 6. Security Considerations 1531 The identity of the server MUST be verified and authenticated by the 1532 client according to local policy before password-based authentication 1533 data or any configuration or state data is sent to or received from 1534 the server. The identity of the client MUST also be verified and 1535 authenticated by the server according to local policy to ensure that 1536 the incoming client request is legitimate before any configuration or 1537 state data is sent to or received from the client. Neither side 1538 should establish a NETCONF over SSH connection with an unknown, 1539 unexpected, or incorrect identity on the opposite side. 1541 ###### 1543 In 2009, [NETCONF-TLS] specified the following text regarding server 1544 identity verification in NETCONF: 1546 ###### 1548 3.1. Server Identity 1550 During the TLS negotiation, the client MUST carefully examine the 1551 certificate presented by the server to determine if it meets the 1552 client's expectations. Particularly, the client MUST check its 1553 understanding of the server hostname against the server's identity as 1554 presented in the server Certificate message, in order to prevent man- 1555 in-the-middle attacks. 1557 Matching is performed according to the rules below (following the 1558 example of [NNTP-TLS]): 1560 o The client MUST use the server hostname it used to open the 1561 connection (or the hostname specified in the TLS "server_name" 1562 extension [TLS]) as the value to compare against the server name 1563 as expressed in the server certificate. The client MUST NOT use 1564 any form of the server hostname derived from an insecure remote 1565 source (e.g., insecure DNS lookup). CNAME canonicalization is not 1566 done. 1568 o If a subjectAltName extension of type dNSName is present in the 1569 certificate, it MUST be used as the source of the server's 1570 identity. 1571 o Matching is case-insensitive. 1572 o A "*" wildcard character MAY be used as the leftmost name 1573 component in the certificate. For example, *.example.com would 1574 match a.example.com, foo.example.com, etc., but would not match 1575 example.com. 1576 o If the certificate contains multiple names (e.g., more than one 1577 dNSName field), then a match with any one of the fields is 1578 considered acceptable. 1580 If the match fails, the client MUST either ask for explicit user 1581 confirmation or terminate the connection and indicate the server's 1582 identity is suspect. 1584 Additionally, clients MUST verify the binding between the identity of 1585 the servers to which they connect and the public keys presented by 1586 those servers. Clients SHOULD implement the algorithm in Section 6 1587 of [PKIX] for general certificate validation, but MAY supplement that 1588 algorithm with other validation methods that achieve equivalent 1589 levels of verification (such as comparing the server certificate 1590 against a local store of already-verified certificates and identity 1591 bindings). 1593 If the client has external information as to the expected identity of 1594 the server, the hostname check MAY be omitted. 1596 ###### 1598 A.8. Syslog (2009) 1600 In 2009, [SYSLOG-TLS] specified the following text regarding server 1601 identity verification in Syslog: 1603 ###### 1605 5.2. Subject Name Authorization 1607 Implementations MUST support certification path validation [PKIX]. 1608 In addition, they MUST support specifying the authorized peers using 1609 locally configured host names and matching the name against the 1610 certificate as follows. 1612 o Implementations MUST support matching the locally configured host 1613 name against a dNSName in the subjectAltName extension field and 1614 SHOULD support checking the name against the common name portion 1615 of the subject distinguished name. 1617 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of 1618 the subjectAltName extension (and in common name, if used to store 1619 the host name), but only as the left-most (least significant) DNS 1620 label in that value. This wildcard matches any left-most DNS 1621 label in the server name. That is, the subject *.example.com 1622 matches the server names a.example.com and b.example.com, but does 1623 not match example.com or a.b.example.com. Implementations MUST 1624 support wildcards in certificates as specified above, but MAY 1625 provide a configuration option to disable them. 1626 o Locally configured names MAY contain the wildcard character to 1627 match a range of values. The types of wildcards supported MAY be 1628 more flexible than those allowed in subject names, making it 1629 possible to support various policies for different environments. 1630 For example, a policy could allow for a trust-root-based 1631 authorization where all credentials issued by a particular CA 1632 trust root are authorized. 1633 o If the locally configured name is an internationalized domain 1634 name, conforming implementations MUST convert it to the ASCII 1635 Compatible Encoding (ACE) format for performing comparisons, as 1636 specified in Section 7 of [PKIX]. 1637 o Implementations MAY support matching a locally configured IP 1638 address against an iPAddress stored in the subjectAltName 1639 extension. In this case, the locally configured IP address is 1640 converted to an octet string as specified in [PKIX], Section 1641 4.2.1.6. A match occurs if this octet string is equal to the 1642 value of iPAddress in the subjectAltName extension. 1644 ###### 1646 A.9. SIP (2010) 1648 At the time of this writing, [SIP-CERTS] specified text regarding 1649 server identity verification in the Session Initiation Protocol 1650 (SIP). However, that specification has not yet been approved by the 1651 IESG and text cannot be considered final. 1653 The relevant text follows. 1655 ###### 1657 7.2. Comparing SIP Identities 1659 When an implementation (either client or server) compares two values 1660 as SIP domain identities: 1661 Implementations MUST compare only the DNS name component of each 1662 SIP domain identifier; an implementation MUST NOT use any scheme 1663 or parameters in the comparison. 1665 Implementations MUST compare the values as DNS names, which means 1666 that the comparison is case insensitive as specified by 1667 [DNS-CASE]. Implementations MUST handle Internationalized Domain 1668 Names (IDNs) in accordance with Section 7.2 of [PKIX]. 1669 Implementations MUST match the values in their entirety: 1670 Implementations MUST NOT match suffixes. For example, 1671 "foo.example.com" does not match "example.com". 1672 Implemenations MUST NOT match any form of wildcard, such as a 1673 leading "." or "*." with any other DNS label or sequence of 1674 labels. For example, "*.example.com" matches only 1675 "*.example.com" but not "foo.example.com". Similarly, 1676 ".example.com" matches only ".example.com", and does not match 1677 "foo.example.com." 1678 [HTTP-TLS] allows the dNSName component to contain a 1679 wildcard; e.g., "DNS:*.example.com". [PKIX], while not 1680 disallowing this explicitly, leaves the interpretation of 1681 wildcards to the individual specification. [SIP] does not 1682 provide any guidelines on the presence of wildcards in 1683 certificates. Through the rule above, this document 1684 prohibits such wildcards in certificates for SIP domains. 1686 ###### 1688 A.10. GIST (2010) 1690 In 2010, [GIST] specified the following text regarding server 1691 identity verification in the General Internet Signalling Transport: 1693 ###### 1695 5.7.3.1. Identity Checking in TLS 1697 After TLS authentication, a node MUST check the identity presented by 1698 the peer in order to avoid man-in-the-middle attacks, and verify that 1699 the peer is authorised to take part in signalling at the GIST layer. 1700 The authorisation check is carried out by comparing the presented 1701 identity with each Authorised Peer Database (APD) entry in turn, as 1702 discussed in Section 4.4.2. This section defines the identity 1703 comparison algorithm for a single APD entry. 1705 For TLS authentication with X.509 certificates, an identity from the 1706 DNS namespace MUST be checked against each subjectAltName extension 1707 of type dNSName present in the certificate. If no such extension is 1708 present, then the identity MUST be compared to the (most specific) 1709 Common Name in the Subject field of the certificate. When matching 1710 DNS names against dNSName or Common Name fields, matching is case- 1711 insensitive. Also, a "*" wildcard character MAY be used as the left- 1712 most name component in the certificate or identity in the APD. For 1713 example, *.example.com in the APD would match certificates for 1714 a.example.com, foo.example.com, *.example.com, etc., but would not 1715 match example.com. Similarly, a certificate for *.example.com would 1716 be valid for APD identities of a.example.com, foo.example.com, 1717 *.example.com, etc., but not example.com. 1719 Additionally, a node MUST verify the binding between the identity of 1720 the peer to which it connects and the public key presented by that 1721 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX] 1722 for general certificate validation, but MAY supplement that algorithm 1723 with other validation methods that achieve equivalent levels of 1724 verification (such as comparing the server certificate against a 1725 local store of already-verified certificates and identity bindings). 1727 For TLS authentication with pre-shared keys, the identity in the 1728 psk_identity_hint (for the server identity, i.e. the Responding node) 1729 or psk_identity (for the client identity, i.e. the Querying node) 1730 MUST be compared to the identities in the APD. 1732 ###### 1734 Authors' Addresses 1736 Peter Saint-Andre (editor) 1737 Cisco 1739 Email: psaintan@cisco.com 1741 Jeff Hodges (editor) 1742 PayPal 1744 Email: Jeff.Hodges@PayPal.com