7Internet Engineering Task Force (IETF) P. Saint-Andre
8Request for Comments: 6125 Cisco
9Category: Standards Track J. Hodges
14 Representation and Verification of Domain-Based Application Service
15 Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
16 Certificates in the Context of Transport Layer Security (TLS)
20 Many application technologies enable secure communication between two
21 entities by means of Internet Public Key Infrastructure Using X.509
22 (PKIX) certificates in the context of Transport Layer Security (TLS).
23 This document specifies procedures for representing and verifying the
24 identity of application services in such interactions.
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6125.
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Saint-Andre & Hodges Standards Track [Page 1]
60RFC 6125 Service Identity March 2011
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
67 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 1.3. How to Read This Document . . . . . . . . . . . . . . . . 4
69 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
70 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5
71 1.6. Generalization from Current Technologies . . . . . . . . . 6
72 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
73 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7
74 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7
75 1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
76 2. Naming of Application Services . . . . . . . . . . . . . . . . 13
77 2.1. Naming Application Services . . . . . . . . . . . . . . . 13
78 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 14
79 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15
80 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17
81 3. Designing Application Protocols . . . . . . . . . . . . . . . 18
82 4. Representing Server Identity . . . . . . . . . . . . . . . . . 18
83 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18
84 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20
85 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21
86 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 21
87 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
88 6.2. Constructing a List of Reference Identifiers . . . . . . . 22
89 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22
90 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24
91 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25
92 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26
93 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27
94 6.4.2. Checking of Internationalized Domain Names . . . . . . 27
95 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27
96 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28
97 6.5. Matching the Application Service Type Portion . . . . . . 28
98 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
99 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29
100 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29
101 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29
102 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29
103 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30
104 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30
105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
106 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30
107 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31
108 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32
109 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32
110 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
114Saint-Andre & Hodges Standards Track [Page 2]
116RFC 6125 Service Identity March 2011
119 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
120 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
121 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
122 10.2. Informative References . . . . . . . . . . . . . . . . . . 34
123 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40
124 Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 42
125 B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 42
126 B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 43
127 B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44
128 B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47
129 B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 49
130 B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 50
131 B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 51
132 B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52
133 B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 54
134 B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
135 B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 55
141 The visible face of the Internet largely consists of services that
142 employ a client-server architecture in which an interactive or
143 automated client communicates with an application service in order to
144 retrieve or upload information, communicate with other entities, or
145 access a broader network of services. When a client communicates
146 with an application service using Transport Layer Security [TLS] or
147 Datagram Transport Layer Security [DTLS], it references some notion
148 of the server's identity (e.g., "the website at example.com") while
149 attempting to establish secure communication. Likewise, during TLS
150 negotiation, the server presents its notion of the service's identity
151 in the form of a public-key certificate that was issued by a
152 certification authority (CA) in the context of the Internet Public
153 Key Infrastructure using X.509 [PKIX]. Informally, we can think of
154 these identities as the client's "reference identity" and the
155 server's "presented identity" (these rough ideas are defined more
156 precisely later in this document through the concept of particular
157 identifiers). In general, a client needs to verify that the server's
158 presented identity matches its reference identity so it can
159 authenticate the communication.
161 Many application technologies adhere to the pattern just outlined.
162 Such protocols have traditionally specified their own rules for
163 representing and verifying application service identity.
164 Unfortunately, this divergence of approaches has caused some
165 confusion among certification authorities, application developers,
166 and protocol designers.
170Saint-Andre & Hodges Standards Track [Page 3]
172RFC 6125 Service Identity March 2011
175 Therefore, to codify secure procedures for the implementation and
176 deployment of PKIX-based authentication, this document specifies
177 recommended procedures for representing and verifying application
178 service identity in certificates intended for use in application
179 protocols employing TLS.
183 The primary audience for this document consists of application
184 protocol designers, who can reference this document instead of
185 defining their own rules for the representation and verification of
186 application service identity. Secondarily, the audience consists of
187 certification authorities, service providers, and client developers
188 from technology communities that might reuse the recommendations in
189 this document when defining certificate issuance policies, generating
190 certificate signing requests, or writing software algorithms for
1931.3. How to Read This Document
195 This document is longer than the authors would have liked because it
196 was necessary to carefully define terminology, explain the underlying
197 concepts, define the scope, and specify recommended behavior for both
198 certification authorities and application software implementations.
199 The following sections are of special interest to various audiences:
201 o Protocol designers might want to first read the checklist in
204 o Certification authorities might want to first read the
205 recommendations for representation of server identity in
208 o Service providers might want to first read the recommendations for
209 requesting of server certificates in Section 5.
211 o Software implementers might want to first read the recommendations
212 for verification of server identity in Section 6.
214 The sections on terminology (Section 1.8), naming of application
215 services (Section 2), document scope (Section 1.7), and the like
216 provide useful background information regarding the recommendations
217 and guidelines that are contained in the above-referenced sections,
218 but are not absolutely necessary for a first reading of this
226Saint-Andre & Hodges Standards Track [Page 4]
228RFC 6125 Service Identity March 2011
233 This document does not supersede the rules for certificate issuance
234 or validation provided in [PKIX]. Therefore, [PKIX] is authoritative
235 on any point that might also be discussed in this document.
236 Furthermore, [PKIX] also governs any certificate-related topic on
237 which this document is silent, including but not limited to
238 certificate syntax, certificate extensions such as name constraints
239 and extended key usage, and handling of certification paths.
241 This document addresses only name forms in the leaf "end entity"
242 server certificate, not any name forms in the chain of certificates
243 used to validate the server certificate. Therefore, in order to
244 ensure proper authentication, application clients need to verify the
245 entire certification path per [PKIX].
247 This document also does not supersede the rules for verifying service
248 identity provided in specifications for existing application
249 protocols published prior to this document, such as those excerpted
250 under Appendix B. However, the procedures described here can be
251 referenced by future specifications, including updates to
252 specifications for existing application protocols if the relevant
253 technology communities agree to do so.
2551.5. Overview of Recommendations
257 To orient the reader, this section provides an informational overview
258 of the recommendations contained in this document.
260 For the primary audience of application protocol designers, this
261 document provides recommended procedures for the representation and
262 verification of application service identity within PKIX certificates
263 used in the context of TLS.
265 For the secondary audiences, in essence this document encourages
266 certification authorities, application service providers, and
267 application client developers to coalesce on the following practices:
269 o Move away from including and checking strings that look like
270 domain names in the subject's Common Name.
272 o Move toward including and checking DNS domain names via the
273 subjectAlternativeName extension designed for that purpose:
282Saint-Andre & Hodges Standards Track [Page 5]
284RFC 6125 Service Identity March 2011
287 o Move toward including and checking even more specific
288 subjectAlternativeName extensions where appropriate for using the
289 protocol (e.g., uniformResourceIdentifier and the otherName form
292 o Move away from the issuance of so-called wildcard certificates
293 (e.g., a certificate containing an identifier for
296 These suggestions are not entirely consistent with all practices that
297 are currently followed by certification authorities, client
298 developers, and service providers. However, they reflect the best
299 aspects of current practices and are expected to become more widely
300 adopted in the coming years.
3021.6. Generalization from Current Technologies
304 This document attempts to generalize best practices from the many
305 application technologies that currently use PKIX certificates with
306 TLS. Such technologies include, but are not limited to:
308 o The Internet Message Access Protocol [IMAP] and the Post Office
309 Protocol [POP3]; see also [USINGTLS]
311 o The Hypertext Transfer Protocol [HTTP]; see also [HTTP-TLS]
313 o The Lightweight Directory Access Protocol [LDAP]; see also
314 [LDAP-AUTH] and its predecessor [LDAP-TLS]
316 o The Simple Mail Transfer Protocol [SMTP]; see also [SMTP-AUTH] and
319 o The Extensible Messaging and Presence Protocol [XMPP]; see also
322 o The Network News Transfer Protocol [NNTP]; see also [NNTP-TLS]
324 o The NETCONF Configuration Protocol [NETCONF]; see also
325 [NETCONF-SSH] and [NETCONF-TLS]
327 o The Syslog Protocol [SYSLOG]; see also [SYSLOG-TLS] and
330 o The Session Initiation Protocol [SIP]; see also [SIP-CERTS]
332 o The Simple Network Management Protocol [SNMP]; see also [SNMP-TLS]
334 o The General Internet Signalling Transport [GIST]
338Saint-Andre & Hodges Standards Track [Page 6]
340RFC 6125 Service Identity March 2011
343 However, as noted, this document does not supersede the rules for
344 verifying service identity provided in specifications for those
345 application protocols.
351 This document applies only to service identities associated with
352 fully qualified DNS domain names, only to TLS and DTLS (or the older
353 Secure Sockets Layer (SSL) technology), and only to PKIX-based
354 systems. As a result, the scenarios described in the following
355 section are out of scope for this specification (although they might
356 be addressed by future specifications).
360 The following topics are out of scope for this specification:
362 o Client or end-user identities.
364 Certificates representing client or end-user identities (e.g., the
365 rfc822Name identifier) can be used for mutual authentication
366 between a client and server or between two clients, thus enabling
367 stronger client-server security or end-to-end security. However,
368 certification authorities, application developers, and service
369 operators have less experience with client certificates than with
370 server certificates, thus giving us fewer models from which to
371 generalize and a less solid basis for defining best practices.
373 o Identifiers other than fully qualified DNS domain names.
375 Some certification authorities issue server certificates based on
376 IP addresses, but preliminary evidence indicates that such
377 certificates are a very small percentage (less than 1%) of issued
378 certificates. Furthermore, IP addresses are not necessarily
379 reliable identifiers for application services because of the
380 existence of private internets [PRIVATE], host mobility, multiple
381 interfaces on a given host, Network Address Translators (NATs)
382 resulting in different addresses for a host from different
383 locations on the network, the practice of grouping many hosts
384 together behind a single IP address, etc. Most fundamentally,
385 most users find DNS domain names much easier to work with than IP
386 addresses, which is why the domain name system was designed in the
387 first place. We prefer to define best practices for the much more
388 common use case and not to complicate the rules in this
394Saint-Andre & Hodges Standards Track [Page 7]
396RFC 6125 Service Identity March 2011
399 Furthermore, we focus here on application service identities, not
400 specific resources located at such services. Therefore this
401 document discusses Uniform Resource Identifiers [URI] only as a
402 way to communicate a DNS domain name (via the URI "host" component
403 or its equivalent), not as a way to communicate other aspects of a
404 service such as a specific resource (via the URI "path" component)
405 or parameters (via the URI "query" component).
407 We also do not discuss attributes unrelated to DNS domain names,
408 such as those defined in [X.520] and other such specifications
409 (e.g., organizational attributes, geographical attributes, company
410 logos, and the like).
412 o Security protocols other than [TLS], [DTLS], or the older Secure
413 Sockets Layer (SSL) technology.
415 Although other secure, lower-layer protocols exist and even employ
416 PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases
417 can differ from those of TLS-based and DTLS-based application
418 technologies. Furthermore, application technologies have less
419 experience with IPsec than with TLS, thus making it more difficult
420 to gather feedback on proposed best practices.
422 o Keys or certificates employed outside the context of PKIX-based
425 Some deployed application technologies use a web of trust model
426 based on or similar to OpenPGP [OPENPGP], or use self-signed
427 certificates, or are deployed on networks that are not directly
428 connected to the public Internet and therefore cannot depend on
429 Certificate Revocation Lists (CRLs) or the Online Certificate
430 Status Protocol [OCSP] to check CA-issued certificates. However,
431 the method for binding a public key to an identifier in OpenPGP
432 differs essentially from the method in X.509, the data in self-
433 signed certificates has not been certified by a third party in any
434 way, and checking of CA-issued certificates via CRLs or OCSP is
435 critically important to maintaining the security of PKIX-based
436 systems. Attempting to define best practices for such
437 technologies would unduly complicate the rules defined in this
440 o Certification authority policies, such as:
442 * What types or "classes" of certificates to issue and whether to
443 apply different policies for them (e.g., allow the wildcard
444 character in certificates issued to individuals who have
445 provided proof of identity but do not allow the wildcard
446 character in "Extended Validation" certificates [EV-CERTS]).
450Saint-Andre & Hodges Standards Track [Page 8]
452RFC 6125 Service Identity March 2011
455 * Whether to issue certificates based on IP addresses (or some
456 other form, such as relative domain names) in addition to fully
457 qualified DNS domain names.
459 * Which identifiers to include (e.g., whether to include SRV-IDs
460 or URI-IDs as defined in the body of this specification).
462 * How to certify or validate fully qualified DNS domain names and
463 application service types.
465 * How to certify or validate other kinds of information that
466 might be included in a certificate (e.g., organization name).
468 o Resolution of DNS domain names.
470 Although the process whereby a client resolves the DNS domain name
471 of an application service can involve several steps (e.g., this is
472 true of resolutions that depend on DNS SRV resource records,
473 Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and
474 related technologies such as [S-NAPTR]), for our purposes we care
475 only about the fact that the client needs to verify the identity
476 of the entity with which it communicates as a result of the
477 resolution process. Thus the resolution process itself is out of
478 scope for this specification.
480 o User interface issues.
482 In general, such issues are properly the responsibility of client
483 software developers and standards development organizations
484 dedicated to particular application technologies (see, for
489 Because many concepts related to "identity" are often too vague to be
490 actionable in application protocols, we define a set of more concrete
491 terms for use in this specification.
493 application service: A service on the Internet that enables
494 interactive and automated clients to connect for the purpose of
495 retrieving or uploading information, communicating with other
496 entities, or connecting to a broader network of services.
498 application service provider: An organization or individual that
499 hosts or deploys an application service.
506Saint-Andre & Hodges Standards Track [Page 9]
508RFC 6125 Service Identity March 2011
511 application service type: A formal identifier for the application
512 protocol used to provide a particular kind of application service
513 at a domain; the application service type typically takes the form
514 of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service
517 attribute-type-and-value pair: A colloquial name for the ASN.1-based
518 construction comprising a Relative Distinguished Name (RDN), which
519 itself is a building-block component of Distinguished Names. See
520 Section 2 of [LDAP-DN].
522 automated client: A software agent or device that is not directly
523 controlled by a human user.
525 delegated domain: A domain name or host name that is explicitly
526 configured for communicating with the source domain, by either (a)
527 the human user controlling an interactive client or (b) a trusted
528 administrator. In case (a), one example of delegation is an
529 account setup that specifies the domain name of a particular host
530 to be used for retrieving information or connecting to a network,
531 which might be different from the server portion of the user's
532 account name (e.g., a server at mailhost.example.com for
533 connecting to an IMAP server hosting an email address of
534 juliet@example.com). In case (b), one example of delegation is an
535 admin-configured host-to-address/address-to-host lookup table.
537 derived domain: A domain name or host name that a client has derived
538 from the source domain in an automated fashion (e.g., by means of
541 identifier: A particular instance of an identifier type that is
542 either presented by a server in a certificate or referenced by a
543 client for matching purposes.
545 identifier type: A formally defined category of identifier that can
546 be included in a certificate and therefore that can also be used
547 for matching purposes. For conciseness and convenience, we define
548 the following identifier types of interest, which are based on
549 those found in the PKIX specification [PKIX] and various PKIX
552 * CN-ID = a Relative Distinguished Name (RDN) in the certificate
553 subject field that contains one and only one attribute-type-
554 and-value pair of type Common Name (CN), where the value
555 matches the overall form of a domain name (informally, dot-
556 separated letter-digit-hyphen labels); see [PKIX] and also
562Saint-Andre & Hodges Standards Track [Page 10]
564RFC 6125 Service Identity March 2011
567 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
569 * SRV-ID = a subjectAltName entry of type otherName whose name
570 form is SRVName; see [SRVNAME]
572 * URI-ID = a subjectAltName entry of type
573 uniformResourceIdentifier whose value includes both (i) a
574 "scheme" and (ii) a "host" component (or its equivalent) that
575 matches the "reg-name" rule (where the quoted terms represent
576 the associated [ABNF] productions from [URI]); see [PKIX] and
579 interactive client: A software agent or device that is directly
580 controlled by a human user. (Other specifications related to
581 security and application protocols, such as [WSC-UI], often refer
582 to this entity as a "user agent".)
584 pinning: The act of establishing a cached name association between
585 the application service's certificate and one of the client's
586 reference identifiers, despite the fact that none of the presented
587 identifiers matches the given reference identifier. Pinning is
588 accomplished by allowing a human user to positively accept the
589 mismatch during an attempt to communicate with the application
590 service. Once a cached name association is established, the
591 certificate is said to be pinned to the reference identifier and
592 in future communication attempts the client simply verifies that
593 the service's presented certificate matches the pinned
594 certificate, as described under Section 6.6.2. (A similar
595 definition of "pinning" is provided in [WSC-UI].)
597 PKIX: PKIX is a short name for the Internet Public Key
598 Infrastructure using X.509 defined in RFC 5280 [PKIX], which
599 comprises a profile of the X.509v3 certificate specifications and
600 X.509v2 certificate revocation list (CRL) specifications for use
603 PKIX-based system: A software implementation or deployed service
604 that makes use of X.509v3 certificates and X.509v2 certificate
605 revocation lists (CRLs).
607 PKIX certificate: An X.509v3 certificate generated and employed in
610 presented identifier: An identifier that is presented by a server to
611 a client within a PKIX certificate when the client attempts to
612 establish secure communication with the server; the certificate
613 can include one or more presented identifiers of different types,
618Saint-Andre & Hodges Standards Track [Page 11]
620RFC 6125 Service Identity March 2011
623 and if the server hosts more than one domain then the certificate
624 might present distinct identifiers for each domain.
626 reference identifier: An identifier, constructed from a source
627 domain and optionally an application service type, used by the
628 client for matching purposes when examining presented identifiers.
630 source domain: The fully qualified DNS domain name that a client
631 expects an application service to present in the certificate
632 (e.g., "www.example.com"), typically input by a human user,
633 configured into a client, or provided by reference such as in a
634 hyperlink. The combination of a source domain and, optionally, an
635 application service type enables a client to construct one or more
636 reference identifiers.
638 subjectAltName entry: An identifier placed in a subjectAltName
641 subjectAltName extension: A standard PKIX certificate extension
642 [PKIX] enabling identifiers of various types to be bound to the
643 certificate subject -- in addition to, or in place of, identifiers
644 that may be embedded within or provided as a certificate's subject
647 subject field: The subject field of a PKIX certificate identifies
648 the entity associated with the public key stored in the subject
649 public key field (see Section 4.1.2.6 of [PKIX]).
651 subject name: In an overall sense, a subject's name(s) can be
652 represented by or in the subject field, the subjectAltName
653 extension, or both (see [PKIX] for details). More specifically,
654 the term often refers to the name of a PKIX certificate's subject,
655 encoded as the X.501 type Name and conveyed in a certificate's
656 subject field (see Section 4.1.2.6 of [PKIX]).
658 TLS client: An entity that assumes the role of a client in a
659 Transport Layer Security [TLS] negotiation. In this specification
660 we generally assume that the TLS client is an (interactive or
661 automated) application client; however, in application protocols
662 that enable server-to-server communication, the TLS client could
663 be a peer application service.
665 TLS server: An entity that assumes the role of a server in a
666 Transport Layer Security [TLS] negotiation; in this specification
667 we assume that the TLS server is an application service.
674Saint-Andre & Hodges Standards Track [Page 12]
676RFC 6125 Service Identity March 2011
679 Most security-related terms in this document are to be understood in
680 the sense defined in [SECTERMS]; such terms include, but are not
681 limited to, "attack", "authentication", "authorization",
682 "certification authority", "certification path", "certificate",
683 "credential", "identity", "self-signed certificate", "trust", "trust
684 anchor", "trust chain", "validate", and "verify".
686 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
687 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
688 "OPTIONAL" in this document are to be interpreted as described in RFC
6912. Naming of Application Services
693 This section discusses naming of application services on the
694 Internet, followed by a brief tutorial about subject naming in PKIX.
6962.1. Naming Application Services
698 This specification assumes that the name of an application service is
699 based on a DNS domain name (e.g., "example.com") -- supplemented in
700 some circumstances by an application service type (e.g., "the IMAP
701 server at example.com").
703 From the perspective of the application client or user, some names
704 are direct because they are provided directly by a human user (e.g.,
705 via runtime input, prior configuration, or explicit acceptance of a
706 client communication attempt), whereas other names are indirect
707 because they are automatically resolved by the client based on user
708 input (e.g., a target name resolved from a source name using DNS SRV
709 or NAPTR records). This dimension matters most for certificate
710 consumption, specifically verification as discussed in this document.
712 From the perspective of the application service, some names are
713 unrestricted because they can be used in any type of service (e.g., a
714 certificate might be reused for both the HTTP service and the IMAP
715 service at example.com), whereas other names are restricted because
716 they can be used in only one type of service (e.g., a special-purpose
717 certificate that can be used only for an IMAP service). This
718 dimension matters most for certificate issuance.
720 Therefore, we can categorize the identifier types of interest as
723 o A CN-ID is direct and unrestricted.
725 o A DNS-ID is direct and unrestricted.
730Saint-Andre & Hodges Standards Track [Page 13]
732RFC 6125 Service Identity March 2011
735 o An SRV-ID can be either direct or (more typically) indirect, and
738 o A URI-ID is direct and restricted.
740 We summarize this taxonomy in the following table.
742 +-----------+-----------+---------------+
743 | | Direct | Restricted |
744 +-----------+-----------+---------------+
746 +-----------+-----------+---------------+
747 | DNS-ID | Yes | No |
748 +-----------+-----------+---------------+
749 | SRV-ID | Either | Yes |
750 +-----------+-----------+---------------+
751 | URI-ID | Yes | Yes |
752 +-----------+-----------+---------------+
754 When implementing software, deploying services, and issuing
755 certificates for secure PKIX-based authentication, it is important to
756 keep these distinctions in mind. In particular, best practices
757 differ somewhat for application server implementations, application
758 client implementations, application service providers, and
759 certification authorities. Ideally, protocol specifications that
760 reference this document will specify which identifiers are mandatory-
761 to-implement by servers and clients, which identifiers ought to be
762 supported by certificate issuers, and which identifiers ought to be
763 requested by application service providers. Because these
764 requirements differ across applications, it is impossible to
765 categorically stipulate universal rules (e.g., that all software
766 implementations, service providers, and certification authorities for
767 all application protocols need to use or support DNS-IDs as a
768 baseline for the purpose of interoperability).
770 However, it is preferable that each application protocol will at
771 least define a baseline that applies to the community of software
772 developers, application service providers, and CAs actively using or
773 supporting that technology (one such community, the CA/Browser Forum,
774 has codified such a baseline for "Extended Validation Certificates"
779 For the purposes of this specification, the name of an application
780 service is (or is based on) a DNS domain name that conforms to one of
786Saint-Andre & Hodges Standards Track [Page 14]
788RFC 6125 Service Identity March 2011
791 1. A "traditional domain name", i.e., a fully qualified DNS domain
792 name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH
793 labels" as described in [IDNA-DEFS]. Informally, such labels are
794 constrained to [US-ASCII] letters, digits, and the hyphen, with
795 the hyphen prohibited in the first character position.
796 Additional qualifications apply (please refer to the above-
797 referenced specifications for details), but they are not relevant
798 to this specification.
800 2. An "internationalized domain name", i.e., a DNS domain name that
801 conforms to the overall form of a domain name (informally, dot-
802 separated letter-digit-hyphen labels) but includes at least one
803 label containing appropriately encoded Unicode code points
804 outside the traditional US-ASCII range. That is, it contains at
805 least one U-label or A-label, but otherwise may contain any
806 mixture of NR-LDH labels, A-labels, or U-labels, as described in
807 [IDNA-DEFS] and the associated documents.
8092.3. Subject Naming in PKIX Certificates
811 In theory, the Internet Public Key Infrastructure using X.509 [PKIX]
812 employs the global directory service model defined in [X.500] and
813 [X.501]. Under that model, information is held in a directory
814 information base (DIB) and entries in the DIB are organized in a
815 hierarchy called the directory information tree (DIT). An object or
816 alias entry in that hierarchy consists of a set of attributes (each
817 of which has a defined type and one or more values) and is uniquely
818 identified by a Distinguished Name (DN). The DN of an entry is
819 constructed by combining the Relative Distinguished Names of its
820 superior entries in the tree (all the way down to the root of the
821 DIT) with one or more specially nominated attributes of the entry
822 itself (which together comprise the Relative Distinguished Name (RDN)
823 of the entry, so-called because it is relative to the Distinguished
824 Names of the superior entries in the tree). The entry closest to the
825 root is sometimes referred to as the "most significant" entry, and
826 the entry farthest from the root is sometimes referred to as the
827 "least significant" entry. An RDN is a set (i.e., an unordered
828 group) of attribute-type-and-value pairs (see also [LDAP-DN]), each
829 of which asserts some attribute about the entry.
831 In practice, the certificates used in [X.509] and [PKIX] borrow key
832 concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify
833 entities, but such certificates are not necessarily part of a global
834 directory information base. Specifically, the subject field of a
835 PKIX certificate is an X.501 type Name that "identifies the entity
836 associated with the public key stored in the subject public key
837 field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly
838 acceptable for the subject field to be empty, as long as the
842Saint-Andre & Hodges Standards Track [Page 15]
844RFC 6125 Service Identity March 2011
847 certificate contains a subject alternative name ("subjectAltName")
848 extension that includes at least one subjectAltName entry, because
849 the subjectAltName extension allows various identities to be bound to
850 the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName
851 extension itself is a sequence of typed entries, where each type is a
852 distinct kind of identifier.
854 For our purposes, an application service can be identified by a name
855 or names carried in the subject field (i.e., a CN-ID) and/or in one
856 of the following identifier types within subjectAltName entries:
864 Existing certificates often use a CN-ID in the subject field to
865 represent a fully qualified DNS domain name; for example, consider
866 the following three subject names, where the attribute of type Common
867 Name contains a string whose form matches that of a fully qualified
868 DNS domain name ("im.example.org", "mail.example.net", and
869 "www.example.com", respectively):
871 CN=im.example.org,O=Example Org,C=GB
873 C=CA,O=Example Internetworking,CN=mail.example.net
875 O=Examples-R-Us,CN=www.example.com,C=US
877 However, the Common Name is not strongly typed because a Common Name
878 might contain a human-friendly string for the service, rather than a
879 string whose form matches that of a fully qualified DNS domain name
880 (a certificate with such a single Common Name will typically have at
881 least one subjectAltName entry containing the fully qualified DNS
884 CN=A Free Chat Service,O=Example Org,C=GB
886 Or, a certificate's subject might contain both a CN-ID as well as
887 another common name attribute containing a human-friendly string:
889 CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
891 In general, this specification recommends and prefers use of
892 subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the
893 subject field (CN-ID) where possible, as more completely described in
894 the following sections. However, specifications that reuse this one
898Saint-Andre & Hodges Standards Track [Page 16]
900RFC 6125 Service Identity March 2011
903 can legitimately encourage continued support for the CN-ID identifier
904 type if they have good reasons to do so, such as backward
905 compatibility with deployed infrastructure (see, for example,
9082.3.1. Implementation Notes
910 Confusion sometimes arises from different renderings or encodings of
911 the hierarchical information contained in a certificate.
913 Certificates are binary objects and are encoded using the
914 Distinguished Encoding Rules (DER) specified in [X.690]. However,
915 some implementations generate displayable (a.k.a. printable)
916 renderings of the certificate issuer, subject field, and
917 subjectAltName extension, and these renderings convert the DER-
918 encoded sequences into a "string representation" before being
919 displayed. Because a certificate subject field (of type Name
920 [X.509], the same as for a Distinguished Name (DN) [X.501]) is an
921 ordered sequence, order is typically preserved in subject string
922 representations, although the two most prevalent subject (and DN)
923 string representations differ in employing left-to-right vs. right-
924 to-left ordering. However, because a Relative Distinguished Name
925 (RDN) is an unordered group of attribute-type-and-value pairs, the
926 string representation of an RDN can differ from the canonical DER
927 encoding (and the order of attribute-type-and-value pairs can differ
928 in the RDN string representations or display orders provided by
929 various implementations). Furthermore, various specifications refer
930 to the order of RDNs in DNs or certificate subject fields using
931 terminology that is implicitly related to an information hierarchy
932 (which may or may not actually exist), such as "most specific" vs.
933 "least specific", "left-most" vs. "right-most", "first" vs. "last",
934 or "most significant" vs. "least significant" (see, for example,
937 To reduce confusion, in this specification we avoid such terms and
938 instead use the terms provided under Section 1.8; in particular, we
939 do not use the term "(most specific) Common Name field in the subject
940 field" from [HTTP-TLS] and instead state that a CN-ID is a Relative
941 Distinguished Name (RDN) in the certificate subject containing one
942 and only one attribute-type-and-value pair of type Common Name (thus
943 removing the possibility that an RDN might contain multiple AVAs
944 (Attribute Value Assertions) of type CN, one of which could be
945 considered "most specific").
947 Finally, although theoretically some consider the order of RDNs
948 within a subject field to have meaning, in practice that rule is
949 often not observed. An AVA of type CN is considered to be valid at
950 any position within the subject field.
954Saint-Andre & Hodges Standards Track [Page 17]
956RFC 6125 Service Identity March 2011
9593. Designing Application Protocols
961 This section provides guidelines for designers of application
962 protocols, in the form of a checklist to follow when reusing the
963 recommendations provided in this document.
965 o Does your technology use DNS SRV records to resolve the DNS domain
966 names of application services? If so, consider recommending or
967 requiring support for the SRV-ID identifier type in PKIX
968 certificates issued and used in your technology community. (Note
969 that many existing application technologies use DNS SRV records to
970 resolve the DNS domain names of application services, but do not
971 rely on representations of those records in PKIX certificates by
972 means of SRV-IDs as defined in [SRVNAME].)
974 o Does your technology use URIs to identify application services?
975 If so, consider recommending or requiring support for the URI-ID
976 identifier type. (Note that many existing application
977 technologies use URIs to identify application services, but do not
978 rely on representation of those URIs in PKIX certificates by means
981 o Does your technology need to use DNS domain names in the Common
982 Name of certificates for the sake of backward compatibility? If
983 so, consider recommending support for the CN-ID identifier type as
986 o Does your technology need to allow the wildcard character in DNS
987 domain names? If so, consider recommending support for wildcard
988 certificates, and specify exactly where the wildcard character is
989 allowed to occur (e.g., only the complete left-most label of a DNS
992 Sample text is provided under Appendix A.
9944. Representing Server Identity
996 This section provides rules and guidelines for issuers of
1001 When a certification authority issues a certificate based on the
1002 fully qualified DNS domain name at which the application service
1003 provider will provide the relevant application, the following rules
1004 apply to the representation of application service identities. The
1010Saint-Andre & Hodges Standards Track [Page 18]
1012RFC 6125 Service Identity March 2011
1015 reader needs to be aware that some of these rules are cumulative and
1016 can interact in important ways that are illustrated later in this
1019 1. The certificate SHOULD include a "DNS-ID" if possible as a
1020 baseline for interoperability.
1022 2. If the service using the certificate deploys a technology for
1023 which the relevant specification stipulates that certificates
1024 ought to include identifiers of type SRV-ID (e.g., this is true
1025 of [XMPP]), then the certificate SHOULD include an SRV-ID.
1027 3. If the service using the certificate deploys a technology for
1028 which the relevant specification stipulates that certificates
1029 ought to include identifiers of type URI-ID (e.g., this is true
1030 of [SIP] as specified by [SIP-CERTS], but not true of [HTTP]
1031 since [HTTP-TLS] does not describe usage of a URI-ID for HTTP
1032 services), then the certificate SHOULD include a URI-ID. The
1033 scheme SHALL be that of the protocol associated with the
1034 application service type and the "host" component (or its
1035 equivalent) SHALL be the fully qualified DNS domain name of the
1036 service. A specification that reuses this one MUST specify which
1037 URI schemes are to be considered acceptable in URI-IDs contained
1038 in PKIX certificates used for the application protocol (e.g.,
1039 "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS],
1040 or perhaps http and https for HTTP as might be described in a
1041 future specification).
1043 4. The certificate MAY include other application-specific
1044 identifiers for types that were defined before publication of
1045 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names
1046 or URI schemes do not exist; however, such application-specific
1047 identifiers are not applicable to all application technologies
1048 and therefore are out of scope for this specification.
1050 5. Even though many deployed clients still check for the CN-ID
1051 within the certificate subject field, certification authorities
1052 are encouraged to migrate away from issuing certificates that
1053 represent the server's fully qualified DNS domain name in a
1054 CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID
1055 unless the certification authority issues the certificate in
1056 accordance with a specification that reuses this one and that
1057 explicitly encourages continued support for the CN-ID identifier
1058 type in the context of a given application technology.
1060 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or
1061 URI-ID but SHOULD NOT contain more than one CN-ID, as further
1062 explained under Section 7.4.
1066Saint-Andre & Hodges Standards Track [Page 19]
1068RFC 6125 Service Identity March 2011
1071 7. Unless a specification that reuses this one allows continued
1072 support for the wildcard character '*', the DNS domain name
1073 portion of a presented identifier SHOULD NOT contain the wildcard
1074 character, whether as the complete left-most label within the
1075 identifier (following the description of labels and domain names
1076 in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment
1077 thereof (e.g., *oo.example.com, f*o.example.com, or
1078 fo*.example.com). A more detailed discussion of so-called
1079 "wildcard certificates" is provided under Section 7.2.
1083 Consider a simple website at "www.example.com", which is not
1084 discoverable via DNS SRV lookups. Because HTTP does not specify the
1085 use of URIs in server certificates, a certificate for this service
1086 might include only a DNS-ID of "www.example.com". It might also
1087 include a CN-ID of "www.example.com" for backward compatibility with
1088 deployed infrastructure.
1090 Consider an IMAP-accessible email server at the host
1091 "mail.example.net" servicing email addresses of the form
1092 "user@example.net" and discoverable via DNS SRV lookups on the
1093 application service name of "example.net". A certificate for this
1094 service might include SRV-IDs of "_imap.example.net" and
1095 "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of
1096 "example.net" and "mail.example.net". It might also include CN-IDs
1097 of "example.net" and "mail.example.net" for backward compatibility
1098 with deployed infrastructure.
1100 Consider a SIP-accessible voice-over-IP (VoIP) server at the host
1101 "voice.example.edu" servicing SIP addresses of the form
1102 "user@voice.example.edu" and identified by a URI of <sip:
1103 voice.example.edu>. A certificate for this service would include a
1104 URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along with a
1105 DNS-ID of "voice.example.edu". It might also include a CN-ID of
1106 "voice.example.edu" for backward compatibility with deployed
1109 Consider an XMPP-compatible instant messaging (IM) server at the host
1110 "im.example.org" servicing IM addresses of the form
1111 "user@im.example.org" and discoverable via DNS SRV lookups on the
1112 "im.example.org" domain. A certificate for this service might
1113 include SRV-IDs of "_xmpp-client.im.example.org" and
1114 "_xmpp-server.im.example.org" (see [XMPP]), a DNS-ID of
1115 "im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org"
1116 (see [XMPP]). It might also include a CN-ID of "im.example.org" for
1117 backward compatibility with deployed infrastructure.
1122Saint-Andre & Hodges Standards Track [Page 20]
1124RFC 6125 Service Identity March 2011
11275. Requesting Server Certificates
1129 This section provides rules and guidelines for service providers
1130 regarding the information to include in certificate signing requests
1133 In general, service providers are encouraged to request certificates
1134 that include all of the identifier types that are required or
1135 recommended for the application service type that will be secured
1136 using the certificate to be issued.
1138 If the certificate might be used for any type of application service,
1139 then the service provider is encouraged to request a certificate that
1140 includes only a DNS-ID.
1142 If the certificate will be used for only a single type of application
1143 service, then the service provider is encouraged to request a
1144 certificate that includes a DNS-ID and, if appropriate for the
1145 application service type, an SRV-ID or URI-ID that limits the
1146 deployment scope of the certificate to only the defined application
1149 If a service provider offering multiple application service types
1150 (e.g., a World Wide Web service, an email service, and an instant
1151 messaging service) wishes to limit the applicability of certificates
1152 using SRV-IDs or URI-IDs, then the service provider is encouraged to
1153 request multiple certificates, i.e., one certificate per application
1154 service type. Conversely, the service provider is discouraged from
1155 requesting a single certificate containing multiple SRV-IDs or URI-
1156 IDs identifying each different application service type. This
1157 guideline does not apply to application service type "bundles" that
1158 are used to identify manifold distinct access methods to the same
1159 underlying application (e.g., an email application with access
1160 methods denoted by the application service types of "imap", "imaps",
1161 "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]).
11636. Verifying Service Identity
1165 This section provides rules and guidelines for implementers of
1166 application client software regarding algorithms for verification of
1167 application service identity.
1171 At a high level, the client verifies the application service's
1172 identity by performing the actions listed below (which are defined in
1173 the following subsections of this document):
1178Saint-Andre & Hodges Standards Track [Page 21]
1180RFC 6125 Service Identity March 2011
1183 1. The client constructs a list of acceptable reference identifiers
1184 based on the source domain and, optionally, the type of service
1185 to which the client is connecting.
1187 2. The server provides its identifiers in the form of a PKIX
1190 3. The client checks each of its reference identifiers against the
1191 presented identifiers for the purpose of finding a match.
1193 4. When checking a reference identifier against a presented
1194 identifier, the client matches the source domain of the
1195 identifiers and, optionally, their application service type.
1197 Naturally, in addition to checking identifiers, a client might
1198 complete further checks to ensure that the server is authorized to
1199 provide the requested service. However, such checking is not a
1200 matter of verifying the application service identity presented in a
1201 certificate, and therefore methods for doing so (e.g., consulting
1202 local policy information) are out of scope for this document.
12046.2. Constructing a List of Reference Identifiers
1208 The client MUST construct a list of acceptable reference identifiers,
1209 and MUST do so independently of the identifiers presented by the
1212 The inputs used by the client to construct its list of reference
1213 identifiers might be a URI that a user has typed into an interface
1214 (e.g., an HTTPS URL for a website), configured account information
1215 (e.g., the domain name of a particular host or URI used for
1216 retrieving information or connecting to a network, which might be
1217 different from the DNS domain name portion of a username), a
1218 hyperlink in a web page that triggers a browser to retrieve a media
1219 object or script, or some other combination of information that can
1220 yield a source domain and an application service type.
1222 The client might need to extract the source domain and application
1223 service type from the input(s) it has received. The extracted data
1224 MUST include only information that can be securely parsed out of the
1225 inputs (e.g., parsing the fully qualified DNS domain name out of the
1226 "host" component (or its equivalent) of a URI or deriving the
1227 application service type from the scheme of a URI) or information
1228 that is derived in a manner not subject to subversion by network
1229 attackers (e.g., pulling the data from a delegated domain that is
1230 explicitly established via client or system configuration, resolving
1234Saint-Andre & Hodges Standards Track [Page 22]
1236RFC 6125 Service Identity March 2011
1239 the data via [DNSSEC], or obtaining the data from a third-party
1240 domain mapping service in which a human user has explicitly placed
1241 trust and with which the client communicates over a connection or
1242 association that provides both mutual authentication and integrity
1243 checking). These considerations apply only to extraction of the
1244 source domain from the inputs; naturally, if the inputs themselves
1245 are invalid or corrupt (e.g., a user has clicked a link provided by a
1246 malicious entity in a phishing attack), then the client might end up
1247 communicating with an unexpected application service.
1249 Example: Given an input URI of <sips:alice@example.net>, a client
1250 would derive the application service type "sip" from the "scheme"
1251 and parse the domain name "example.net" from the "host" component
1252 (or its equivalent).
1254 Each reference identifier in the list SHOULD be based on the source
1255 domain and SHOULD NOT be based on a derived domain (e.g., a host name
1256 or domain name discovered through DNS resolution of the source
1257 domain). This rule is important because only a match between the
1258 user inputs and a presented identifier enables the client to be sure
1259 that the certificate can legitimately be used to secure the client's
1260 communication with the server. There is only one scenario in which
1261 it is acceptable for an interactive client to override the
1262 recommendation in this rule and therefore communicate with a domain
1263 name other than the source domain: because a human user has "pinned"
1264 the application service's certificate to the alternative domain name
1265 as further discussed under Section 6.6.4 and Section 7.1. In this
1266 case, the inputs used by the client to construct its list of
1267 reference identifiers might include more than one fully qualified DNS
1268 domain name, i.e., both (a) the source domain and (b) the alternative
1269 domain contained in the pinned certificate.
1271 Using the combination of fully qualified DNS domain name(s) and
1272 application service type, the client constructs a list of reference
1273 identifiers in accordance with the following rules:
1275 o The list SHOULD include a DNS-ID. A reference identifier of type
1276 DNS-ID can be directly constructed from a fully qualified DNS
1277 domain name that is (a) contained in or securely derived from the
1278 inputs (i.e., the source domain), or (b) explicitly associated
1279 with the source domain by means of user configuration (i.e., a
1282 o If a server for the application service type is typically
1283 discovered by means of DNS SRV records, then the list SHOULD
1290Saint-Andre & Hodges Standards Track [Page 23]
1292RFC 6125 Service Identity March 2011
1295 o If a server for the application service type is typically
1296 associated with a URI for security purposes (i.e., a formal
1297 protocol document specifies the use of URIs in server
1298 certificates), then the list SHOULD include a URI-ID.
1300 o The list MAY include a CN-ID, mainly for the sake of backward
1301 compatibility with deployed infrastructure.
1303 Which identifier types a client includes in its list of reference
1304 identifiers is a matter of local policy. For example, in certain
1305 deployment environments, a client that is built to connect only to a
1306 particular kind of service (e.g., only IM services) might be
1307 configured to accept as valid only certificates that include an
1308 SRV-ID for that application service type; in this case, the client
1309 would include only SRV-IDs matching the application service type in
1310 its list of reference identifiers (not, for example, DNS-IDs). By
1311 contrast, a more lenient client (even one built to connect only to a
1312 particular kind of service) might include both SRV-IDs and DNS-IDs in
1313 its list of reference identifiers.
1315 Implementation Note: It is highly likely that implementers of
1316 client software will need to support CN-IDs for the foreseeable
1317 future, because certificates containing CN-IDs are so widely
1318 deployed. Implementers are advised to monitor the state of the
1319 art with regard to certificate issuance policies and migrate away
1320 from support CN-IDs in the future if possible.
1322 Implementation Note: The client does not need to construct the
1323 foregoing identifiers in the actual formats found in a certificate
1324 (e.g., as ASN.1 types); it only needs to construct the functional
1325 equivalent of such identifiers for matching purposes.
1327 Security Warning: A client MUST NOT construct a reference
1328 identifier corresponding to Relative Distinguished Names (RDNs)
1329 other than those of type Common Name and MUST NOT check for RDNs
1330 other than those of type Common Name in the presented identifiers.
1334 A web browser that is connecting via HTTPS to the website at
1335 "www.example.com" might have two reference identifiers: a DNS-ID of
1336 "www.example.com" and, as a fallback, a CN-ID of "www.example.com".
1338 A mail user agent that is connecting via IMAPS to the email service
1339 at "example.net" (resolved as "mail.example.net") might have five
1340 reference identifiers: an SRV-ID of "_imaps.example.net" (see
1341 [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and,
1342 as a fallback, CN-IDs of "example.net" and "mail.example.net". (A
1346Saint-Andre & Hodges Standards Track [Page 24]
1348RFC 6125 Service Identity March 2011
1351 legacy email user agent would not support [EMAIL-SRV] and therefore
1352 would probably be explicitly configured to connect to
1353 "mail.example.net", whereas an SRV-aware user agent would derive
1354 "example.net" from an email address of the form "user@example.net"
1355 but might also accept "mail.example.net" as the DNS domain name
1356 portion of reference identifiers for the service.)
1358 A voice-over-IP (VoIP) user agent that is connecting via SIP to the
1359 voice service at "voice.example.edu" might have only one reference
1360 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
1362 An instant messaging (IM) client that is connecting via XMPP to the
1363 IM service at "im.example.org" might have three reference
1364 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]),
1365 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of
1366 "im.example.org" (see [XMPP]).
13686.3. Preparing to Seek a Match
1370 Once the client has constructed its list of reference identifiers and
1371 has received the server's presented identifiers in the form of a PKIX
1372 certificate, the client checks its reference identifiers against the
1373 presented identifiers for the purpose of finding a match. The search
1374 fails if the client exhausts its list of reference identifiers
1375 without finding a match. The search succeeds if any presented
1376 identifier matches one of the reference identifiers, at which point
1377 the client SHOULD stop the search.
1379 Implementation Note: A client might be configured to perform
1380 multiple searches, i.e., to match more than one reference
1381 identifier. Although such behavior is not forbidden by this
1382 specification, rules for matching multiple reference identifiers
1383 are a matter for implementation or future specification.
1385 Security Warning: A client MUST NOT seek a match for a reference
1386 identifier of CN-ID if the presented identifiers include a DNS-ID,
1387 SRV-ID, URI-ID, or any application-specific identifier types
1388 supported by the client.
1390 Before applying the comparison rules provided in the following
1391 sections, the client might need to split the reference identifier
1392 into its DNS domain name portion and its application service type
1393 portion, as follows:
1395 o A reference identifier of type DNS-ID does not include an
1396 application service type portion and thus can be used directly as
1397 the DNS domain name for comparison purposes. As an example, a
1402Saint-Andre & Hodges Standards Track [Page 25]
1404RFC 6125 Service Identity March 2011
1407 DNS-ID of "www.example.com" would result in a DNS domain name
1408 portion of "www.example.com".
1410 o A reference identifier of type CN-ID also does not include an
1411 application service type portion and thus can be used directly as
1412 the DNS domain name for comparison purposes. As previously
1413 mentioned, this document specifies that a CN-ID always contains a
1414 string whose form matches that of a DNS domain name (thus
1415 differentiating a CN-ID from a Common Name containing a human-
1418 o For a reference identifier of type SRV-ID, the DNS domain name
1419 portion is the Name and the application service type portion is
1420 the Service. As an example, an SRV-ID of "_imaps.example.net"
1421 would be split into a DNS domain name portion of "example.net" and
1422 an application service type portion of "imaps" (mapping to an
1423 application protocol of IMAP as explained in [EMAIL-SRV]).
1425 o For a reference identifier of type URI-ID, the DNS domain name
1426 portion is the "reg-name" part of the "host" component (or its
1427 equivalent) and the application service type portion is the
1428 application service type associated with the scheme name matching
1429 the [ABNF] "scheme" rule from [URI] (not including the ':'
1430 separator). As previously mentioned, this document specifies that
1431 a URI-ID always contains a "host" component (or its equivalent)
1432 containing a "reg-name". (Matching only the "reg-name" rule from
1433 [URI] limits verification to DNS domain names, thereby
1434 differentiating a URI-ID from a uniformResourceIdentifier entry
1435 that contains an IP address or a mere host name, or that does not
1436 contain a "host" component at all.) Furthermore, note that
1437 extraction of the "reg-name" might necessitate normalization of
1438 the URI (as explained in [URI]). As an example, a URI-ID of "sip:
1439 voice.example.edu" would be split into a DNS domain name portion
1440 of "voice.example.edu" and an application service type of "sip"
1441 (associated with an application protocol of SIP as explained in
1444 Detailed comparison rules for matching the DNS domain name portion
1445 and application service type portion of the reference identifier are
1446 provided in the following sections.
14486.4. Matching the DNS Domain Name Portion
1450 The client MUST match the DNS domain name portion of a reference
1451 identifier according to the following rules (and SHOULD also check
1452 the application service type as described under Section 6.5). The
1453 rules differ depending on whether the domain to be checked is a
1454 "traditional domain name" or an "internationalized domain name" (as
1458Saint-Andre & Hodges Standards Track [Page 26]
1460RFC 6125 Service Identity March 2011
1463 defined under Section 2.2). Furthermore, to meet the needs of
1464 clients that support presented identifiers containing the wildcard
1465 character '*', we define a supplemental rule for so-called "wildcard
1466 certificates". Finally, we also specify the circumstances under
1467 which it is acceptable to check the "CN-ID" identifier type.
14696.4.1. Checking of Traditional Domain Names
1471 If the DNS domain name portion of a reference identifier is a
1472 "traditional domain name", then matching of the reference identifier
1473 against the presented identifier is performed by comparing the set of
1474 domain name labels using a case-insensitive ASCII comparison, as
1475 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
1476 to "www.example.com" for comparison purposes). Each label MUST match
1477 in order for the names to be considered to match, except as
1478 supplemented by the rule about checking of wildcard labels
14816.4.2. Checking of Internationalized Domain Names
1483 If the DNS domain name portion of a reference identifier is an
1484 internationalized domain name, then an implementation MUST convert
1485 any U-labels [IDNA-DEFS] in the domain name to A-labels before
1486 checking the domain name. In accordance with [IDNA-PROTO], A-labels
1487 MUST be compared as case-insensitive ASCII. Each label MUST match in
1488 order for the domain names to be considered to match, except as
1489 supplemented by the rule about checking of wildcard labels
1490 (Section 6.4.3; but see also Section 7.2 regarding wildcards in
1491 internationalized domain names).
14936.4.3. Checking of Wildcard Certificates
1495 A client employing this specification's rules MAY match the reference
1496 identifier against a presented identifier whose DNS domain name
1497 portion contains the wildcard character '*' as part or all of a label
1498 (following the description of labels and domain names in
1501 For information regarding the security characteristics of wildcard
1502 certificates, see Section 7.2.
1504 If a client matches the reference identifier against a presented
1505 identifier whose DNS domain name portion contains the wildcard
1506 character '*', the following rules apply:
1508 1. The client SHOULD NOT attempt to match a presented identifier in
1509 which the wildcard character comprises a label other than the
1510 left-most label (e.g., do not match bar.*.example.net).
1514Saint-Andre & Hodges Standards Track [Page 27]
1516RFC 6125 Service Identity March 2011
1519 2. If the wildcard character is the only character of the left-most
1520 label in the presented identifier, the client SHOULD NOT compare
1521 against anything but the left-most label of the reference
1522 identifier (e.g., *.example.com would match foo.example.com but
1523 not bar.foo.example.com or example.com).
1525 3. The client MAY match a presented identifier in which the wildcard
1526 character is not the only character of the label (e.g.,
1527 baz*.example.net and *baz.example.net and b*z.example.net would
1528 be taken to match baz1.example.net and foobaz.example.net and
1529 buzz.example.net, respectively). However, the client SHOULD NOT
1530 attempt to match a presented identifier where the wildcard
1531 character is embedded within an A-label or U-label [IDNA-DEFS] of
1532 an internationalized domain name [IDNA-PROTO].
15346.4.4. Checking of Common Names
1536 As noted, a client MUST NOT seek a match for a reference identifier
1537 of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
1538 URI-ID, or any application-specific identifier types supported by the
1541 Therefore, if and only if the presented identifiers do not include a
1542 DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
1543 supported by the client, then the client MAY as a last resort check
1544 for a string whose form matches that of a fully qualified DNS domain
1545 name in a Common Name field of the subject field (i.e., a CN-ID). If
1546 the client chooses to compare a reference identifier of type CN-ID
1547 against that string, it MUST follow the comparison rules for the DNS
1548 domain name portion of an identifier of type DNS-ID, SRV-ID, or
1549 URI-ID, as described under Section 6.4.1, Section 6.4.2, and
15526.5. Matching the Application Service Type Portion
1554 When a client checks identifiers of type SRV-ID and URI-ID, it MUST
1555 check not only the DNS domain name portion of the identifier but also
1556 the application service type portion. The client does this by
1557 splitting the identifier into the DNS domain name portion and the
1558 application service type portion (as described under Section 6.3),
1559 then checking both the DNS domain name portion (as described under
1560 Section 6.4) and the application service type portion as described in
1561 the following subsections.
1563 Implementation Note: An identifier of type SRV-ID or URI-ID
1564 provides an application service type portion to be checked, but
1565 that portion is combined only with the DNS domain name portion of
1566 the SRV-ID or URI-ID itself. For example, if a client's list of
1570Saint-Andre & Hodges Standards Track [Page 28]
1572RFC 6125 Service Identity March 2011
1575 reference identifiers includes an SRV-ID of "_xmpp-
1576 client.im.example.org" and a DNS-ID of "apps.example.net", the
1577 client would check (a) the combination of an application service
1578 type of "xmpp-client" and a DNS domain name of "im.example.org"
1579 and (b) a DNS domain name of "apps.example.net". However, the
1580 client would not check (c) the combination of an application
1581 service type of "xmpp-client" and a DNS domain name of
1582 "apps.example.net" because it does not have an SRV-ID of "_xmpp-
1583 client.apps.example.net" in its list of reference identifiers.
1587 The application service name portion of an SRV-ID (e.g., "imaps")
1588 MUST be matched in a case-insensitive manner, in accordance with
1589 [DNS-SRV]. Note that the "_" character is prepended to the service
1590 identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and
1591 thus does not need to be included in any comparison.
1595 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in
1596 a case-insensitive manner, in accordance with [URI]. Note that the
1597 ":" character is a separator between the scheme name and the rest of
1598 the URI, and thus does not need to be included in any comparison.
1602 The outcome of the matching procedure is one of the following cases.
16046.6.1. Case #1: Match Found
1606 If the client has found a presented identifier that matches a
1607 reference identifier, then the service identity check has succeeded.
1608 In this case, the client MUST use the matched reference identifier as
1609 the validated identity of the application service.
16116.6.2. Case #2: No Match Found, Pinned Certificate
1613 If the client does not find a presented identifier matching any of
1614 the reference identifiers but the client has previously pinned the
1615 application service's certificate to one of the reference identifiers
1616 in the list it constructed for this communication attempt (as
1617 "pinning" is explained under Section 1.8), and the presented
1618 certificate matches the pinned certificate (including the context as
1619 described under Section 7.1), then the service identity check has
1626Saint-Andre & Hodges Standards Track [Page 29]
1628RFC 6125 Service Identity March 2011
16316.6.3. Case #3: No Match Found, No Pinned Certificate
1633 If the client does not find a presented identifier matching any of
1634 the reference identifiers and the client has not previously pinned
1635 the certificate to one of the reference identifiers in the list it
1636 constructed for this communication attempt, then the client MUST
1637 proceed as described under Section 6.6.4.
1641 If the client is an interactive client that is directly controlled by
1642 a human user, then it SHOULD inform the user of the identity mismatch
1643 and automatically terminate the communication attempt with a bad
1644 certificate error; this behavior is preferable because it prevents
1645 users from inadvertently bypassing security protections in hostile
1648 Security Warning: Some interactive clients give advanced users the
1649 option of proceeding with acceptance despite the identity
1650 mismatch, thereby "pinning" the certificate to one of the
1651 reference identifiers in the list constructed by the client for
1652 this communication attempt. Although this behavior can be
1653 appropriate in certain specialized circumstances, in general it
1654 ought to be exposed only to advanced users. Even then it needs to
1655 be handled with extreme caution, for example by first encouraging
1656 even an advanced user to terminate the communication attempt and,
1657 if the advanced user chooses to proceed anyway, by forcing the
1658 user to view the entire certification path and only then allowing
1659 the user to pin the certificate (on a temporary or permanent
1660 basis, at the user's option).
1662 Otherwise, if the client is an automated application not directly
1663 controlled by a human user, then it SHOULD terminate the
1664 communication attempt with a bad certificate error and log the error
1665 appropriately. An automated application MAY provide a configuration
1666 setting that disables this behavior, but MUST enable the behavior by
16697. Security Considerations
16717.1. Pinned Certificates
1673 As defined under Section 1.8, a certificate is said to be "pinned" to
1674 a DNS domain name when a user has explicitly chosen to associate a
1675 service's certificate with that DNS domain name despite the fact that
1676 the certificate contains some other DNS domain name (e.g., the user
1677 has explicitly approved "apps.example.net" as a domain associated
1678 with a source domain of "example.com"). The cached name association
1682Saint-Andre & Hodges Standards Track [Page 30]
1684RFC 6125 Service Identity March 2011
1687 MUST take account of both the certificate presented and the context
1688 in which it was accepted or configured (where the "context" includes
1689 the chain of certificates from the presented certificate to the trust
1690 anchor, the source domain, the application service type, the
1691 service's derived domain and port number, and any other relevant
1692 information provided by the user or associated by the client).
16947.2. Wildcard Certificates
1696 This document states that the wildcard character '*' SHOULD NOT be
1697 included in presented identifiers but MAY be checked by application
1698 clients (mainly for the sake of backward compatibility with deployed
1699 infrastructure). As a result, the rules provided in this document
1700 are more restrictive than the rules for many existing application
1701 technologies (such as those excerpted under Appendix B). Several
1702 security considerations justify tightening the rules:
1704 o Wildcard certificates automatically vouch for any and all host
1705 names within their domain. This can be convenient for
1706 administrators but also poses the risk of vouching for rogue or
1707 buggy hosts. See for example [Defeating-SSL] (beginning at slide
1708 91) and [HTTPSbytes] (slides 38-40).
1710 o Specifications for existing application technologies are not clear
1711 or consistent about the allowable location of the wildcard
1712 character, such as whether it can be:
1714 * only the complete left-most label (e.g., *.example.com)
1716 * some fragment of the left-most label (e.g., fo*.example.com,
1717 f*o.example.com, or *oo.example.com)
1719 * all or part of a label other than the left-most label (e.g.,
1720 www.*.example.com or www.foo*.example.com)
1722 * all or part of a label that identifies a so-called "public
1723 suffix" (e.g., *.co.uk or *.com)
1725 * included more than once in a given label (e.g.,
1728 * included as all or part of more than one label (e.g.,
1731 These ambiguities might introduce exploitable differences in
1732 identity checking behavior among client implementations and
1733 necessitate overly complex and inefficient identity checking
1738Saint-Andre & Hodges Standards Track [Page 31]
1740RFC 6125 Service Identity March 2011
1743 o There is no specification that defines how the wildcard character
1744 may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
1745 internationalized domain name [IDNA-PROTO]; as a result,
1746 implementations are strongly discouraged from including or
1747 attempting to check for the wildcard character embedded within the
1748 A-labels or U-labels of an internationalized domain name (e.g.,
1749 "xn--kcry6tjko*.example.org"). Note, however, that a presented
1750 domain name identifier MAY contain the wildcard character as long
1751 as that character occupies the entire left-most label position,
1752 where all of the remaining labels are valid NR-LDH labels,
1753 A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org").
1755 Notwithstanding the foregoing security considerations, specifications
1756 that reuse this one can legitimately encourage continued support for
1757 the wildcard character if they have good reasons to do so, such as
1758 backward compatibility with deployed infrastructure (see, for
1759 example, [EV-CERTS]).
17617.3. Internationalized Domain Names
1763 Allowing internationalized domain names can lead to the inclusion of
1764 visually similar (so-called "confusable") characters in certificates;
1765 for discussion, see for example [IDNA-DEFS].
17677.4. Multiple Identifiers
1769 A given application service might be addressed by multiple DNS domain
1770 names for a variety of reasons, and a given deployment might service
1771 multiple domains (e.g., in so-called "virtual hosting" environments).
1772 In the default TLS handshake exchange, the client is not able to
1773 indicate the DNS domain name with which it wants to communicate, and
1774 the TLS server returns only one certificate for itself. Absent an
1775 extension to TLS, a typical workaround used to facilitate mapping an
1776 application service to multiple DNS domain names is to embed all of
1777 the domain names into a single certificate.
1779 A more recent approach, formally specified in [TLS-EXT], is for the
1780 client to use the TLS "Server Name Indication" (SNI) extension when
1781 sending the client_hello message, stipulating the DNS domain name it
1782 desires or expects of the service. The service can then return the
1783 appropriate certificate in its Certificate message, and that
1784 certificate can represent a single DNS domain name.
1786 To accommodate the workaround that was needed before the development
1787 of the SNI extension, this specification allows multiple DNS-IDs,
1788 SRV-IDs, or URI-IDs in a certificate; however, it explicitly
1789 discourages multiple CN-IDs. Although it would be preferable to
1790 forbid multiple CN-IDs entirely, there are several reasons at this
1794Saint-Andre & Hodges Standards Track [Page 32]
1796RFC 6125 Service Identity March 2011
1799 time why this specification states that they SHOULD NOT (instead of
1800 MUST NOT) be included:
1802 o At least one significant technology community of interest
1803 explicitly allows multiple CN-IDs [EV-CERTS].
1805 o At least one significant certification authority is known to issue
1806 certificates containing multiple CN-IDs.
1808 o Many service providers often deem inclusion of multiple CN-IDs
1809 necessary in virtual hosting environments because at least one
1810 widely deployed operating system does not yet support the SNI
1813 It is hoped that the recommendation regarding multiple CN-IDs can be
1814 further tightened in the future.
1818 The following individuals made important contributions to the text of
1819 this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
1823 The editors and contributors wish to thank the following individuals
1824 for their feedback and suggestions: Bernard Aboba, Richard Barnes,
1825 Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott
1826 Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus
1827 Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno
1828 Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love
1829 Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman,
1830 Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott
1831 Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy,
1832 Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen,
1833 Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe
1834 Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael
1835 Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul
1836 Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and
1839 Thanks also to Barry Leiba and Ben Campbell for their reviews on
1840 behalf of the Security Directorate and the General Area Review Team,
1843 The responsible Area Director was Alexey Melnikov.
1850Saint-Andre & Hodges Standards Track [Page 33]
1852RFC 6125 Service Identity March 2011
185710.1. Normative References
1859 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
1860 facilities", STD 13, RFC 1034, November 1987.
1862 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
1863 for specifying the location of services (DNS SRV)",
1864 RFC 2782, February 2000.
1866 [IDNA-DEFS] Klensin, J., "Internationalized Domain Names for
1867 Applications (IDNA): Definitions and Document
1868 Framework", RFC 5890, August 2010.
1870 [IDNA-PROTO] Klensin, J., "Internationalized Domain Names in
1871 Applications (IDNA): Protocol", RFC 5891,
1874 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1875 Requirement Levels", BCP 14, RFC 2119, March 1997.
1877 [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access
1878 Protocol (LDAP): String Representation of
1879 Distinguished Names", RFC 4514, June 2006.
1881 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1882 Housley, R., and W. Polk, "Internet X.509 Public Key
1883 Infrastructure Certificate and Certificate
1884 Revocation List (CRL) Profile", RFC 5280, May 2008.
1886 [SRVNAME] Santesson, S., "Internet X.509 Public Key
1887 Infrastructure Subject Alternative Name for
1888 Expression of Service Name", RFC 4985, August 2007.
1890 [URI] Berners-Lee, T., Fielding, R., and L. Masinter,
1891 "Uniform Resource Identifier (URI): Generic Syntax",
1892 STD 66, RFC 3986, January 2005.
189410.2. Informative References
1896 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
1897 Syntax Specifications: ABNF", STD 68, RFC 5234,
1900 [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case
1901 Insensitivity Clarification", RFC 4343,
1906Saint-Andre & Hodges Standards Track [Page 34]
1908RFC 6125 Service Identity March 2011
1911 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and
1912 S. Rose, "DNS Security Introduction and
1913 Requirements", RFC 4033, March 2005.
1915 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport
1916 Layer Security", RFC 4347, April 2006.
1918 [Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in
1919 Practice", BlackHat DC, February 2009,
1920 <http://www.blackhat.com/presentations/
1921 bh-dc-09/Marlinspike/ BlackHat-DC-09-Marlinspike-
1924 [EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email
1925 Submission/Access Services", RFC 6186, March 2011.
1927 [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And
1928 Management Of Extended Validation Certificates",
1930 <http://www.cabforum.org/Guidelines_v1_2.pdf>.
1932 [GIST] Schulzrinne, H. and R. Hancock, "GIST: General
1933 Internet Signalling Transport", RFC 5971,
1936 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1937 Masinter, L., Leach, P., and T. Berners-Lee,
1938 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
1941 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1943 [HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me",
1944 BlackHat Abu Dhabi, November 2010,
1945 <https://media.blackhat.com/bh-ad-10/Hansen/
1946 Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-
1949 [IDNA2003] Faltstrom, P., Hoffman, P., and A. Costello,
1950 "Internationalizing Domain Names in Applications
1951 (IDNA)", RFC 3490, March 2003.
1953 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
1954 VERSION 4rev1", RFC 3501, March 2003.
1956 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
1962Saint-Andre & Hodges Standards Track [Page 35]
1964RFC 6125 Service Identity March 2011
1967 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
1968 Internet Protocol", RFC 4301, December 2005.
1970 [IPv6] Deering, S. and R. Hinden, "Internet Protocol,
1971 Version 6 (IPv6) Specification", RFC 2460,
1974 [LDAP] Sermersheim, J., "Lightweight Directory Access
1975 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
1977 [LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol
1978 (LDAP): Authentication Methods and Security
1979 Mechanisms", RFC 4513, June 2006.
1981 [LDAP-SCHEMA] Sciberras, A., Ed., "Lightweight Directory Access
1982 Protocol (LDAP): Schema for User Applications",
1983 RFC 4519, June 2006.
1985 [LDAP-TLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
1986 Directory Access Protocol (v3): Extension for
1987 Transport Layer Security", RFC 2830, May 2000.
1989 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System
1990 (DDDS) Part Three: The Domain Name System (DNS)
1991 Database", RFC 3403, October 2002.
1993 [NETCONF] Enns, R., Ed., "NETCONF Configuration Protocol",
1994 RFC 4741, December 2006.
1996 [NETCONF-SSH] Wasserman, M. and T. Goddard, "Using the NETCONF
1997 Configuration Protocol over Secure SHell (SSH)",
1998 RFC 4742, December 2006.
2000 [NETCONF-TLS] Badra, M., "NETCONF over Transport Layer Security
2001 (TLS)", RFC 5539, May 2009.
2003 [NNTP] Feather, C., "Network News Transfer Protocol
2004 (NNTP)", RFC 3977, October 2006.
2006 [NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using
2007 Transport Layer Security (TLS) with Network News
2008 Transfer Protocol (NNTP)", RFC 4642, October 2006.
2010 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S.,
2011 and C. Adams, "X.509 Internet Public Key
2012 Infrastructure Online Certificate Status Protocol -
2013 OCSP", RFC 2560, June 1999.
2018Saint-Andre & Hodges Standards Track [Page 36]
2020RFC 6125 Service Identity March 2011
2023 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D.,
2024 and R. Thayer, "OpenPGP Message Format", RFC 4880,
2027 [PKIX-OLD] Housley, R., Ford, W., Polk, T., and D. Solo,
2028 "Internet X.509 Public Key Infrastructure
2029 Certificate and CRL Profile", RFC 2459,
2032 [POP3] Myers, J. and M. Rose, "Post Office Protocol -
2033 Version 3", STD 53, RFC 1939, May 1996.
2035 [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
2036 G., and E. Lear, "Address Allocation for Private
2037 Internets", BCP 5, RFC 1918, February 1996.
2039 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application
2040 Service Location Using SRV RRs and the Dynamic
2041 Delegation Discovery Service (DDDS)", RFC 3958,
2044 [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2",
2045 RFC 4949, August 2007.
2047 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
2048 Johnston, A., Peterson, J., Sparks, R., Handley, M.,
2049 and E. Schooler, "SIP: Session Initiation Protocol",
2050 RFC 3261, June 2002.
2052 [SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
2053 Certificates in the Session Initiation Protocol
2054 (SIP)", RFC 5922, June 2010.
2056 [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the
2057 Session Initiation Protocol (SIP)", RFC 5630,
2060 [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
2061 RFC 5321, October 2008.
2063 [SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP
2064 Service Extension for Authentication", RFC 4954,
2067 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
2068 over Transport Layer Security", RFC 3207,
2074Saint-Andre & Hodges Standards Track [Page 37]
2076RFC 6125 Service Identity March 2011
2079 [SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An
2080 Architecture for Describing Simple Network
2081 Management Protocol (SNMP) Management Frameworks",
2082 STD 62, RFC 3411, December 2002.
2084 [SNMP-TLS] Hardaker, W., "Transport Layer Security (TLS)
2085 Transport Model for the Simple Network Management
2086 Protocol (SNMP)", RFC 5953, August 2010.
2088 [SYSLOG] Gerhards, R., "The Syslog Protocol", RFC 5424,
2091 [SYSLOG-DTLS] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
2092 "Datagram Transport Layer Security (DTLS) Transport
2093 Mapping for Syslog", RFC 6012, October 2010.
2095 [SYSLOG-TLS] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.,
2096 "Transport Layer Security (TLS) Transport Mapping
2097 for Syslog", RFC 5425, March 2009.
2099 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
2100 Security (TLS) Protocol Version 1.2", RFC 5246,
2103 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
2104 Extensions: Extension Definitions", RFC 6066,
2107 [US-ASCII] American National Standards Institute, "Coded
2108 Character Set - 7-bit American Standard Code for
2109 Information Interchange", ANSI X3.4, 1986.
2111 [USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
2112 RFC 2595, June 1999.
2114 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context:
2115 User Interface Guidelines", World Wide Web
2116 Consortium LastCall WD-wsc-ui-20100309, March 2010,
2117 <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
2119 [X.500] International Telecommunications Union, "Information
2120 Technology - Open Systems Interconnection - The
2121 Directory: Overview of concepts, models and
2122 services", ITU-T Recommendation X.500, ISO Standard
2123 9594-1, August 2005.
2130Saint-Andre & Hodges Standards Track [Page 38]
2132RFC 6125 Service Identity March 2011
2135 [X.501] International Telecommunications Union, "Information
2136 Technology - Open Systems Interconnection - The
2137 Directory: Models", ITU-T Recommendation X.501,
2138 ISO Standard 9594-2, August 2005.
2140 [X.509] International Telecommunications Union, "Information
2141 Technology - Open Systems Interconnection - The
2142 Directory: Public-key and attribute certificate
2143 frameworks", ITU-T Recommendation X.509,
2144 ISO Standard 9594-8, August 2005.
2146 [X.520] International Telecommunications Union, "Information
2147 Technology - Open Systems Interconnection - The
2148 Directory: Selected attribute types", ITU-
2149 T Recommendation X.509, ISO Standard 9594-6,
2152 [X.690] International Telecommunications Union, "Information
2153 Technology - ASN.1 encoding rules: Specification of
2154 Basic Encoding Rules (BER), Canonical Encoding Rules
2155 (CER) and Distinguished Encoding Rules (DER)", ITU-
2156 T Recommendation X.690, ISO Standard 8825-1,
2159 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
2160 Protocol (XMPP): Core", RFC 6120, March 2011.
2162 [XMPP-OLD] Saint-Andre, P., Ed., "Extensible Messaging and
2163 Presence Protocol (XMPP): Core", RFC 3920,
2186Saint-Andre & Hodges Standards Track [Page 39]
2188RFC 6125 Service Identity March 2011
2191Appendix A. Sample Text
2193 At the time of this writing, two application technologies reuse the
2194 recommendations in this specification: email [EMAIL-SRV] and XMPP
2195 [XMPP]. Here we include the text from [XMPP] to illustrate the
2196 thought process that might be followed by protocol designers for
2197 other application technologies. Specifically, because XMPP uses DNS
2198 SRV records for resolution of the DNS domain names for application
2199 services, the XMPP specification recommends the use of SRV-IDs.
2201 The text regarding certificate issuance is as follows:
2205 In a PKIX certificate to be presented by an XMPP server (i.e., a
2206 "server certificate"), the certificate MUST include one or more XMPP
2207 addresses (i.e., domainparts) associated with XMPP services hosted at
2208 the server. The rules and guidelines defined in [this specification]
2209 apply to XMPP server certificates, with the following XMPP-specific
2212 o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
2213 client and server software implementations. Certification
2214 authorities that issue XMPP-specific certificates MUST support the
2215 DNS-ID identifier type. XMPP service providers SHOULD include the
2216 DNS-ID identifier type in certificate requests.
2218 o Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for
2219 XMPP client and server software implementations (for verification
2220 purposes XMPP client implementations need to support only the
2221 "_xmpp-client" application service type, whereas XMPP server
2222 implementations need to support both the "_xmpp-client" and
2223 "_xmpp-server" application service types). Certification
2224 authorities that issue XMPP-specific certificates SHOULD support
2225 the SRV-ID identifier type. XMPP service providers SHOULD include
2226 the SRV-ID identifier type in certificate requests.
2228 o Support for the XmppAddr identifier type is encouraged in XMPP
2229 client and server software implementations for the sake of
2230 backward-compatibility, but is no longer encouraged in
2231 certificates issued by certification authorities or requested by
2232 XMPP service providers.
2234 o DNS domain names in server certificates MAY contain the wildcard
2235 character '*' as the complete left-most label within the
2242Saint-Andre & Hodges Standards Track [Page 40]
2244RFC 6125 Service Identity March 2011
2247 The text regarding certificate verification is as follows:
2251 For server certificates, the rules and guidelines defined in [this
2252 specification] apply, with the proviso that the XmppAddr identifier
2253 is allowed as a reference identifier.
2255 The identities to be checked are set as follows:
2257 o The initiating entity sets its reference identifier to the 'to'
2258 address it communicates in the initial stream header; i.e., this
2259 is the identity it expects the receiving entity to provide in a
2262 o The receiving entity sets its reference identifier to the 'from'
2263 address communicated by the initiating entity in the initial
2264 stream header; i.e., this is the identity that the initiating
2265 entity is trying to assert.
2298Saint-Andre & Hodges Standards Track [Page 41]
2300RFC 6125 Service Identity March 2011
2303Appendix B. Prior Art
2305 (This section is non-normative.)
2307 The recommendations in this document are an abstraction from
2308 recommendations in specifications for a wide range of application
2309 protocols. For the purpose of comparison and to delineate the
2310 history of thinking about application service identity verification
2311 within the IETF, this informative section gathers together prior art
2312 by including the exact text from various RFCs (the only modifications
2313 are changes to the names of several references to maintain coherence
2314 with the main body of this document, and the elision of irrelevant
2315 text as marked by the characters "[...]").
2317B.1. IMAP, POP3, and ACAP (1999)
2319 In 1999, [USINGTLS] specified the following text regarding
2320 application service identity verification in IMAP, POP3, and ACAP:
2324 2.4. Server Identity Check
2326 During the TLS negotiation, the client MUST check its understanding
2327 of the server hostname against the server's identity as presented in
2328 the server Certificate message, in order to prevent man-in-the-middle
2329 attacks. Matching is performed according to these rules:
2331 o The client MUST use the server hostname it used to open the
2332 connection as the value to compare against the server name as
2333 expressed in the server certificate. The client MUST NOT use any
2334 form of the server hostname derived from an insecure remote source
2335 (e.g., insecure DNS lookup). CNAME canonicalization is not done.
2337 o If a subjectAltName extension of type dNSName is present in the
2338 certificate, it SHOULD be used as the source of the server's
2341 o Matching is case-insensitive.
2343 o A "*" wildcard character MAY be used as the left-most name
2344 component in the certificate. For example, *.example.com would
2345 match a.example.com, foo.example.com, etc. but would not match
2348 o If the certificate contains multiple names (e.g. more than one
2349 dNSName field), then a match with any one of the fields is
2350 considered acceptable.
2354Saint-Andre & Hodges Standards Track [Page 42]
2356RFC 6125 Service Identity March 2011
2359 If the match fails, the client SHOULD either ask for explicit user
2360 confirmation, or terminate the connection and indicate the server's
2361 identity is suspect.
2367 In 2000, [HTTP-TLS] specified the following text regarding
2368 application service identity verification in HTTP:
2372 3.1. Server Identity
2374 In general, HTTP/TLS requests are generated by dereferencing a URI.
2375 As a consequence, the hostname for the server is known to the client.
2376 If the hostname is available, the client MUST check it against the
2377 server's identity as presented in the server's Certificate message,
2378 in order to prevent man-in-the-middle attacks.
2380 If the client has external information as to the expected identity of
2381 the server, the hostname check MAY be omitted. (For instance, a
2382 client may be connecting to a machine whose address and hostname are
2383 dynamic but the client knows the certificate that the server will
2384 present.) In such cases, it is important to narrow the scope of
2385 acceptable certificates as much as possible in order to prevent man
2386 in the middle attacks. In special cases, it may be appropriate for
2387 the client to simply ignore the server's identity, but it must be
2388 understood that this leaves the connection open to active attack.
2390 If a subjectAltName extension of type dNSName is present, that MUST
2391 be used as the identity. Otherwise, the (most specific) Common Name
2392 field in the Subject field of the certificate MUST be used. Although
2393 the use of the Common Name is existing practice, it is deprecated and
2394 Certification Authorities are encouraged to use the dNSName instead.
2396 Matching is performed using the matching rules specified by
2397 [PKIX-OLD]. If more than one identity of a given type is present in
2398 the certificate (e.g., more than one dNSName name, a match in any one
2399 of the set is considered acceptable.) Names may contain the wildcard
2400 character * which is considered to match any single domain name
2401 component or component fragment. E.g., *.a.com matches foo.a.com but
2402 not bar.foo.a.com. f*.com matches foo.com but not bar.com.
2404 In some cases, the URI is specified as an IP address rather than a
2405 hostname. In this case, the iPAddress subjectAltName must be present
2406 in the certificate and must exactly match the IP in the URI.
2410Saint-Andre & Hodges Standards Track [Page 43]
2412RFC 6125 Service Identity March 2011
2415 If the hostname does not match the identity in the certificate, user
2416 oriented clients MUST either notify the user (clients MAY give the
2417 user the opportunity to continue with the connection in any case) or
2418 terminate the connection with a bad certificate error. Automated
2419 clients MUST log the error to an appropriate audit log (if available)
2420 and SHOULD terminate the connection (with a bad certificate error).
2421 Automated clients MAY provide a configuration setting that disables
2422 this check, but MUST provide a setting which enables it.
2424 Note that in many cases the URI itself comes from an untrusted
2425 source. The above-described check provides no protection against
2426 attacks where this source is compromised. For example, if the URI
2427 was obtained by clicking on an HTML page which was itself obtained
2428 without using HTTP/TLS, a man in the middle could have replaced the
2429 URI. In order to prevent this form of attack, users should carefully
2430 examine the certificate presented by the server to determine if it
2431 meets their expectations.
2435B.3. LDAP (2000/2006)
2437 In 2000, [LDAP-TLS] specified the following text regarding
2438 application service identity verification in LDAP:
2442 3.6. Server Identity Check
2444 The client MUST check its understanding of the server's hostname
2445 against the server's identity as presented in the server's
2446 Certificate message, in order to prevent man-in-the-middle attacks.
2448 Matching is performed according to these rules:
2450 o The client MUST use the server hostname it used to open the LDAP
2451 connection as the value to compare against the server name as
2452 expressed in the server's certificate. The client MUST NOT use
2453 the server's canonical DNS name or any other derived form of name.
2455 o If a subjectAltName extension of type dNSName is present in the
2456 certificate, it SHOULD be used as the source of the server's
2459 o Matching is case-insensitive.
2461 o The "*" wildcard character is allowed. If present, it applies
2462 only to the left-most name component.
2466Saint-Andre & Hodges Standards Track [Page 44]
2468RFC 6125 Service Identity March 2011
2471 E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
2472 bar.com. If more than one identity of a given type is present in the
2473 certificate (e.g. more than one dNSName name), a match in any one of
2474 the set is considered acceptable.
2476 If the hostname does not match the dNSName-based identity in the
2477 certificate per the above check, user-oriented clients SHOULD either
2478 notify the user (clients MAY give the user the opportunity to
2479 continue with the connection in any case) or terminate the connection
2480 and indicate that the server's identity is suspect. Automated
2481 clients SHOULD close the connection, returning and/or logging an
2482 error indicating that the server's identity is suspect.
2484 Beyond the server identity checks described in this section, clients
2485 SHOULD be prepared to do further checking to ensure that the server
2486 is authorized to provide the service it is observed to provide. The
2487 client MAY need to make use of local policy information.
2491 In 2006, [LDAP-AUTH] specified the following text regarding
2492 application service identity verification in LDAP:
2496 3.1.3. Server Identity Check
2498 In order to prevent man-in-the-middle attacks, the client MUST verify
2499 the server's identity (as presented in the server's Certificate
2500 message). In this section, the client's understanding of the
2501 server's identity (typically the identity used to establish the
2502 transport connection) is called the "reference identity".
2504 The client determines the type (e.g., DNS name or IP address) of the
2505 reference identity and performs a comparison between the reference
2506 identity and each subjectAltName value of the corresponding type
2507 until a match is produced. Once a match is produced, the server's
2508 identity has been verified, and the server identity check is
2509 complete. Different subjectAltName types are matched in different
2510 ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
2511 various subjectAltName types.
2513 The client may map the reference identity to a different type prior
2514 to performing a comparison. Mappings may be performed for all
2515 available subjectAltName types to which the reference identity can be
2516 mapped; however, the reference identity should only be mapped to
2517 types for which the mapping is either inherently secure (e.g.,
2518 extracting the DNS name from a URI to compare with a subjectAltName
2522Saint-Andre & Hodges Standards Track [Page 45]
2524RFC 6125 Service Identity March 2011
2527 of type dNSName) or for which the mapping is performed in a secure
2528 manner (e.g., using [DNSSEC], or using user- or admin-configured
2529 host-to-address/address-to-host lookup tables).
2531 The server's identity may also be verified by comparing the reference
2532 identity to the Common Name (CN) [LDAP-SCHEMA] value in the last
2533 Relative Distinguished Name (RDN) of the subject field of the
2534 server's certificate (where "last" refers to the DER-encoded order,
2535 not the order of presentation in a string representation of DER-
2536 encoded data). This comparison is performed using the rules for
2537 comparison of DNS names in Section 3.1.3.1, below, with the exception
2538 that no wildcard matching is allowed. Although the use of the Common
2539 Name value is existing practice, it is deprecated, and Certification
2540 Authorities are encouraged to provide subjectAltName values instead.
2541 Note that the TLS implementation may represent DNs in certificates
2542 according to X.500 or other conventions. For example, some X.500
2543 implementations order the RDNs in a DN using a left-to-right (most
2544 significant to least significant) convention instead of LDAP's right-
2547 If the server identity check fails, user-oriented clients SHOULD
2548 either notify the user (clients may give the user the opportunity to
2549 continue with the LDAP session in this case) or close the transport
2550 connection and indicate that the server's identity is suspect.
2551 Automated clients SHOULD close the transport connection and then
2552 return or log an error indicating that the server's identity is
2555 Beyond the server identity check described in this section, clients
2556 should be prepared to do further checking to ensure that the server
2557 is authorized to provide the service it is requested to provide. The
2558 client may need to make use of local policy information in making
2561 3.1.3.1. Comparison of DNS Names
2563 If the reference identity is an internationalized domain name,
2564 conforming implementations MUST convert it to the ASCII Compatible
2565 Encoding (ACE) format as specified in Section 4 of RFC 3490
2566 [IDNA2003] before comparison with subjectAltName values of type
2567 dNSName. Specifically, conforming implementations MUST perform the
2568 conversion operation specified in Section 4 of RFC 3490 as follows:
2570 o in step 1, the domain name SHALL be considered a "stored string";
2572 o in step 3, set the flag called "UseSTD3ASCIIRules";
2574 o in step 4, process each label with the "ToASCII" operation; and
2578Saint-Andre & Hodges Standards Track [Page 46]
2580RFC 6125 Service Identity March 2011
2583 o in step 5, change all label separators to U+002E (full stop).
2585 After performing the "to-ASCII" conversion, the DNS labels and names
2586 MUST be compared for equality according to the rules specified in
2587 Section 3 of RFC3490.
2589 The '*' (ASCII 42) wildcard character is allowed in subjectAltName
2590 values of type dNSName, and then only as the left-most (least
2591 significant) DNS label in that value. This wildcard matches any
2592 left-most DNS label in the server name. That is, the subject
2593 *.example.com matches the server names a.example.com and
2594 b.example.com, but does not match example.com or a.b.example.com.
2596 3.1.3.2. Comparison of IP Addresses
2598 When the reference identity is an IP address, the identity MUST be
2599 converted to the "network byte order" octet string representation
2600 [IP] [IPv6]. For IP Version 4, as specified in RFC 791, the octet
2601 string will contain exactly four octets. For IP Version 6, as
2602 specified in RFC 2460, the octet string will contain exactly sixteen
2603 octets. This octet string is then compared against subjectAltName
2604 values of type iPAddress. A match occurs if the reference identity
2605 octet string and value octet strings are identical.
2607 3.1.3.3. Comparison of Other subjectName Types
2609 Client implementations MAY support matching against subjectAltName
2610 values of other types as described in other documents.
2614B.4. SMTP (2002/2007)
2616 In 2002, [SMTP-TLS] specified the following text regarding
2617 application service identity verification in SMTP:
2621 4.1 Processing After the STARTTLS Command
2625 The decision of whether or not to believe the authenticity of the
2626 other party in a TLS negotiation is a local matter. However, some
2627 general rules for the decisions are:
2634Saint-Andre & Hodges Standards Track [Page 47]
2636RFC 6125 Service Identity March 2011
2639 o A SMTP client would probably only want to authenticate an SMTP
2640 server whose server certificate has a domain name that is the
2641 domain name that the client thought it was connecting to.
2647 In 2006, [SMTP-AUTH] specified the following text regarding
2648 application service identity verification in SMTP:
2652 14. Additional Requirements When Using SASL PLAIN over TLS
2656 After a successful [TLS] negotiation, the client MUST check its
2657 understanding of the server hostname against the server's identity as
2658 presented in the server Certificate message, in order to prevent man-
2659 in-the-middle attacks. If the match fails, the client MUST NOT
2660 attempt to authenticate using the SASL PLAIN mechanism. Matching is
2661 performed according to the following rules:
2663 The client MUST use the server hostname it used to open the
2664 connection as the value to compare against the server name as
2665 expressed in the server certificate. The client MUST NOT use any
2666 form of the server hostname derived from an insecure remote source
2667 (e.g., insecure DNS lookup). CNAME canonicalization is not done.
2669 If a subjectAltName extension of type dNSName is present in the
2670 certificate, it SHOULD be used as the source of the server's
2673 Matching is case-insensitive.
2675 A "*" wildcard character MAY be used as the leftmost name
2676 component in the certificate. For example, *.example.com would
2677 match a.example.com, foo.example.com, etc., but would not match
2680 If the certificate contains multiple names (e.g., more than one
2681 dNSName field), then a match with any one of the fields is
2682 considered acceptable.
2690Saint-Andre & Hodges Standards Track [Page 48]
2692RFC 6125 Service Identity March 2011
2697 In 2004, [XMPP-OLD] specified the following text regarding
2698 application service identity verification in XMPP:
2702 14.2. Certificate Validation
2704 When an XMPP peer communicates with another peer securely, it MUST
2705 validate the peer's certificate. There are three possible cases:
2707 Case #1: The peer contains an End Entity certificate which appears
2708 to be certified by a certification path terminating in a trust
2709 anchor (as described in Section 6.1 of [PKIX]).
2711 Case #2: The peer certificate is certified by a Certificate
2712 Authority not known to the validating peer.
2714 Case #3: The peer certificate is self-signed.
2716 In Case #1, the validating peer MUST do one of two things:
2718 1. Verify the peer certificate according to the rules of [PKIX].
2719 The certificate SHOULD then be checked against the expected
2720 identity of the peer following the rules described in [HTTP-TLS],
2721 except that a subjectAltName extension of type "xmpp" MUST be
2722 used as the identity if present. If one of these checks fails,
2723 user-oriented clients MUST either notify the user (clients MAY
2724 give the user the opportunity to continue with the connection in
2725 any case) or terminate the connection with a bad certificate
2726 error. Automated clients SHOULD terminate the connection (with a
2727 bad certificate error) and log the error to an appropriate audit
2728 log. Automated clients MAY provide a configuration setting that
2729 disables this check, but MUST provide a setting that enables it.
2731 2. The peer SHOULD show the certificate to a user for approval,
2732 including the entire certification path. The peer MUST cache the
2733 certificate (or some non-forgeable representation such as a
2734 hash). In future connections, the peer MUST verify that the same
2735 certificate was presented and MUST notify the user if it has
2738 In Case #2 and Case #3, implementations SHOULD act as in (2) above.
2746Saint-Andre & Hodges Standards Track [Page 49]
2748RFC 6125 Service Identity March 2011
2751 Although [XMPP-OLD] defined its own rules, [XMPP] reuses the rules in
2752 this document regarding application service identity verification in
2757 In 2006, [NNTP-TLS] specified the following text regarding
2758 application service identity verification in NNTP:
2762 5. Security Considerations
2766 During the TLS negotiation, the client MUST check its understanding
2767 of the server hostname against the server's identity as presented in
2768 the server Certificate message, in order to prevent man-in-the-middle
2769 attacks. Matching is performed according to these rules:
2771 o The client MUST use the server hostname it used to open the
2772 connection (or the hostname specified in TLS "server_name"
2773 extension [TLS]) as the value to compare against the server name
2774 as expressed in the server certificate. The client MUST NOT use
2775 any form of the server hostname derived from an insecure remote
2776 source (e.g., insecure DNS lookup). CNAME canonicalization is not
2779 o If a subjectAltName extension of type dNSName is present in the
2780 certificate, it SHOULD be used as the source of the server's
2783 o Matching is case-insensitive.
2785 o A "*" wildcard character MAY be used as the left-most name
2786 component in the certificate. For example, *.example.com would
2787 match a.example.com, foo.example.com, etc., but would not match
2790 o If the certificate contains multiple names (e.g., more than one
2791 dNSName field), then a match with any one of the fields is
2792 considered acceptable.
2794 If the match fails, the client SHOULD either ask for explicit user
2795 confirmation or terminate the connection with a QUIT command and
2796 indicate the server's identity is suspect.
2802Saint-Andre & Hodges Standards Track [Page 50]
2804RFC 6125 Service Identity March 2011
2807 Additionally, clients MUST verify the binding between the identity of
2808 the servers to which they connect and the public keys presented by
2809 those servers. Clients SHOULD implement the algorithm in Section 6
2810 of [PKIX] for general certificate validation, but MAY supplement that
2811 algorithm with other validation methods that achieve equivalent
2812 levels of verification (such as comparing the server certificate
2813 against a local store of already-verified certificates and identity
2818B.7. NETCONF (2006/2009)
2820 In 2006, [NETCONF-SSH] specified the following text regarding
2821 application service identity verification in NETCONF:
2825 6. Security Considerations
2827 The identity of the server MUST be verified and authenticated by the
2828 client according to local policy before password-based authentication
2829 data or any configuration or state data is sent to or received from
2830 the server. The identity of the client MUST also be verified and
2831 authenticated by the server according to local policy to ensure that
2832 the incoming client request is legitimate before any configuration or
2833 state data is sent to or received from the client. Neither side
2834 should establish a NETCONF over SSH connection with an unknown,
2835 unexpected, or incorrect identity on the opposite side.
2839 In 2009, [NETCONF-TLS] specified the following text regarding
2840 application service identity verification in NETCONF:
2844 3.1. Server Identity
2846 During the TLS negotiation, the client MUST carefully examine the
2847 certificate presented by the server to determine if it meets the
2848 client's expectations. Particularly, the client MUST check its
2849 understanding of the server hostname against the server's identity as
2850 presented in the server Certificate message, in order to prevent man-
2851 in-the-middle attacks.
2858Saint-Andre & Hodges Standards Track [Page 51]
2860RFC 6125 Service Identity March 2011
2863 Matching is performed according to the rules below (following the
2864 example of [NNTP-TLS]):
2866 o The client MUST use the server hostname it used to open the
2867 connection (or the hostname specified in the TLS "server_name"
2868 extension [TLS]) as the value to compare against the server name
2869 as expressed in the server certificate. The client MUST NOT use
2870 any form of the server hostname derived from an insecure remote
2871 source (e.g., insecure DNS lookup). CNAME canonicalization is not
2874 o If a subjectAltName extension of type dNSName is present in the
2875 certificate, it MUST be used as the source of the server's
2878 o Matching is case-insensitive.
2880 o A "*" wildcard character MAY be used as the leftmost name
2881 component in the certificate. For example, *.example.com would
2882 match a.example.com, foo.example.com, etc., but would not match
2885 o If the certificate contains multiple names (e.g., more than one
2886 dNSName field), then a match with any one of the fields is
2887 considered acceptable.
2889 If the match fails, the client MUST either ask for explicit user
2890 confirmation or terminate the connection and indicate the server's
2891 identity is suspect.
2893 Additionally, clients MUST verify the binding between the identity of
2894 the servers to which they connect and the public keys presented by
2895 those servers. Clients SHOULD implement the algorithm in Section 6
2896 of [PKIX] for general certificate validation, but MAY supplement that
2897 algorithm with other validation methods that achieve equivalent
2898 levels of verification (such as comparing the server certificate
2899 against a local store of already-verified certificates and identity
2902 If the client has external information as to the expected identity of
2903 the server, the hostname check MAY be omitted.
2909 In 2009, [SYSLOG-TLS] specified the following text regarding
2910 application service identity verification in Syslog:
2914Saint-Andre & Hodges Standards Track [Page 52]
2916RFC 6125 Service Identity March 2011
2921 5.2. Subject Name Authorization
2923 Implementations MUST support certification path validation [PKIX].
2924 In addition, they MUST support specifying the authorized peers using
2925 locally configured host names and matching the name against the
2926 certificate as follows.
2928 o Implementations MUST support matching the locally configured host
2929 name against a dNSName in the subjectAltName extension field and
2930 SHOULD support checking the name against the common name portion
2931 of the subject distinguished name.
2933 o The '*' (ASCII 42) wildcard character is allowed in the dNSName of
2934 the subjectAltName extension (and in common name, if used to store
2935 the host name), but only as the left-most (least significant) DNS
2936 label in that value. This wildcard matches any left-most DNS
2937 label in the server name. That is, the subject *.example.com
2938 matches the server names a.example.com and b.example.com, but does
2939 not match example.com or a.b.example.com. Implementations MUST
2940 support wildcards in certificates as specified above, but MAY
2941 provide a configuration option to disable them.
2943 o Locally configured names MAY contain the wildcard character to
2944 match a range of values. The types of wildcards supported MAY be
2945 more flexible than those allowed in subject names, making it
2946 possible to support various policies for different environments.
2947 For example, a policy could allow for a trust-root-based
2948 authorization where all credentials issued by a particular CA
2949 trust root are authorized.
2951 o If the locally configured name is an internationalized domain
2952 name, conforming implementations MUST convert it to the ASCII
2953 Compatible Encoding (ACE) format for performing comparisons, as
2954 specified in Section 7 of [PKIX].
2956 o Implementations MAY support matching a locally configured IP
2957 address against an iPAddress stored in the subjectAltName
2958 extension. In this case, the locally configured IP address is
2959 converted to an octet string as specified in [PKIX], Section
2960 4.2.1.6. A match occurs if this octet string is equal to the
2961 value of iPAddress in the subjectAltName extension.
2970Saint-Andre & Hodges Standards Track [Page 53]
2972RFC 6125 Service Identity March 2011
2977 In 2010, [SIP-CERTS] specified the following text regarding
2978 application service identity verification in SIP:
2982 7.2. Comparing SIP Identities
2984 When an implementation (either client or server) compares two values
2985 as SIP domain identities:
2987 Implementations MUST compare only the DNS name component of each
2988 SIP domain identifier; an implementation MUST NOT use any scheme
2989 or parameters in the comparison.
2991 Implementations MUST compare the values as DNS names, which means
2992 that the comparison is case insensitive as specified by
2993 [DNS-CASE]. Implementations MUST handle Internationalized Domain
2994 Names (IDNs) in accordance with Section 7.2 of [PKIX].
2996 Implementations MUST match the values in their entirety:
2998 Implementations MUST NOT match suffixes. For example,
2999 "foo.example.com" does not match "example.com".
3001 Implementations MUST NOT match any form of wildcard, such as a
3002 leading "." or "*." with any other DNS label or sequence of
3003 labels. For example, "*.example.com" matches only
3004 "*.example.com" but not "foo.example.com". Similarly,
3005 ".example.com" matches only ".example.com", and does not match
3008 [HTTP-TLS] allows the dNSName component to contain a
3009 wildcard; e.g., "DNS:*.example.com". [PKIX], while not
3010 disallowing this explicitly, leaves the interpretation of
3011 wildcards to the individual specification. [SIP] does not
3012 provide any guidelines on the presence of wildcards in
3013 certificates. Through the rule above, this document
3014 prohibits such wildcards in certificates for SIP domains.
3026Saint-Andre & Hodges Standards Track [Page 54]
3028RFC 6125 Service Identity March 2011
3033 In 2010, [SNMP-TLS] specified the following text regarding
3034 application service identity verification in SNMP:
3038 If the server's presented certificate has passed certification path
3039 validation [PKIX] to a configured trust anchor, and an active row
3040 exists with a zero-length snmpTlstmAddrServerFingerprint value, then
3041 the snmpTlstmAddrServerIdentity column contains the expected host
3042 name. This expected host name is then compared against the server's
3043 certificate as follows:
3045 o Implementations MUST support matching the expected host name
3046 against a dNSName in the subjectAltName extension field and MAY
3047 support checking the name against the CommonName portion of the
3048 subject distinguished name.
3050 o The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName
3051 of the subjectAltName extension (and in common name, if used to
3052 store the host name), but only as the left-most (least
3053 significant) DNS label in that value. This wildcard matches any
3054 left-most DNS label in the server name. That is, the subject
3055 *.example.com matches the server names a.example.com and
3056 b.example.com, but does not match example.com or a.b.example.com.
3057 Implementations MUST support wildcards in certificates as
3058 specified above, but MAY provide a configuration option to disable
3061 o If the locally configured name is an internationalized domain
3062 name, conforming implementations MUST convert it to the ASCII
3063 Compatible Encoding (ACE) format for performing comparisons, as
3064 specified in Section 7 of [PKIX].
3066 If the expected host name fails these conditions then the connection
3073 In 2010, [GIST] specified the following text regarding application
3074 service identity verification in the General Internet Signalling
3082Saint-Andre & Hodges Standards Track [Page 55]
3084RFC 6125 Service Identity March 2011
3089 5.7.3.1. Identity Checking in TLS
3091 After TLS authentication, a node MUST check the identity presented by
3092 the peer in order to avoid man-in-the-middle attacks, and verify that
3093 the peer is authorised to take part in signalling at the GIST layer.
3094 The authorisation check is carried out by comparing the presented
3095 identity with each Authorised Peer Database (APD) entry in turn, as
3096 discussed in Section 4.4.2. This section defines the identity
3097 comparison algorithm for a single APD entry.
3099 For TLS authentication with X.509 certificates, an identity from the
3100 DNS namespace MUST be checked against each subjectAltName extension
3101 of type dNSName present in the certificate. If no such extension is
3102 present, then the identity MUST be compared to the (most specific)
3103 Common Name in the Subject field of the certificate. When matching
3104 DNS names against dNSName or Common Name fields, matching is case-
3105 insensitive. Also, a "*" wildcard character MAY be used as the left-
3106 most name component in the certificate or identity in the APD. For
3107 example, *.example.com in the APD would match certificates for
3108 a.example.com, foo.example.com, *.example.com, etc., but would not
3109 match example.com. Similarly, a certificate for *.example.com would
3110 be valid for APD identities of a.example.com, foo.example.com,
3111 *.example.com, etc., but not example.com.
3113 Additionally, a node MUST verify the binding between the identity of
3114 the peer to which it connects and the public key presented by that
3115 peer. Nodes SHOULD implement the algorithm in Section 6 of [PKIX]
3116 for general certificate validation, but MAY supplement that algorithm
3117 with other validation methods that achieve equivalent levels of
3118 verification (such as comparing the server certificate against a
3119 local store of already-verified certificates and identity bindings).
3121 For TLS authentication with pre-shared keys, the identity in the
3122 psk_identity_hint (for the server identity, i.e. the Responding node)
3123 or psk_identity (for the client identity, i.e. the Querying node)
3124 MUST be compared to the identities in the APD.
3138Saint-Andre & Hodges Standards Track [Page 56]
3140RFC 6125 Service Identity March 2011
3147 1899 Wyknoop Street, Suite 600
3151 Phone: +1-303-308-3282
3152 EMail: psaintan@cisco.com
3157 2211 North First Street
3158 San Jose, California 95131
3161 EMail: Jeff.Hodges@PayPal.com
3194Saint-Andre & Hodges Standards Track [Page 57]