< draft-saintandre-tls-server-id-check-11.txt   draft-saintandre-tls-server-id-check-12.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP J. Hodges Intended status: BCP J. Hodges
Expires: May 21, 2011 PayPal Expires: June 16, 2011 PayPal
November 17, 2010 December 13, 2010
Representation and Verification of Domain-Based Application Service Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS) Certificates in the Context of Transport Layer Security (TLS)
draft-saintandre-tls-server-id-check-11 draft-saintandre-tls-server-id-check-12
Abstract Abstract
Many application technologies enable a secure connection between two Many application technologies enable secure communication between two
entities by means of Internet Public Key Infrastructure Using X.509 entities by means of Internet Public Key Infrastructure Using X.509
(PKIX) certificates in the context of Transport Layer Security (TLS). (PKIX) certificates in the context of Transport Layer Security (TLS).
This document specifies best current practices for representing and This document specifies best current practices for representing and
verifying the identity of application services in such interactions. verifying the identity of application services in such interactions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2011. This Internet-Draft will expire on June 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability and Audience . . . . . . . . . . . . . . . . 5 1.2. Applicability and Audience . . . . . . . . . . . . . . . . 5
1.3. Overview of Recommendations . . . . . . . . . . . . . . . 6 1.3. Overview of Recommendations . . . . . . . . . . . . . . . 6
1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 7
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
1.6. Contributors . . . . . . . . . . . . . . . . . . . . . . . 12
1.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Naming Application Services . . . . . . . . . . . . . . . 13 2.1. Naming Application Services . . . . . . . . . . . . . . . 13
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15
3. Representation of Server Identity . . . . . . . . . . . . . . 17 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Representation of Server Identity . . . . . . . . . . . . . . 18
3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Verification of Service Identity . . . . . . . . . . . . . . . 19 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. Verification of Service Identity . . . . . . . . . . . . . . . 20
4.2. Constructing a List of Reference Identifiers . . . . . . . 19 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Constructing a List of Reference Identifiers . . . . . . . 20
4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Preparing to Seeking a Match . . . . . . . . . . . . . . . 21 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 22
4.4. Verifying the DNS Domain Name Portion . . . . . . . . . . 23 4.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 22
4.4.1. Checking of Traditional Domain Names . . . . . . . . . 23 4.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 24
4.4.2. Checking of Internationalized Domain Names . . . . . . 23 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 24
4.4.3. Checking of Wildcard Certificates . . . . . . . . . . 23 4.4.2. Checking of Internationalized Domain Names . . . . . . 24
4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 24 4.4.3. Checking of Wildcard Certificates . . . . . . . . . . 25
4.5. Verifying the Application Type Portion . . . . . . . . . . 24 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 25
4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 25 4.5. Matching the Application Type Portion . . . . . . . . . . 26
4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 25 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 25 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 25 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 26
4.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 25 4.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 27
4.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 25 4.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 26 5.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 28
5.3. Internationalized Domain Names . . . . . . . . . . . . . . 27 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7.2. Informative References . . . . . . . . . . . . . . . . . . 28 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . . 32
A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 37
A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 37
A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 41 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 38
A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 42 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 39
A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 43 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 42
A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 44 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 43
A.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 45 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 44
A.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 46 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 47
A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 48
A.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 49
A.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
The visible face of the Internet consists of services that employ a The visible face of the Internet largely consists of services that
client-server architecture in which an interactive or automated employ a client-server architecture in which an interactive or
client connects to an application service in order to retrieve or automated client communicates with an application service in order to
upload information, communicate with other entities, or access a retrieve or upload information, communicate with other entities, or
broader network of services. When a client connects to an access a broader network of services. When a client communicates
application service using Transport Layer Security [TLS] or Datagram with an application service using Transport Layer Security [TLS] or
Transport Layer Security [DTLS], it references some conception of the Datagram Transport Layer Security [DTLS], it references some notion
server's identity while attempting to establish a secure connection of the server's identity (e.g., "the website at example.com") while
(e.g., "the website at example.com"). Likewise, during TLS attempting to establish secure communication. Likewise, during TLS
negotiation the server presents its conception of the service's negotiation the server presents its notion of the service's identity
identity in the form of a public-key certificate that was issued by a in the form of a public-key certificate that was issued by a
certification authority (CA) in the context of the Internet Public certification authority (CA) in the context of the Internet Public
Key Infrastructure using X.509 [PKIX]. Informally, we can think of Key Infrastructure using X.509 [PKIX]. Informally, we can think of
these identities as the client's "reference identity" and the these identities as the client's "reference identity" and the
server's "presented identity" (these rough ideas are defined more server's "presented identity" (these rough ideas are defined more
precisely later in this document through the concept of particular precisely later in this document through the concept of particular
identifiers). In general, a client needs to verify that the server's identifiers). In general, a client needs to verify that the server's
presented identity matches its reference identity so it can be sure presented identity matches its reference identity so it can be sure
that the certificate can legitimately be used to authenticate the that the certificate can legitimately be used to authenticate the
connection. communication.
Many application technologies adhere to the pattern just outlined, Many application technologies adhere to the pattern just outlined,
including but not limited to the following: including but not limited to the following:
o The Internet Message Access Protocol [IMAP] and the Post Office o The Internet Message Access Protocol [IMAP] and the Post Office
Protocol [POP3], for which see also [USINGTLS] Protocol [POP3], for which see also [USINGTLS]
o The Hypertext Transfer Protocol [HTTP], for which see also o The Hypertext Transfer Protocol [HTTP], for which see also
[HTTP-TLS] [HTTP-TLS]
skipping to change at page 5, line 29 skipping to change at page 5, line 29
Application protocols have traditionally specified their own rules Application protocols have traditionally specified their own rules
for representing and verifying application service identity. for representing and verifying application service identity.
Unfortunately, this divergence of approaches has caused some Unfortunately, this divergence of approaches has caused some
confusion among certification authorities, application developers, confusion among certification authorities, application developers,
and protocol designers. and protocol designers.
Therefore, to codify best current practices regarding the Therefore, to codify best current practices regarding the
implementation and deployment of secure PKIX-based authentication, implementation and deployment of secure PKIX-based authentication,
this document specifies recommended procedures for representing and this document specifies recommended procedures for representing and
verifying application service identity in certificates intended for verifying application service identity in certificates intended for
use in applications employing TLS. use in application protocols employing TLS.
1.2. Applicability and Audience 1.2. Applicability and Audience
This document does not supersede the rules for certificate issuance This document does not supersede the rules for certificate issuance
or validation provided in [PKIX], which governs any certificate- or validation provided in [PKIX]. Therefore, [PKIX] is authoritative
related topic on which this document is silent (e.g., certificate on any point that might also be discussed in this document.
Furthermore, [PKIX] also governs any certificate-related topic on
which this document is silent, including but limited to certificate
syntax, certificate extensions such as name constraints and extended syntax, certificate extensions such as name constraints and extended
key usage, and handling of certification paths). Specifically, in key usage, and handling of certification paths.
order to ensure proper authentication, application clients need to
verify the entire certification path, because this document addresses This document addresses only name forms in the leaf "end entity"
only name forms in the leaf server certificate, not any name forms in server certificate, not any name forms in the chain of certificates
the chain of certificates used to validate the server certificate. used to validate the server certificate. Therefore, in order to
ensure proper authentication, application clients need to verify the
entire certification path per [PKIX].
This document also does not supersede the rules for verifying service This document also does not supersede the rules for verifying service
identity provided in specifications for existing application identity provided in specifications for existing application
protocols, such as those mentioned under Appendix A. However, the protocols published prior to this BCP, such as those excerpted under
best current practices described here can be referenced by future Appendix A. However, the best current practices described here can
specifications, including updates to specifications for existing be referenced by future specifications, including updates to
application protocols if the relevant technology communities agree to specifications for existing application protocols if the relevant
do so. It is also expected that this document will be updated or technology communities agree to do so. It is also expected that this
obsoleted in the future as best practices for issuance and document will be updated or obsoleted in the future as best practices
verification of PKIX certificates continue to evolve through more for issuance and verification of PKIX certificates continue to evolve
widespread implementation and deployment of TLS-protected application through more widespread implementation and deployment of TLS-
services over the Internet. protected application services over the Internet.
The primary audience for this document consists of application The primary audience for this document consists of application
protocol designers, who might reference this document instead of protocol designers, who can reference this document instead of
defining their own rules for the representation and verification of defining their own rules for the representation and verification of
application service identity. Secondarily, the audience consists of application service identity. Secondarily, the audience consists of
certification authorities, client developers, service providers, and certification authorities, client developers, service providers, and
other members of technology communities that might re-use or other members of technology communities that can re-use the
"profile" the recommendations in this document when defining recommendations in this document when defining certificate issuance
certificate issuance policies, writing software algorithms for policies, writing software algorithms for identity matching,
identity matching, generating certificate signing requests, etc. generating certificate signing requests, and so forth.
1.3. Overview of Recommendations 1.3. Overview of Recommendations
To orient the reader, this section provides an informational overview To orient the reader, this section provides an informational overview
of the recommendations contained in this document. of the recommendations contained in this document.
For the primary audience of application protocol designers, based on For the primary audience of application protocol designers, based on
best current practices this document provides recommended procedures best current practices this document provides recommended procedures
for representation and verification of application service identity for the representation and verification of application service
within PKIX certificates used in the context of TLS. identity within PKIX certificates used in the context of TLS.
For the secondary audiences, in essence this document encourages For the secondary audiences, in essence this document encourages
certification authorities, application service providers, and certification authorities, application service providers, and
application client developers to coalesce on the following best application client developers to coalesce on the following best
current practices: current practices:
o Move away from including and checking strings that look like o Move away from including and checking strings that look like
domain names in the subject's Common Name. domain names in the subject's Common Name.
o Move toward including and checking DNS domain names via the o Move toward including and checking DNS domain names via the
skipping to change at page 7, line 28 skipping to change at page 7, line 32
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
o Client or end-user identities. o Client or end-user identities.
Certificates representing client or end-user identities (e.g., the Certificates representing client or end-user identities (e.g., the
rfc822Name identifier) can be used for mutual authentication rfc822Name identifier) can be used for mutual authentication
between a client and server or between two clients, thus enabling between a client and server or between two clients, thus enabling
stronger client-server security or end-to-end security. However, stronger client-server security or end-to-end security. However,
certification authorities, application developers, and service certification authorities, application developers, and service
operators have less experience with client certificates than with operators have less experience with client certificates than with
server certificates, thus gives us fewer models from which to server certificates, thus giving us fewer models from which to
generalize and a less solid basis for defining best practices. generalize and a less solid basis for defining best practices.
o Identifiers other than fully-qualified DNS domain names. o Identifiers other than fully-qualified DNS domain names.
Some certification authorities issue server certificates based on Some certification authorities issue server certificates based on
IP addresses, but preliminary evidence indicates that such IP addresses, but preliminary evidence indicates that such
certificates are a very small percentage (less than 1%) of issued certificates are a very small percentage (less than 1%) of issued
certificates. Furthermore, IP addresses are not necessarily certificates. Furthermore, IP addresses are not necessarily
reliable identifiers for application services because of the reliable identifiers for application services because of the
existence of private internets [PRIVATE], host mobility, multiple existence of private internets [PRIVATE], host mobility, multiple
skipping to change at page 7, line 50 skipping to change at page 8, line 6
resulting in different addresses for a host from different resulting in different addresses for a host from different
locations on the network, the practice of grouping many hosts locations on the network, the practice of grouping many hosts
together behind a single IP address, etc. Most fundamentally, together behind a single IP address, etc. Most fundamentally,
most users find DNS domain names much easier to work with than IP most users find DNS domain names much easier to work with than IP
addresses, which is why the domain name system was designed in the addresses, which is why the domain name system was designed in the
first place. We prefer to define best practices for the much more first place. We prefer to define best practices for the much more
common use case and not to complicate the rules in this common use case and not to complicate the rules in this
specification. specification.
Furthermore, we focus here on application service identities, not Furthermore, we focus here on application service identities, not
specific resources located at such services, e.g., a specific web specific resources located at such services. Therefore this
page that can be accessed at a particular Uniform Resource document discusses Uniform Resource Identifiers [URI] only as a
Identifier [URI] whose authority component is the DNS domain name way to communicate a DNS domain name (via the URI "authority"
of the application service. We also do not address identifiers component), not as a way to communicate other aspects of a service
derived from Naming Authority Pointer (NAPTR) DNS resource records such as a specific resource (via the URI "path" component) or
[NAPTR] and related technologies such as [S-NAPTR], since such parameters (via the URI "query" component).
identifiers cannot be validated in a trusted manner in the absence
of [DNSSEC].
Finally, we do not discuss attributes unrelated to DNS domain We also do not discuss attributes unrelated to DNS domain names,
names, such as those defined in [X.520] and other such such as those defined in [X.520] and other such specifications
specifications (e.g., organizational attributes, geographical (e.g., organizational attributes, geographical attributes, company
attributes, company logos, and the like). logos, and the like).
o Security protocols other than [TLS], [DTLS], or the older Secure o Security protocols other than [TLS], [DTLS], or the older Secure
Sockets Layer (SSL) technology. Sockets Layer (SSL) technology.
Although other secure, lower-layer protocols exist and even employ Although other secure, lower-layer protocols exist and even employ
PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases
can differ from those of TLS-based and DTLS-based application can differ from those of TLS-based and DTLS-based application
technologies. Furthermore, application technologies have less technologies. Furthermore, application technologies have less
experience with IPsec than with TLS, thus making it more difficult experience with IPsec than with TLS, thus making it more difficult
to gather feedback on proposed best practices. to gather feedback on proposed best practices.
o Keys or certificates employed outside the context of PKIX-based o Keys or certificates employed outside the context of PKIX-based
systems. systems.
Some deployed application technologies use a web of trust model Some deployed application technologies use a web of trust model
based on or similar to OpenPGP [OPENPGP], or use self-signed based on or similar to OpenPGP [OPENPGP], or use self-signed
certificates, or are deployed on networks that are not directly certificates, or are deployed on networks that are not directly
connected to the public Internet and therefore cannot depend on connected to the public Internet and therefore cannot depend on
Certificate Revocation Lists (CRLs) or the Online Certificate Certificate Revocation Lists (CRLs) or the Online Certificate
Status Protocol [OCSP] to check CA-issued certificates. However, Status Protocol [OCSP] to check CA-issued certificates. However,
the syntax of OpenPGP differs essentially from that of X.509, the the method for binding a public key to an identifier in OpenPGP
data in self-signed certificates has not been certified by a third differs essentially from the method in X.509, the data in self-
party in any way, and checking of CA-issued certificates via CRLs signed certificates has not been certified by a third party in any
or OSCP is critically important to maintaining the security of way, and checking of CA-issued certificates via CRLs or OSCP is
PKIX-based systems. Attempting to define best practices for such critically important to maintaining the security of PKIX-based
systems. Attempting to define best practices for such
technologies would unduly complicate the rules defined in this technologies would unduly complicate the rules defined in this
specification. specification.
Furthermore, this document also does not address various o Certification authority policies, such as:
certification authority policies, such as:
o What types or "classes" of certificates to issue and whether to * What types or "classes" of certificates to issue and whether to
apply different policies for them (e.g., allow the wildcard apply different policies for them (e.g., allow the wildcard
character in certificates issued to individuals who have provided character in certificates issued to individuals who have
proof of identity but do not allow the wildcard character in provided proof of identity but do not allow the wildcard
"Extended Validation" certificates [EV-CERTS]). character in "Extended Validation" certificates [EV-CERTS]).
o Whether to issue certificates based on IP addresses (or some other * Whether to issue certificates based on IP addresses (or some
form, such as relative domain names) in addition to fully- other form, such as relative domain names) in addition to
qualified DNS domain names. fully-qualified DNS domain names.
o Which identifiers to include (e.g., whether to include SRV-IDs or * Which identifiers to include (e.g., whether to include SRV-IDs
URI-IDs as defined in the body of this specification). or URI-IDs as defined in the body of this specification).
o How to certify or validate fully-qualified domain names and * How to certify or validate fully-qualified DNS domain names and
application service types. application service types.
o How to certify or validate other kinds of information that might * How to certify or validate other kinds of information that
be included in a certificate (e.g., organization name). might be included in a certificate (e.g., organization name).
Finally, this specification is mostly silent about user interface o Resolution of DNS domain names.
issues, which in general are properly the responsibility of client
software developers and standards development organizations dedicated Although the process whereby a client resolves the DNS domain name
to particular application technologies (see for example [WSC-UI]). of an application service can involve several steps (e.g., this is
true of resolutions that depend on DNS SRV resource records,
Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and
related technologies such as [S-NAPTR]), for our purposes we care
only about the fact that the client needs to verify the identity
of the entity with which it communicates as a result of the
resolution process. Thus the resolution process itself is out of
scope for this specification.
o User interface issues.
In general, such issues are properly the responsibility of client
software developers and standards development organizations
dedicated to particular application technologies (see for example
[WSC-UI]).
1.5. Terminology 1.5. Terminology
Because many concepts related to "identity" are often too vague to be Because many concepts related to "identity" are often too vague to be
actionable in application protocols, we define a set of more concrete actionable in application protocols, we define a set of more concrete
terms for use in this specification. (Following the convention from terms for use in this specification.
[SECTERMS], each entry is preceded by a dollar sign ($) and a space.)
application service: A service on the Internet that enables application service: A service on the Internet that enables
interactive and automated clients to connect for the purpose of interactive and automated clients to connect for the purpose of
retrieving or uploading information, communicating with other retrieving or uploading information, communicating with other
entities, or connecting to a broader network of services. entities, or connecting to a broader network of services.
application service provider: An organization or individual that application service provider: An organization or individual that
hosts or deploys an application service. hosts or deploys an application service.
attribute-type-and-value pair: A colloquial name for the ASN.1-based attribute-type-and-value pair: A colloquial name for the ASN.1-based
construction comprising a Relative Distinguished Name (RDN), which construction comprising a Relative Distinguished Name (RDN), which
itself is a building-block component of Distinguished Names. See itself is a building-block component of Distinguished Names. See
Section 2 of [LDAP-DN]. Section 2 of [LDAP-DN].
automated client: A software agent or device that is not directly automated client: A software agent or device that is not directly
controlled by a human user. controlled by a human user.
delegated domain: A domain name or host name that is explicitly delegated domain: A domain name or host name that is explicitly
configured for connecting to the source domain, by either (a) the configured for communicating with the source domain, by either (a)
human user controlling an interactive client or (b) a trusted the human user controlling an interactive client or (b) a trusted
administrator. In case (a), one example of delegation is an administrator. In case (a), one example of delegation is an
account setup that specifies the domain name of a particular host account setup that specifies the domain name of a particular host
to be used for retrieving information or connecting to a network, to be used for retrieving information or connecting to a network,
which might be different from the server portion of the user's which might be different from the server portion of the user's
account name (e.g., a server at mailhost.example.com for account name (e.g., a server at mailhost.example.com for
connecting to an IMAP server hosting an email address of connecting to an IMAP server hosting an email address of
juliet@example.com). In case (b), one example of delegation is an juliet@example.com). In case (b), one example of delegation is an
admin-configured host-to-address/address-to-host lookup table. admin-configured host-to-address/address-to-host lookup table.
derived domain: A domain name or host name that a client has derived derived domain: A domain name or host name that a client has derived
from the source domain in an automated fashion (e.g., by means of from the source domain in an automated fashion (e.g., by means of
a [DNS-SRV] lookup). a [DNS-SRV] lookup).
identifier: A particular instance of an identifier type that is identifier: A particular instance of an identifier type that is
either presented by a server in a certificate or referenced by a either presented by a server in a certificate or referenced by a
client for matching purposes. client for matching purposes.
identifier type: A formally defined category of identifier that can identifier type: A formally defined category of identifier that can
be included in a certificate and therefore that can also be used be included in a certificate and therefore that can also be used
for matching purposes; the types covered in this specification for matching purposes. For conciseness and convenience, we define
are: the following identifier types of interest, which are based on
those found in the PKIX specification [PKIX] and various PKIX
extensions.
* CN-ID = a Relative Distinguished Name (RDN) in the certificate * CN-ID = a Relative Distinguished Name (RDN) in the certificate
subject field that contains one and only one attribute-type- subject field that contains one and only one attribute-type-
and-value pair of type Common Name (CN), where the value and-value pair of type Common Name (CN), where the value
matches the overall form of a domain name (informally, dot- matches the overall form of a domain name (informally, dot-
separated letter-digit-hyphen labels); see [PKIX] and also separated letter-digit-hyphen labels); see [PKIX] and also
[LDAP-SCHEMA] [LDAP-SCHEMA]
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
* SRV-ID = a subjectAltName entry of type otherName whose name * SRV-ID = a subjectAltName entry of type otherName whose name
form is SRVName; see [SRVNAME] form is SRVName; see [SRVNAME]
* URI-ID = a subjectAltName entry of type * URI-ID = a subjectAltName entry of type
uniformResourceIdentifier, where the value includes both (i) a uniformResourceIdentifier whose value includes both (i) a
"scheme" and (ii) an "authority" component whose "host" "scheme" and (ii) an "authority" component whose "host"
subcomponent matches the "reg-name" rule (where the quoted subcomponent matches the "reg-name" rule (where the quoted
terms represent the associated [ABNF] rules from [URI]); see terms represent the associated [ABNF] productions from [URI]);
[PKIX] see [PKIX] and [URI]
interactive client: A software agent or device that is directly interactive client: A software agent or device that is directly
controlled by a human user. (Other specifications related to controlled by a human user. (Other specifications related to
security and application protocols, such as [WSC-UI], often refer security and application protocols, such as [WSC-UI], often refer
to this entity as a "user agent"; however that term is neither to this entity as a "user agent".
entirely accurate nor consistent with the terminology of common
application protocols such as [HTTP].)
pinning: The act of establishing a cached name association between pinning: The act of establishing a cached name association between
the application service's certificate and one of the client's the application service's certificate and one of the client's
reference identifiers, despite the fact that none of the presented reference identifiers, despite the fact that none of the presented
identifiers matches the given reference identifier. Pinning is identifiers matches the given reference identifier. Pinning is
accomplished by allowing a human user to positively accept the accomplished by allowing a human user to positively accept the
mismatch during an attempt to connect to the application service. mismatch during an attempt to communicate with the application
Once a cached name association is established, the certificate is service. Once a cached name association is established, the
said to be pinned to the reference identifier and in future certificate is said to be pinned to the reference identifier and
connection attempts the client simply verifies that the service's in future communication attempts the client simply verifies that
presented certificate matches the pinned certificate, as described the service's presented certificate matches the pinned
under Section 4.6.2. (A similar definition of "pinning" is certificate, as described under Section 4.6.2. (A similar
provided in [WSC-UI].) definition of "pinning" is provided in [WSC-UI].)
PKIX: PKIX is a short name for the Internet Public Key PKIX: PKIX is a short name for the Internet Public Key
Infrastructure using X.509 defined in RFC 5280 [PKIX], which Infrastructure using X.509 defined in RFC 5280 [PKIX], which
comprises a profile of the X.509v3 certificate specifications and comprises a profile of the X.509v3 certificate specifications and
X.509v2 certificate revocation list (CRL) specifications for use X.509v2 certificate revocation list (CRL) specifications for use
in the Internet. in the Internet.
PKIX-based system: A software implementation or deployed service PKIX-based system: A software implementation or deployed service
that makes use of X.509v3 certificates and X.509v2 certificate that makes use of X.509v3 certificates and X.509v2 certificate
revocation lists (CRLs). revocation lists (CRLs).
PKIX certificate: An X.509v3 certificate generated and employed in PKIX certificate: An X.509v3 certificate generated and employed in
the context of PKIX. the context of PKIX.
presented identifier: An identifier that is presented by a server to presented identifier: An identifier that is presented by a server to
a client within the server's PKIX certificate when the client a client within a PKIX certificate when the client attempts to
attempts to establish a secure connection with the server; the establish secure communication with the server; the certificate
certificate can include one or more presented identifiers of can include one or more presented identifiers of different types,
different types. and if the server hosts more than one domain then the certificate
might present distinct identifiers for each domain.
reference identifier: An identifier, constructed from a source reference identifier: An identifier, constructed from a source
domain and optionally a service type, used by the client for domain and optionally a service type, used by the client for
matching purposes when examining presented identifiers. matching purposes when examining presented identifiers.
service type: A formal identifier for the application protocol used service type: A formal identifier for the application protocol used
to provide a particular kind of service at a domain; the service to provide a particular kind of service at a domain; the service
type typically takes the form of a Uniform Resource Identifier type typically takes the form of a Uniform Resource Identifier
scheme [URI] or a DNS SRV Service [DNS-SRV]. scheme [URI] or a DNS SRV Service [DNS-SRV].
skipping to change at page 12, line 11 skipping to change at page 12, line 28
hyperlink. The combination of a source domain and, optionally, a hyperlink. The combination of a source domain and, optionally, a
service type enables a client to construct one or more reference service type enables a client to construct one or more reference
identifiers. identifiers.
subjectAltName entry: An identifier placed in a subjectAltName subjectAltName entry: An identifier placed in a subjectAltName
extension. extension.
subjectAltName extension: A standard PKIX certificate extension subjectAltName extension: A standard PKIX certificate extension
[PKIX] enabling identifiers of various types to be bound to the [PKIX] enabling identifiers of various types to be bound to the
certificate subject -- in addition to, or in place of, identifiers certificate subject -- in addition to, or in place of, identifiers
that may be embedded in or provided as a certificate's subject that may be embedded within or provided as a certificate's subject
field. field.
subject field: The subject field of a PKIX certificate identifies subject field: The subject field of a PKIX certificate identifies
the entity associated with the public key stored in the subject the entity associated with the public key stored in the subject
public key field (see Section 4.1.2.6 of [PKIX]). public key field (see Section 4.1.2.6 of [PKIX]).
subject name: In an overall sense, a subject's name(s) can be subject name: In an overall sense, a subject's name(s) can be
represented by or in the subject field, the subjectAltName represented by or in the subject field, the subjectAltName
extension, or both (see [PKIX] for details). More specifically, extension, or both (see [PKIX] for details). More specifically,
the term often refers to the composite name of a PKIX the term often refers to the name of a PKIX certificate's subject,
certificate's subject, encoded as the X.501 type Name and conveyed encoded as the X.501 type Name and conveyed in a certificate's
in a certificate's subject field (see Section 4.1.2.6 of [PKIX]). subject field (see Section 4.1.2.6 of [PKIX]).
TLS client: An entity that assumes the role of a client in a TLS client: An entity that assumes the role of a client in a
Transport Layer Security [TLS] negotiation; in this specification Transport Layer Security [TLS] negotiation; in this specification
we generally assume that the TLS client is an (interactive or we generally assume that the TLS client is an (interactive or
automated) application client, however in application protocols automated) application client, however in application protocols
that enable server-to-server communication the TLS client could be that enable server-to-server communication the TLS client could be
a peer application service. a peer application service.
TLS server: An entity that assumes the role of a server in a TLS server: An entity that assumes the role of a server in a
Transport Layer Security [TLS] negotiation; in this specfication Transport Layer Security [TLS] negotiation; in this specfication
skipping to change at page 12, line 48 skipping to change at page 13, line 21
limited to, "attack", "authentication", "authorization", limited to, "attack", "authentication", "authorization",
"certification authority", "certification path", "certificate", "certification authority", "certification path", "certificate",
"credential", "identity", "self-signed certificate", "trust", "trust "credential", "identity", "self-signed certificate", "trust", "trust
anchor", "trust chain", "validate", and "verify". anchor", "trust chain", "validate", and "verify".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[KEYWORDS]. [KEYWORDS].
1.6. Contributors
The following individuals made important contributions to the text of
this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
1.7. Acknowledgements
The editors and contributors wish to thank the following individuals
for their feedback and suggestions: Bernard Aboba, Richard Barnes,
Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Ben
Campbell, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave
Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip
Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul
Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey
Hutzelman, Simon Josefsson, Geoff Keating, John Klensin, Scott
Lawrence, Matt McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel,
Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea,
Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan
Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew
Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner,
Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.
2. Names 2. Names
This section discusses naming of application services on the This section discusses naming of application services on the
Internet, followed by a brief tutorial about subject naming in PKIX. Internet, followed by a brief tutorial about subject naming in PKIX.
2.1. Naming Application Services 2.1. Naming Application Services
This specification assumes that the name of an application service is This specification assumes that the name of an application service is
based on a DNS domain name (e.g., "example.com") -- supplemented in based on a DNS domain name (e.g., "example.com") -- supplemented in
some circumstances by a service type (e.g., "the IMAP server at some circumstances by a service type (e.g., "the IMAP server at
example.com"). example.com").
From the perspective of the application client or user, some names From the perspective of the application client or user, some names
are direct because they are provided directly by a human user (e.g., are direct because they are provided directly by a human user (e.g.,
via runtime input, prior configuration, or explicit acceptance of a via runtime input, prior configuration, or explicit acceptance of a
client connection attempt) whereas other names are indirect because client communication attempt) whereas other names are indirect
they are automatially resolved by the client based on user input because they are automatically resolved by the client based on user
(e.g., a target name resolved from a source name using DNS SRV input (e.g., a target name resolved from a source name using DNS SRV
records). This dimension matters most for certificate consumption, or NAPTR records). This dimension matters most for certificate
specifically verification as discussed in this document. consumption, specifically verification as discussed in this document.
From the perspective of the application service, some names are From the perspective of the application service, some names are
unrestricted because they can be used in any type of service (e.g., a unrestricted because they can be used in any type of service (e.g., a
certificate might be re-used for both the HTTP service and the IMAP certificate might be re-used for both the HTTP service and the IMAP
service at example.com) whereas other names are restricted because service at example.com) whereas other names are restricted because
they can be used in only one type of service (e.g., a special-purpose they can be used in only one type of service (e.g., a special-purpose
certificate that can be used only for an IMAP service). This certificate that can be used only for an IMAP service). This
dimension matters most for certificate issuance. dimension matters most for certificate issuance.
Therefore: Therefore we can categorize the identifier types of interest as
follows:
o A CN-ID is direct and unrestricted. o A CN-ID is direct and unrestricted.
o A DNS-ID is direct and unrestricted. o A DNS-ID is direct and unrestricted.
o An SRV-ID can be either direct or (more typically) indirect, and o An SRV-ID can be either direct or (more typically) indirect, and
is restricted. is restricted.
o A URI-ID is direct and restricted. o A URI-ID is direct and restricted.
skipping to change at page 14, line 42 skipping to change at page 14, line 42
client implementations, application service providers, and client implementations, application service providers, and
certification authorities. Ideally, protocol specifications that certification authorities. Ideally, protocol specifications that
reference this document will specify which identifiers are mandatory- reference this document will specify which identifiers are mandatory-
to-implement by servers and clients, which identifiers ought to be to-implement by servers and clients, which identifiers ought to be
supported by certificate issuers, and which identifiers ought to be supported by certificate issuers, and which identifiers ought to be
requested by application service providers. Because these requested by application service providers. Because these
requirements differ across applications, it is impossible to requirements differ across applications, it is impossible to
categorically stipulate universal rules (e.g., that all software categorically stipulate universal rules (e.g., that all software
implementations, service providers, and certification authorities for implementations, service providers, and certification authorities for
all application protocols need to use or support DNS-IDs as a all application protocols need to use or support DNS-IDs as a
baseline for the purpose of interoperability). However, it is baseline for the purpose of interoperability).
preferable that each application protocol will at least define a
baseline that applies to the community of software developers, However, it is preferable that each application protocol will at
application service providers, and CAs actively using or supporting least define a baseline that applies to the community of software
that technology (one such community, the CA/Browser Forum, has developers, application service providers, and CAs actively using or
codified such a baseline for "Extended Validation Certificates" in supporting that technology (one such community, the CA/Browser Forum,
[EV-CERTS]). has codified such a baseline for "Extended Validation Certificates"
in [EV-CERTS]).
2.2. DNS Domain Names 2.2. DNS Domain Names
For the purposes of this specification, the name of an application For the purposes of this specification, the name of an application
service is a DNS domain name that conforms to one of the following service is (or is based on) a DNS domain name that conforms to one of
forms: the following forms:
1. A "traditional domain name", i.e., a fully-qualified domain name 1. A "traditional domain name", i.e., a fully-qualified DNS domain
or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH
labels" as defined in [IDNA-DEFS]. Informally, such labels are labels" as described in [IDNA-DEFS]. Informally, such labels are
constrained to [US-ASCII] letters, digits, and the hyphen, with constrained to [US-ASCII] letters, digits, and the hyphen, with
the hyphen prohibited in the first character position. the hyphen prohibited in the first character position.
Additional qualifications apply (please refer to the above- Additional qualifications apply (please refer to the above-
referenced specifications for details) but they are not relevant referenced specifications for details) but they are not relevant
to this specification. to this specification.
2. An "internationalized domain name", i.e., a DNS domain name that 2. An "internationalized domain name", i.e., a DNS domain name that
conforms to the overall form of a domain name (informally, dot- conforms to the overall form of a domain name (informally, dot-
separated letter-digit-hyphen labels) but that can include separated letter-digit-hyphen labels) but includes at least one
appropriately encoded Unicode code points outside the traditional label containing appropriately encoded Unicode code points
US-ASCII range (more precisely, either U-labels or A-labels as outside the traditional US-ASCII range. That is, it contains at
described in [IDNA-DEFS] and the associated documents). least one U-label or A-label, but otherwise may contain any
mixture of NR-LDH labels, A-labels, or U-labels, as described in
[IDNA-DEFS] and the associated documents).
2.3. Subject Naming in PKIX Certificates 2.3. Subject Naming in PKIX Certificates
In theory, the Internet Public Key Infrastructure using X.509 [PKIX] In theory, the Internet Public Key Infrastructure using X.509 [PKIX]
employs the global directory service model defined in [X.500] and employs the global directory service model defined in [X.500] and
[X.501]. Under that model, information is held in a directory [X.501]. Under that model, information is held in a directory
information base (DIB) and entries in the DIB are organized in a information base (DIB) and entries in the DIB are organized in a
hierarchy called the directory information tree (DIT). An object or hierarchy called the directory information tree (DIT). An object or
alias entry in that hierarchy consists of a set of attributes (each alias entry in that hierarchy consists of a set of attributes (each
of which has a defined type and one or more values) and is uniquely of which has a defined type and one or more values) and is uniquely
skipping to change at page 15, line 50 skipping to change at page 15, line 52
itself (which together comprise the Relative Distinguished Name (RDN) itself (which together comprise the Relative Distinguished Name (RDN)
of the entry, so-called because it is relative to the Distinguished of the entry, so-called because it is relative to the Distinguished
Names of the superior entries in the tree). The entry closest to the Names of the superior entries in the tree). The entry closest to the
root is sometimes referred to as the "most significant" entry and the root is sometimes referred to as the "most significant" entry and the
entry farthest from the root is sometimes referred to as the "least entry farthest from the root is sometimes referred to as the "least
significant" entry. An RDN is a set (i.e., an unordered group) of significant" entry. An RDN is a set (i.e., an unordered group) of
attribute-type-and-value pairs (see also [LDAP-DN]), each of which attribute-type-and-value pairs (see also [LDAP-DN]), each of which
asserts some attribute about the entry. asserts some attribute about the entry.
In practice, the certificates used in [X.509] and [PKIX] borrow key In practice, the certificates used in [X.509] and [PKIX] borrow key
concepts of X.500 and X.501 (e.g., DNs and RDNs) to identify concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify
entities, but such certificates are not necessarily part of a global entities, but such certificates are not necessarily part of a global
directory information base. Specifically, the subject field of a directory information base. Specifically, the subject field of a
PKIX certificate is an X.501 type Name that "identifies the entity PKIX certificate is an X.501 type Name that "identifies the entity
associated with the public key stored in the subject public key associated with the public key stored in the subject public key
field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly
acceptable for the subject field to be empty, as long as the acceptable for the subject field to be empty, as long as the
certificate contains a subjectAltName extension that includes at certificate contains a subject alternative name ("subjectAltName")
least one subjectAltName entry, because the subject alternative name extension that includes at least one subjectAltName entry, because
("subjectAltName") extension allows various identities to be bound to the subjectAltName extension allows various identities to be bound to
the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName
extension itself is a sequence of typed entries, where each type is a extension itself is a sequence of typed entries, where each type is a
distinct kind of identifier. distinct kind of identifier.
For our purposes, an application service is identified by a name or For our purposes, an application service can be identified by a name
names carried in the subject field and/or in one of the following or names carried in the subject field (i.e., a CN-ID) and/or in one
identifier types: of the following identifier types within subjectAltName entries:
o DNS-ID o DNS-ID
o SRV-ID o SRV-ID
o URI-ID o URI-ID
Existing certificates often use a CN-ID in the subject field to Existing certificates often use a CN-ID in the subject field to
represent a fully-qualified DNS domain name; for example, consider represent a fully-qualified DNS domain name; for example, consider
the following three subject names, where the attribute of type Common the following three subject names, where the attribute of type Common
Name contains a string whose form matches that of a fully-qualified Name contains a string whose form matches that of a fully-qualified
DNS domain name ("www.example.com", "mail.example.net", and DNS domain name ("im.example.org", "mail.example.net", and
"im.example.org" respectively): "www.example.com" respectively):
CN=im.example.org,O=Example Org,C=GB CN=im.example.org,O=Example Org,C=GB
C=CA,O=Example Internetworking,CN=mail.example.net C=CA,O=Example Internetworking,CN=mail.example.net
O=Examples-R-Us,CN=www.example.com,C=US O=Examples-R-Us,CN=www.example.com,C=US
However, the Common Name might contain a human-readable string for However, a Common Name might contain a human-friendly string for the
the service, rather than a string whose form matches that of a fully- service, rather than a string whose form matches that of a fully-
qualified DNS domain name: qualified DNS domain name (a certificate with such a single Common
Name will tyupically have at least one subjectAltName entry
containing the fully-qualified DNS domain name):
CN=A Free Chat Service,O=Example Org,C=GB CN=A Free Chat Service,O=Example Org,C=GB
Or, a certificate's subject might contain both a CN-ID as well as
another common name attribute containing a human-friendly string:
CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB
In general, this specification recommends and prefers use of In general, this specification recommends and prefers use of
subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the
subject field (CN-ID) where possible, as more completely described in subject field (CN-ID) where possible, as more completely described in
the following sections. However, profiles of this specification can the following sections. However, specifications that re-use this one
legitimately encourage continued support for the CN-ID identifier can legitimately encourage continued support for the CN-ID identifier
type if they have good reasons to do so, such as backward type if they have good reasons to do so, such as backward
compatibility with deployed infrastructure. compatibility with deployed infrastructure (see, for example,
[EV-CERTS]).
Implementation Note: Confusion sometimes arises from different 2.3.1. Implementation Notes
renderings or encodings of the hierarchical information contained
in a certificate. Certificates are binary objects and are encoded Confusion sometimes arises from different renderings or encodings of
using the Distinguished Encoding Rules (DER) specified in [X.690]. the hierarchical information contained in a certificate.
However, some implementations generate displayable (a.k.a.
printable) renderings of the certificate issuer, subject field, Certificates are binary objects and are encoded using the
and subjectAltName extension, and these renderings convert the Distinguished Encoding Rules (DER) specified in [X.690]. However,
DER-encoded sequences into a "string representation" before being some implementations generate displayable (a.k.a. printable)
displayed. Because a Distinguished Name (DN) is an ordered renderings of the certificate issuer, subject field, and
sequence, order is typically preserved in the DN string subjectAltName extension, and these renderings convert the DER-
representations, although the two most prevalent DN string encoded sequences into a "string representation" before being
representations differ in employing left-to-right vs. right-to- displayed. Because a certificate subject field (of type Name
left ordering. However, because a Relative Distinguished Name [X.509], the same as for a Distinguished Name (DN) [X.501]) is an
(RDN) is an unordered group of attribute-type-and-value pairs, the ordered sequence, order is typically preserved in subject string
string representation of an RDN can differ from the canonical DER representations, although the two most prevalent subject (and DN)
encoding (and the order of attribute-type-and-value pairs can string representations differ in employing left-to-right vs. right-
differ in the RDN string representations or display orders to-left ordering. However, because a Relative Distinguished Name
provided by various implementations). Furthermore, various (RDN) is an unordered group of attribute-type-and-value pairs, the
specifications refer to the order of RDNs using terminology that string representation of an RDN can differ from the canonical DER
is not directly related to the information hierarchy, such as encoding (and the order of attribute-type-and-value pairs can differ
"most specific" vs. "least specific", "left-most" vs. "right- in the RDN string representations or display orders provided by
most", "first" vs. "last", or "most significant" vs. "least various implementations). Furthermore, various specifications refer
significant" (see for example [LDAP-DN]). To reduce confusion, in to the order of RDNs in DNs or certificate subject fields using
this specification we avoid such terms and instead use the terms terminology that is implicitly related to an information hierarchy
provided under Section 1.5; in particular, we do not use the term (which may or may not actually exist), such as "most specific" vs.
"(most specific) Common Name field in the subject field" from "least specific", "left-most" vs. "right-most", "first" vs. "last",
[HTTP-TLS] and instead state that a CN-ID is a Relative or "most significant" vs. "least significant" (see for example
Distinguished Name (RDN) in the certificate subject that contains [LDAP-DN]).
one and only one attribute-type-and-value pair of type Common Name
(thus removing the possibility that an RDN might contain multiple To reduce confusion, in this specification we avoid such terms and
AVAs of type CN, one of which would be considered "most instead use the terms provided under Section 1.5; in particular, we
specific"). Finally, although theoretically some consider the do not use the term "(most specific) Common Name field in the subject
order of AVAs within an RDN to have meaning, in practice that rule field" from [HTTP-TLS] and instead state that a CN-ID is a Relative
is not observed, so we consider an AVA of type CN to be valid at Distinguished Name (RDN) in the certificate subject containing one
any position within the subject field. and only one attribute-type-and-value pair of type Common Name (thus
removing the possibility that an RDN might contain multiple AVAs of
type CN, one of which could be considered "most specific").
Finally, although theoretically some consider the order of RDNs
within a subject field to have meaning, in practice that rule is
often not observed. An AVA of type CN is considered to be valid at
any position within the subject field.
3. Representation of Server Identity 3. Representation of Server Identity
3.1. Rules 3.1. Rules
When a certification authority issues a certificate based on the When a certification authority issues a certificate based on the
fully-qualified DNS domain name at which the application service fully-qualified DNS domain name at which the application service
provider will provide the relevant application, the following rules provider will provide the relevant application, the following rules
apply to the representation of application service identities. apply to the representation of application service identities. The
reader needs to be aware that some of these rules are cumulative and
can interact in important ways that are illustrated later in this
document.
1. The certificate SHOULD include a "DNS-ID" if possible as a 1. The certificate SHOULD include a "DNS-ID" if possible as a
baseline for interoperability. baseline for interoperability.
2. If the service using the certificate deploys a technology in 2. If the service using the certificate deploys a technology in
which a server is discovered by means of DNS SRV records which a server is discovered by means of DNS SRV records
[DNS-SRV] (e.g., this is true of [XMPP]), then the certificate [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
SHOULD include an "SRV-ID". SHOULD include an "SRV-ID".
3. If the service using the certificate deploys a technology in 3. If the service using the certificate deploys a technology in
which a server is typically associated with a URI (e.g., this is which a server is programatically associated with a URI for
true of [SIP]), then the certificate SHOULD include a URI-ID; the security purposes (e.g., this is true of [SIP] as specified by
scheme SHALL be that of the protocol associated with the service [SIP-CERTS], but not true of [HTTP] since [HTTP-TLS] does not
type and the authority component SHALL be the fully-qualified DNS describe usage of a URI-ID for HTTP services), then the
domain name of the service. certificate SHOULD include a URI-ID; the scheme SHALL be that of
the protocol associated with the service type and the "authority"
component SHALL be the fully-qualified DNS domain name of the
service. A specification that re-uses this one MUST specify
which URI schemes are to be considered acceptable in URI-IDs
contained in PKIX certificates used for the application protocol
(e.g., "sip" but not "sips" or "tel" for SIP as described in
[SIP-SIPS], or perhaps http and https for HTTP as might be
described in a future specification).
4. The certificate MAY include other application-specific 4. The certificate MAY include other application-specific
identifiers for types that were defined before publication of identifiers for types that were defined before publication of
[SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names
or URI schemes do not exist; however, such application-specific or URI schemes do not exist; however, such application-specific
identifiers are not applicable to all application technologies identifiers are not applicable to all application technologies
and therefore are out of scope for this specification. and therefore are out of scope for this specification.
5. Even though many deployed clients still check for the CN-ID 5. Even though many deployed clients still check for the CN-ID
within the certificate subject field, the certificate SHOULD NOT within the certificate subject field, the certificate SHOULD NOT
represent the server's fully-qualified DNS domain name in a CN-ID represent the server's fully-qualified DNS domain name in a CN-ID
unless a profile of this specification encourages continued unless a specification that re-uses this one encourages continued
support for the CN-ID identifier type. support for the CN-ID identifier type.
6. The certificate MAY contain more than one DNS-ID, SRV-ID, or 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or
URI-ID (but SHOULD NOT contain more than one CN-ID). URI-ID but SHOULD NOT contain more than one CN-ID, as further
explained under Section 5.4.
7. Unless a profile of this specification allows continued support 7. Unless a specification that re-uses this one allows continued
for the wildcard character '*', the fully-qualified DNS domain support for the wildcard character '*', the DNS domain name
name portion of a presented identifier SHOULD NOT contain the portion of a presented identifier SHOULD NOT contain the wildcard
wildcard character, whether as the complete left-most label character, whether as the complete left-most label within the
within the identifier (following the definition of "label" from identifier (following the definition of "label" from [DNS], e.g.,
[DNS], e.g., "*.example.com") or as a fragment thereof (e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com,
*oo.example.com, f*o.example.com, or foo*.example.com). For f*o.example.com, or foo*.example.com). A more detailed
details, see Section 5.2. discussion of so-called "wildcard certificates" is provided under
Section 5.2.
3.2. Examples 3.2. Examples
A certificate for the website at "www.example.com" might include only Consider a simple website at "www.example.com", which is not
a DNS-ID of "www.example.com" (and, strictly as a fallback for discoverable via DNS SRV lookups. A certificate for this service
existing client software, a CN-ID of "www.example.com"). might include only a DNS-ID of "www.example.com".
A certificate for the IMAP-accessible email server at Consider an IMAP-accessible email server at "mail.example.net"
"mail.example.net" might include SRV-IDs of "_imap.mail.example.net" servicing email addresses of the form "user@example.net" and
and "_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of discoverable via DNS SRV lookups on the "example.net" domain. A
"mail.example.net". certificate for this service might include SRV-IDs of
"_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along
with a DNS-ID of "example.net".
A certificate for the XMPP-compatible instant messaging server at Consider a SIP-accessible voice-over-IP (VoIP) server at
"im.example.org" might include SRV-IDs of "_xmpp- "voice.example.edu" servicing SIP addresses of the form
client.im.example.org" and "_xmpp-server.im.example.org" (see "user@voice.example.edu" and identified by a URI of <sip:
[XMPP]), a DNS-ID of "im.example.org", and an XMPP-specific voice.example.edu>. A certificate for this service would include a
"XmppAddr" of "im.example.org" (see [XMPP]). URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
Consider an XMPP-compatible instant messaging (IM) server at
"im.example.org" servicing IM addresses of the form
"user@im.example.org" and discoverable via DNS SRV lookups on the
"im.example.org" domain. A certificate for this service might
include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp-
server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org",
and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]).
4. Verification of Service Identity 4. Verification of Service Identity
4.1. Overview 4.1. Overview
At a high level, the client verifies the application service's At a high level, the client verifies the application service's
identity by performing the actions listed below (which are defined in identity by performing the actions listed below (which are defined in
the following subsections of this document): the following subsections of this document):
1. The client constructs a list of acceptable reference identifiers 1. The client constructs a list of acceptable reference identifiers
skipping to change at page 20, line 8 skipping to change at page 20, line 47
The client MUST construct a list of acceptable reference identifiers, The client MUST construct a list of acceptable reference identifiers,
and MUST do so independently of the identifiers presented by the and MUST do so independently of the identifiers presented by the
service. service.
The inputs used by the client to construct its list of reference The inputs used by the client to construct its list of reference
identifiers might be a URI that a user has typed into an interface identifiers might be a URI that a user has typed into an interface
(e.g., an HTTPS URL for a web site), configured account information (e.g., an HTTPS URL for a web site), configured account information
(e.g., the domain name of a particular host or URI used for (e.g., the domain name of a particular host or URI used for
retrieving information or connecting to a network, which might be retrieving information or connecting to a network, which might be
different from the server portion of the user's account name), a different from the DNS domain name portion of a username), a
hyperlink in a web page that triggers a browser to retrieve a media hyperlink in a web page that triggers a browser to retrieve a media
object or script, or some other combination of information that can object or script, or some other combination of information that can
yield a source domain and a service type. yield a source domain and a service type.
The client might need to extract the source domain and service type The client might need to extract the source domain and service type
from the input(s) it has received. The extracted data MUST include from the input(s) it has received. The extracted data MUST include
only information that can be securely parsed out of the inputs (e.g., only information that can be securely parsed out of the inputs (e.g.,
extracting the fully-qualified DNS domain name from the authority parsing the fully-qualified DNS domain name out of the "authority"
component of a URI or extracting the service type from the scheme of component of a URI or deriving the service type from the scheme of a
a URI) or information for which the extraction is performed in a URI) or information that is derived in a manner not subject to
manner that is not subject to subversion by network attackers (e.g., subversion by network attackers (e.g., pulling the data from a
pulling the data from a delegated domain that is explicitly delegated domain that is explicitly established via client or system
established via client or system configuration, resolving the data configuration, resolving the data via [DNSSEC], or obtaining the data
via [DNSSEC], or obtaining the data from a third-party domain mapping from a third-party domain mapping service in which a human user has
service in which a human user has explicitly placed trust and with explicitly placed trust and with which the client communicates over a
which the client communicates over a connection that provides both connection or association that provides both mutual authentication
mutual authentication and integrity checking). and integrity checking). These considerations apply only to
extraction of the source domain from the inputs; naturally, if the
inputs themselves are invalid or corrupt (e.g., a user has clicked a
link provided by a malicious entity in a phishing attack), then the
client might end up communicating with an unexpected application
service.
Example: Given an input URI of <sips:alice@example.net>, a client
would derive the service type "sip" from the "scheme" and parse
the domain name "example.net" from the "authority" component.
Each reference identifier in the list SHOULD be based on the source Each reference identifier in the list SHOULD be based on the source
domain and SHOULD NOT be based on a derived domain (e.g., a host name domain and SHOULD NOT be based on a derived domain (e.g., a host name
or domain name discovered through DNS resolution of the source or domain name discovered through DNS resolution of the source
domain). This rule is important because only a match between the domain). This rule is important because only a match between the
user inputs and a presented identifier enables the client to be sure user inputs and a presented identifier enables the client to be sure
that the certificate can legitimately be used to secure the that the certificate can legitimately be used to secure the client's
connection. There is only one scenario in which it is acceptable for communication with the server. There is only one scenario in which
an interactive client to override the recommendation in this rule and it is acceptable for an interactive client to override the
therefore connect to a domain name other than the source domain: recommendation in this rule and therefore communicate with a domain
because a human user has "pinned" the application service's name other than the source domain: because a human user has "pinned"
certificate to the alternative domain name as further discussed under the application service's certificate to the alternative domain name
Section 4.6.4 and Section 5.1. In this case, the inputs used by the as further discussed under Section 4.6.4 and Section 5.1. In this
client to construct its list of reference identifiers might include case, the inputs used by the client to construct its list of
more than one fully-qualified DNS domain name, i.e., both (a) the reference identifiers might include more than one fully-qualified DNS
source domain and (b) the alternative domain contained in the pinned domain name, i.e., both (a) the source domain and (b) the alternative
certificate. domain contained in the pinned certificate.
Using the combination of fully-qualified DNS domain name(s) and Using the combination of fully-qualified DNS domain name(s) and
service type, the client constructs a list of reference identifiers service type, the client constructs a list of reference identifiers
in accordance with the following rules: in accordance with the following rules:
o The list MUST include a DNS-ID. A reference identifier of type o The list MUST include a DNS-ID. A reference identifier of type
DNS-ID can be directly constructed from a fully-qualified DNS DNS-ID can be directly constructed from a fully-qualified DNS
domain name that is (a) contained in or securely derived from the domain name that is (a) contained in or securely derived from the
inputs (i.e., the source domain), or (b) explicitly associated inputs (i.e., the source domain), or (b) explicitly associated
with the source domain by means of user configuration (i.e., a with the source domain by means of user configuration (i.e., a
derived domain). derived domain).
o If a server for the service type is typically discovered by means o If a server for the service type is typically discovered by means
of DNS SRV records, then the list SHOULD include an SRV-ID. of DNS SRV records, then the list SHOULD include an SRV-ID.
o If a server for the service type is typically associated with a o If a server for the service type is typically associated with a
URI, then the list SHOULD include a URI-ID. URI for security purposes, then the list SHOULD include a URI-ID.
o The list MAY include a CN-ID, mainly for the sake of backward o The list MAY include a CN-ID, mainly for the sake of backward
compatibility with existing infrastructure. compatibility with deployed infrastructure.
The client does not need to construct the foregoing identifiers in The client does not need to construct the foregoing identifiers in
the actual formats found in a certificate (e.g., as ASN.1 types), it the actual formats found in a certificate (e.g., as ASN.1 types); it
only needs to construct the functional equivalent of such identifiers only needs to construct the functional equivalent of such identifiers
for matching purposes. for matching purposes.
Security Note: A client MUST NOT construct a reference identifier Security Warning: A client MUST NOT construct a reference
corresponding to Relative Distinguished Names (RDNs) other than identifier corresponding to Relative Distinguished Names (RDNs)
those of type Common Name and MUST NOT check for RDNs other than other than those of type Common Name and MUST NOT check for RDNs
those of type Common Name in the presented identifiers. other than those of type Common Name in the presented identifiers.
4.2.2. Examples 4.2.2. Examples
A web browser that is connecting via HTTPS to the website at A web browser that is connecting via HTTPS to the website at
"www.example.com" might have two reference identifiers: a DNS-ID of "www.example.com" might have two reference identifiers: a DNS-ID of
"www.example.com" and, as a fallback, a CN-ID of "www.example.com". "www.example.com" and, as a fallback, a CN-ID of "www.example.com".
A mail user agent that is connecting via IMAP to the email service at A mail user agent that is connecting via IMAP to the email service at
"mail.example.net" might have two reference identifiers: an SRV-ID of "example.net" (resolved as "mail.example.net") might have two
"_imaps.mail.example.net" (see [EMAIL-SRV]) and a DNS-ID of reference identifiers: an SRV-ID of "_imaps.example.net" (see
"mail.example.net". [EMAIL-SRV]) and a DNS-ID of "example.net".
A voice-over-IP (VoIP) user agent that is connecting via SIP to the
voice service at "voice.example.edu" might have only one reference
identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
An instant messaging (IM) client that is connecting via XMPP to the An instant messaging (IM) client that is connecting via XMPP to the
IM service at "im.example.org" might have three reference IM service at "im.example.org" might have three reference
identifiers: an SRV-ID of "_xmpp.im.example.org", a DNS-ID of identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]),
"im.example.org", and an XMPP-specific "XmppAddr" of "im.example.org" a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of
(see [XMPP]). "im.example.org" (see [XMPP]).
4.3. Preparing to Seeking a Match 4.3. Preparing to Seek a Match
Once the client has constructed its list of reference identifiers and Once the client has constructed its list of reference identifiers and
has received the server's presented identifiers in the form of a PKIX has received the server's presented identifiers in the form of a PKIX
certificate, the client checks its reference identifiers against the certificate, the client checks its reference identifiers against the
presented identifiers for the purpose of finding a match. The search presented identifiers for the purpose of finding a match. The search
fails if the client exhausts its list of reference identifiers fails if the client exhausts its list of reference identifiers
without finding a match. The search succeeds if any presented without finding a match. The search succeeds if any presented
identifier matches one of the reference identifiers, at which point identifier matches one of the reference identifiers, at which point
the client SHOULD stop the search. the client SHOULD stop the search.
Implementation Note: A client might be configured to perform Implementation Note: A client might be configured to perform
multiple searches, i.e., to match more than one reference multiple searches, i.e., to match more than one reference
identifier; although such behavior is not forbidden by this identifier; although such behavior is not forbidden by this
document, rules for matching multiple reference identifiers are a specification, rules for matching multiple reference identifiers
matter for implementation or future specification. are a matter for implementation or future specification.
Security Note: A client MUST NOT seek a match for a reference Security Warning: A client MUST NOT seek a match for a reference
identifier of CN-ID if the presented identifiers include a DNS-ID, identifier of CN-ID if the presented identifiers include a DNS-ID,
SRV-ID, URI-ID, or any application-specific identifier types SRV-ID, URI-ID, or any application-specific identifier types
supported by the client. supported by the client.
Before applying the comparison rules provided in the following Before applying the comparison rules provided in the following
sections, the client might need to split the reference identifier sections, the client might need to split the reference identifier
into its DNS domain name portion and its application type portion, as into its DNS domain name portion and its service type portion, as
follows: follows:
o A reference identifier of type DNS-ID does not include an o A reference identifier of type DNS-ID does not include a service
application type portion and thus can be used directly as the DNS type portion and thus can be used directly as the DNS domain name
domain name for comparison purposes. for comparison purposes. As an example, a DNS-ID of
"www.example.com" would result in a DNS domain name portion of
"www.example.com".
o A reference identifier of type CN-ID also does not include an o A reference identifier of type CN-ID also does not include a
application type portion and thus can be used directly as the DNS service type portion and thus can be used directly as the DNS
domain name for comparison purposes; note that this document domain name for comparison purposes. As previously mentioned,
specifies that a CN-ID always contains a string whose form matches this document specifies that a CN-ID always contains a string
that of a DNS domain name (thus differentiating a CN-ID from a whose form matches that of a DNS domain name (thus differentiating
Common Name containing a human-friendly name). a CN-ID from a Common Name containing a human-friendly name).
o For a reference identifier of type SRV-ID, the DNS domain name o For a reference identifier of type SRV-ID, the DNS domain name
portion is the Name and the application type portion is the portion is the Name and the service type portion is the Service.
Service. As an example, an SRV-ID of "_imaps.example.net" would be split
into a DNS domain name portion of "example.net" and a service type
portion of "imaps" (mapping to an application protocol of IMAP as
explained in [EMAIL-SRV]).
o For a reference identifier of type URI-ID, the DNS domain name o For a reference identifier of type URI-ID, the DNS domain name
portion is the reg-name part of the authority component and the portion is the "reg-name" part of the "authority" component and
application type portion is the scheme name matching the [ABNF] the service type portion is the service type associated with the
"scheme" rule from [URI] (not including the ':' separator); note scheme name matching the [ABNF] "scheme" rule from [URI] (not
that this document specifies that a URI-ID always contains an including the ':' separator). As previously mentioned, this
authority component whose host subcomponent contains a reg-name document specifies that a URI-ID always contains an "authority"
(thus differentiating a URI-ID from a uniformResourceIdentifier component whose "host" subcomponent contains a "reg-name".
entry that contains an IP address or that does not contain an
authority component), and that extraction of the reg-name might (Matching only the "reg-name" rule from [URI] limits verification
necessitate normalization of the URI (as explained in [URI]). to DNS domain names, thereby differentiating a URI-ID from a
uniformResourceIdentifier entry that contains an IP address or a
mere host name, or that does not contain an "authority" component
at all.). Furthermore, note that extraction of the "reg-name"
might necessitate normalization of the URI (as explained in
[URI]). As an example, a URI-ID of "sip:voice.example.edu" would
be split into a DNS domain name portion of "voice.example.edu" and
a service type of "sip" (associated with an application protocol
of SIP as explained in [SIP-CERTS]).
Detailed comparison rules for matching the DNS domain name portion Detailed comparison rules for matching the DNS domain name portion
and application type portion of the reference identifier are provided and service type portion of the reference identifier are provided in
in the following sections. the following sections.
4.4. Verifying the DNS Domain Name Portion 4.4. Matching the DNS Domain Name Portion
The client MUST match the DNS domain name portion of a reference The client MUST match the DNS domain name portion of a reference
identifier according to the following rules (and SHOULD also check identifier according to the following rules (and SHOULD also check
the service type as described under Section 4.5). The rules differ the service type as described under Section 4.5). The rules differ
depending on whether the domain to be checked is a "traditional depending on whether the domain to be checked is a "traditional
domain name" or an "internationalized domain name" (as defined under domain name" or an "internationalized domain name" (as defined under
Section 2.2). Furthermore, if the client supports presented Section 2.2). Furthermore, to meet the needs of clients that support
identifiers that contain the wildcard character '*', we define a presented identifiers containing the wildcard character '*', we
supplemental rule for so-called "wildcard certificates". We also define a supplemental rule for so-called "wildcard certificates".
specify the circumstances under which it is acceptable to check the Finally, we also specify the circumstances under which it is
"CN-ID" identifier type. acceptable to check the "CN-ID" identifier type.
4.4.1. Checking of Traditional Domain Names 4.4.1. Checking of Traditional Domain Names
If the DNS domain name portion of a reference identifier is a If the DNS domain name portion of a reference identifier is a
"traditional domain name", then matching of the reference identifier "traditional domain name", then matching of the reference identifier
against the presented identifier is performed by comparing the set of against the presented identifier is performed by comparing the set of
domain name components using a case-insensitive ASCII comparison, as domain name labels using a case-insensitive ASCII comparison, as
clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
to "www.example.com" for comparison purposes). Each label MUST match to "www.example.com" for comparison purposes). Each label MUST match
in order for the names to be considered to match, except as in order for the names to be considered to match, except as
supplemented by the rule about checking of wildcard labels supplemented by the rule about checking of wildcard labels
(Section 4.4.3). (Section 4.4.3).
4.4.2. Checking of Internationalized Domain Names 4.4.2. Checking of Internationalized Domain Names
If the DNS domain name portion of a reference identifier is an If the DNS domain name portion of a reference identifier is an
internationalized domain name, then an implementation MUST convert internationalized domain name, then an implementation MUST convert
every label in the domain name to an A-label (as described in any U-labels [IDNA-DEFS] in the domain name to A-labels before
[IDNA-DEFS]) before checking the domain name. In accordance with checking the domain name. In accordance with [IDNA-PROTO], A-labels
[IDNA-PROTO], a pair of A-labels MUST be compared as case-insensitive MUST be compared as case-insensitive ASCII. Each label MUST match in
ASCII. Each label MUST match in order for the names to be considered order for the domain names to be considered to match, except as
to match, except as supplemented by the rule about checking of supplemented by the rule about checking of wildcard labels
wildcard labels (Section 4.4.3). (Section 4.4.3; but see also Section 5.2 regarding wildcards in
internationalized domain names).
4.4.3. Checking of Wildcard Certificates 4.4.3. Checking of Wildcard Certificates
A client employing this specification's rules MAY match the reference A client employing this specification's rules MAY match the reference
identifier against a presented identifier whose DNS domain name identifier against a presented identifier whose DNS domain name
portion contains the wildcard character '*' as part or all of a label portion contains the wildcard character '*' as part or all of a label
(following the definition of "label" from [DNS]). For information (following the definition of "label" from [DNS-CONCEPTS]).
regarding the security characteristics of wildcard certificates, see
Section 5.2. For information regarding the security characteristics of wildcard
certificates, see Section 5.2.
If a client matches the reference identifier against a presented If a client matches the reference identifier against a presented
identifier whose DNS domain name portion contains the wildcard identifier whose DNS domain name portion contains the wildcard
character '*', the following rules apply: character '*', the following rules apply:
1. The client SHOULD NOT attempt to match a presented identifier in 1. The client SHOULD NOT attempt to match a presented identifier in
which the wildcard character comprises a label other than the which the wildcard character comprises a label other than the
left-most label (e.g., do not match bar.*.example.net). left-most label (e.g., do not match bar.*.example.net).
2. If the wildcard character is the only character of the left-most 2. If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com). not bar.foo.example.com or example.com).
3. The client MAY match a presented identifier in which the wildcard 3. The client MAY match a presented identifier in which the wildcard
character is not the only character of the label (e.g., character is not the only character of the label (e.g.,
baz*.example.net and *baz.example.net and b*z.example.net would baz*.example.net and *baz.example.net and b*z.example.net would
be taken to match baz1.example.net and foobaz.example.net and be taken to match baz1.example.net and foobaz.example.net and
buzz.example.net, respectively). buzz.example.net, respectively). However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard
character is embedded within an A-label or U-label [IDNA-DEFS] of
an internationalized domain name [IDNA-PROTO].
4.4.4. Checking of Common Names 4.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
URI-ID, or any application-specific identifier types supported by the URI-ID, or any application-specific identifier types supported by the
client. client.
Therefore, if and only if the presented identifiers do not include a Therefore, if and only if the presented identifiers do not include a
DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
supported by the client, then the client MAY as a last resort check supported by the client, then the client MAY as a last resort check
for a string whose form matches that of a fully-qualified DNS domain for a string whose form matches that of a fully-qualified DNS domain
name in the CN-ID. If the client chooses to compare a reference name in a Common Name field of the subject field (i.e., a CN-ID). If
identifier of type CN-ID against that string, it MUST follow the the client chooses to compare a reference identifier of type CN-ID
comparison rules for the DNS domain name portion of an identifier of against that string, it MUST follow the comparison rules for the DNS
type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4.1, domain name portion of an identifier of type DNS-ID, SRV-ID, or
Section 4.4.2, and Section 4.4.3. URI-ID, as described under Section 4.4.1, Section 4.4.2, and
Section 4.4.3.
4.5. Verifying the Application Type Portion 4.5. Matching the Application Type Portion
When checking identifiers of type SRV-ID and URI-ID, a client SHOULD When checking identifiers of type SRV-ID and URI-ID, a client SHOULD
check not only the domain name but also the service type of the check not only the domain name but also the service type of the
service to which it connects. This is a best practice because application service with which it communicates. This is a best
typically a client is not designed to connect to all kinds of practice because typically a client is not designed to communicate
services using all possible application protocols, but instead is with all kinds of services using all possible application protocols,
designed to connect to one kind of service, such as websites, email but instead is designed to communicate with one kind of service, such
services, or instant messaging services. as websites, email services, VoIP services, or IM services.
The service type is verified by means of either an SRV-ID or URI-ID. The service type is verified by means of an SRV-ID or a URI-ID.
4.5.1. SRV-ID 4.5.1. SRV-ID
The service name portion of an SRV-ID (e.g., "xmpp") MUST be matched The service name portion of an SRV-ID (e.g., "imaps") MUST be matched
in a case-insensitive manner, in accordance with [DNS-SRV]. Note in a case-insensitive manner, in accordance with [DNS-SRV]. Note
that the "_" character is prepended to the service identifier in DNS that the "_" character is prepended to the service identifier in DNS
SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to
be included in any comparison. be included in any comparison.
4.5.2. URI-ID 4.5.2. URI-ID
The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in
a case-insensitive manner, in accordance with [URI]. Note that the a case-insensitive manner, in accordance with [URI]. Note that the
":" character is a separator between the scheme name and the rest of ":" character is a separator between the scheme name and the rest of
the URI, and thus does not need to be included in any comparison. the URI, and thus does not need to be included in any comparison.
4.6. Outcome 4.6. Outcome
The outcome of the checking procedure is one of the following cases. The outcome of the matching procedure is one of the following cases.
4.6.1. Case #1: Match Found 4.6.1. Case #1: Match Found
If the client has found a presented identifier that matches a If the client has found a presented identifier that matches a
reference identifier, matching has succeeded. In this case, the reference identifier, then the service identity check has succeeded.
client MUST use the matched reference identifier as the validated In this case, the client MUST use the matched reference identifier as
identity of the application service. the validated identity of the application service.
4.6.2. Case #2: No Match Found, Pinned Certificate 4.6.2. Case #2: No Match Found, Pinned Certificate
If the client does not find a presented identifier matching any of If the client does not find a presented identifier matching any of
the reference identifiers but the client has previously pinned the the reference identifiers but the client has previously pinned the
application service's certificate to one of the reference identifiers application service's certificate to one of the reference identifiers
in the list it constructed for this connection attempt (as "pinning" in the list it constructed for this communication attempt (as
is explained under Section 1.5), and the presented certificate "pinning" is explained under Section 1.5), and the presented
matches the pinned certificate (including the context as described certificate matches the pinned certificate (including the context as
under Section 5.1), then the service identity check succeeds. described under Section 5.1), then the service identity check has
succeeded.
4.6.3. Case #3: No Match Found, No Pinned Certificate 4.6.3. Case #3: No Match Found, No Pinned Certificate
If the client does not find a presented identifier matching any of If the client does not find a presented identifier matching any of
the reference identifiers and the client has not previously pinned the reference identifiers and the client has not previously pinned
the certificate to one of the reference identifiers in the list it the certificate to one of the reference identifiers in the list it
constructed for this connection attempt, then the client MUST proceed constructed for this communication attempt, then the client MUST
as described under Section 4.6.4. proceed as described under Section 4.6.4.
4.6.4. Fallback 4.6.4. Fallback
If the client is an interactive client that is directly controlled by If the client is an interactive client that is directly controlled by
a human user, then it SHOULD inform the user of the identity mismatch a human user, then it SHOULD inform the user of the identity mismatch
and automatically terminate the connection with a bad certificate and automatically terminate the communication attempt with a bad
error; this behavior is preferable because it prevents users from certificate error; this behavior is preferable because it prevents
inadvertently bypassing security protections in hostile situations. users from inadvertently bypassing security protections in hostile
situations.
Security Note: Some interactive clients give advanced users the Security Warning: Some interactive clients give advanced users the
option of proceeding with acceptance despite the identity option of proceeding with acceptance despite the identity
mismatch, thereby "pinning" the certificate to one of the mismatch, thereby "pinning" the certificate to one of the
reference identifiers in the list constructed by the client for reference identifiers in the list constructed by the client for
this connection attempt. Although this behavior can be this communication attempt. Although this behavior can be
appropriate in certain specialized circumstances, in general it appropriate in certain specialized circumstances, in general it
ought to be exposed only to advanced users. Even then it needs to ought to be exposed only to advanced users. Even then it needs to
be handled with extreme caution, for example by first encouraging be handled with extreme caution, for example by first encouraging
even an advanced user to terminate the connection and, if the even an advanced user to terminate the communication attempt and,
advanced user chooses to proceed anyway, by forcing the user to if the advanced user chooses to proceed anyway, by forcing the
view the entire certification path and only then allowing the user user to view the entire certification path and only then allowing
to pin the certificate (on a temporary or permanent basis, at the the user to pin the certificate (on a temporary or permanent
user's option). basis, at the user's option).
Otherwise, if the client is an automated application not directly Otherwise, if the client is an automated application not directly
controlled by a human user, then it SHOULD terminate the connection controlled by a human user, then it SHOULD terminate the
with a bad certificate error and log the error appropriately. An communication attempt with a bad certificate error and log the error
automated application MAY provide a configuration setting that appropriately. An automated application MAY provide a configuration
disables this behavior, but MUST enable the behavior by default. setting that disables this behavior, but MUST enable the behavior by
default.
5. Security Considerations 5. Security Considerations
5.1. Pinned Certificates 5.1. Pinned Certificates
As defined under Section 1.5, a certificate is said to be "pinned" to As defined under Section 1.5, a certificate is said to be "pinned" to
a DNS domain name when a user has explicitly chosen to associate a a DNS domain name when a user has explicitly chosen to associate a
service's certificate with the that domain name despite the fact that service's certificate with that DNS domain name despite the fact that
the certificate contains some other DNS domain name (e.g., the user the certificate contains some other DNS domain name (e.g., the user
has explicitly approved "apps.example.net" as a domain associated has explicitly approved "apps.example.net" as a domain associated
with a source domain of "example.com"). The cached name association with a source domain of "example.com"). The cached name association
MUST take account of both the certificate presented and the context MUST take account of both the certificate presented and the context
in which it was accepted or configured (where the "context" includes in which it was accepted or configured (where the "context" includes
the chain of certificates from the presented certificate to the trust the chain of certificates from the presented certificate to the trust
anchor, the source domain, the service type, the service's derived anchor, the source domain, the service type, the service's derived
domain and port number, and any other relevant information provided domain and port number, and any other relevant information provided
by the user or associated by the client). by the user or associated by the client).
5.2. Wildcard Certificates 5.2. Wildcard Certificates
This document states that the wildcard character '*' SHOULD NOT be This document states that the wildcard character '*' SHOULD NOT be
included in presented identifiers but MAY be checked by application included in presented identifiers but MAY be checked by application
clients (mainly for the sake of backward compatibility with existing clients (mainly for the sake of backward compatibility with deployed
infrastructure); as a result, the rules provided in this document are infrastructure); as a result, the rules provided in this document are
more restrictive than the rules for many existing application more restrictive than the rules for many existing application
technologies (see Appendix A). Several security considerations technologies (such as those excerpted under Appendix A). Several
justify tightening the rules: security considerations justify tightening the rules:
o The inclusion of the wildcard character in certificates has led to
homograph attacks involving non-ASCII characters that look similar
to characters commonly included in HTTPS URLs, such as "/" and
"?"; for discussion, see for example [Defeating-SSL] (beginning at
slide 91).
o The ability to obtain a certificate containing the wildcard o Wildcard certificates automatically vouch for any and all host
character might broaden the range of applications services that an names within their domain. This can be convenient for
attacker could forge, thus increasing (a) the chances that administrators but also poses the risk of vouching for rogue or
attackers would attempt to steal credentials needed for obtaining buggy hosts. See for example [Defeating-SSL] (beginning at slide
certificates and (b) the potential damage that would result from a 91) and [HTTPSbytes] (slides 38-40).
successful attack.
o Specifications for existing application technologies are not clear o Specifications for existing application technologies are not clear
about whether the wildcard character is allowed only as the or consistent about the allowable location of the wildcard
complete left-most label (e.g., *.example.com), some fragment of character, such as whether it can be:
the left-most label (e.g., foo*.example.com, f*o.example.com, or
*oo.example.com), or even all or part of a label other than the
left-most label (e.g., www.*.example.com or www.foo*.example.com);
nor are they clear about whether a presented identifier can
include more than one instance of the wildcard character (e.g.,
f*b*r.example.com or *.*.example.com). These ambiguities might
introduce exploitable differences in identity checking behavior
among client implementations and necessitate overly complex and
inefficient identity checking algorithms.
Notwithstanding the foregoing security considerations, profiles of * only the complete left-most label (e.g., *.example.com)
this specification can legitimately encourage continued support for
* some fragment of the left-most label (e.g., foo*.example.com,
f*o.example.com, or *oo.example.com)
* all or part of a label other than the left-most label (e.g.,
www.*.example.com or www.foo*.example.com)
* all or part of a label that identifies a so-called "public
suffix" (e.g., *.co.uk or *.com)
* included more than once in a given label (e.g.,
f*b*r.example.com
* included as all or part of more than one label (e.g.,
*.*.example.com)
These ambiguities might introduce exploitable differences in
identity checking behavior among client implementations and
necessitate overly complex and inefficient identity checking
algorithms.
o There is no specification that defines how the wildcard character
may be embedded within the A-labels or U-labels [IDNA-DEFS] of an
internationalized domain name [IDNA-PROTO]; as a result,
implementations are strongly discouraged from including or
attempting to check for the wildcard character emdedded within
A-labels and/or U-labels of an internationalized domain name.
Note, however, that a presented domain name identifier MAY contain
the wildcard character where it occupies the entire leftmost label
position, and where some or all of the remaining labels are
A-labels or U-labels.
Notwithstanding the foregoing security considerations, specifications
that re-use this one can legitimately encourage continued support for
the wildcard character if they have good reasons to do so, such as the wildcard character if they have good reasons to do so, such as
backward compatibility with deployed infrastructure. backward compatibility with deployed infrastructure (see, for
example, [EV-CERTS]).
5.3. Internationalized Domain Names 5.3. Internationalized Domain Names
Allowing internationalized domain names can lead to the inclusion of Allowing internationalized domain names can lead to the inclusion of
visually similar (so-called "confusable") characters in certificates; visually similar (so-called "confusable") characters in certificates;
for discussion, see for example [IDNA-DEFS]. for discussion, see for example [IDNA-DEFS].
5.4. Multiple Identifiers
A given application service might be addressed by multiple DNS domain
names for a variety of reasons, and a given deployment might service
multiple domains (e.g., in so-called "virtual hosting" environments).
In the default TLS handshake exchange, the client is not able to
indicate the DNS domain name with which it wants to communicate, and
the TLS server returns only one certificate for itself. Absent an
extension to TLS, a typical workaround used to facilitate mapping an
application service to multiple DNS domain names is to embed all of
the domain names into a single certificate.
A more recent approach, formally specified in [TLS-EXT], is for the
client to use the TLS "Server Name Indication" (SNI) extension when
sending the client_hello message, stipulating the DNS domain name it
desires or expects of the service. The service can then return the
appropriate certificate in its Certificate message, and that
certificate can represent a single DNS domain name.
To accommodate the workaround that was needed before the development
of the SNI extension, this specification allows multiple DNS-IDs,
SRV-IDs, or URI-IDs in a certificate; however, it explicitly
discourages multiple CN-IDs. Although it would be preferable to
forbid multiple CN-IDs entirely, there are several reasons at this
time why this specification states that they SHOULD NOT (instead of
MUST NOT) be included:
o At least one significant technology community of interest
explicitly allows multiple CN-IDs [EV-CERTS].
o At least one significant certification authority is known to issue
certificates containing multiple CN-IDs.
o Many service providers often deem inclusion of multiple CN-IDs
necessary in virtual hosting environments because at least one
widely-deployed operating system does not yet support the SNI
extension.
It is hoped that the recommendation regarding multiple CN-IDs can be
further tightened in the future.
6. IANA Considerations 6. IANA Considerations
This document specifies no actions for the IANA. This document specifies no actions for the IANA.
7. References 7. Contributors
7.1. Normative References
The following individuals made important contributions to the text of
this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
8. Acknowledgements
The editors and contributors wish to thank the following individuals
for their feedback and suggestions: Bernard Aboba, Richard Barnes,
Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott
Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus
Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno
Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love
Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Simon
Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt
McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig
Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert
Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan
Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew
Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner,
Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.
Thanks also to Barry Leiba and Ben Campbell for their reviews on
behalf of the Security Directorate and the General Area Review Team,
respectively.
The responsible Area Director was Alexey Melnikov.
9. References
9.1. Normative References
[DNS] Mockapetris, P., "Domain names - implementation and [DNS] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[DNS-CONCEPTS] [DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities", Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
skipping to change at page 28, line 47 skipping to change at page 32, line 16
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007. RFC 4985, August 2007.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
7.2. Informative References 9.2. Informative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[HTTPSbytes]
Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu
Dhabi, November 2010, <https://media.blackhat.com/
bh-ad-10/Hansen/
Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-
slides.pdf>.
[Defeating-SSL] [Defeating-SSL]
Marlinspike, M., "New Tricks for Defeating SSL in Marlinspike, M., "New Tricks for Defeating SSL in
Practice", February 2009, <http://www.blackhat.com/ Practice", BlackHat DC, February 2009, <http://
presentations/bh-dc-09/Marlinspike/ www.blackhat.com/presentations/bh-dc-09/Marlinspike/
BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>. BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
[DNS-CASE] [DNS-CASE]
Eastlake, D., "Domain Name System (DNS) Case Insensitivity Eastlake, D., "Domain Name System (DNS) Case Insensitivity
Clarification", RFC 4343, January 2006. Clarification", RFC 4343, January 2006.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
skipping to change at page 31, line 42 skipping to change at page 35, line 17
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[SIP-CERTS] [SIP-CERTS]
Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010. RFC 5922, June 2010.
[SIP-SIPS]
Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[SMTP-AUTH] [SMTP-AUTH]
Siemborski, R. and A. Melnikov, "SMTP Service Extension Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007. for Authentication", RFC 4954, July 2007.
[SMTP-TLS] [SMTP-TLS]
Hoffman, P., "SMTP Service Extension for Secure SMTP over Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
skipping to change at page 32, line 30 skipping to change at page 36, line 9
Mapping for Syslog", RFC 6012, October 2010. Mapping for Syslog", RFC 6012, October 2010.
[SYSLOG-TLS] [SYSLOG-TLS]
Miao, F., Ma, Y., and J. Salowey, "Transport Layer Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425, Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009. March 2009.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", draft-ietf-tls-rfc4366-bis-12
(work in progress), September 2010.
[US-ASCII] [US-ASCII]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[USINGTLS] [USINGTLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User
skipping to change at page 41, line 10 skipping to change at page 44, line 43
including the entire certification path. The peer MUST cache the including the entire certification path. The peer MUST cache the
certificate (or some non-forgeable representation such as a certificate (or some non-forgeable representation such as a
hash). In future connections, the peer MUST verify that the same hash). In future connections, the peer MUST verify that the same
certificate was presented and MUST notify the user if it has certificate was presented and MUST notify the user if it has
changed. changed.
In Case #2 and Case #3, implementations SHOULD act as in (2) above. In Case #2 and Case #3, implementations SHOULD act as in (2) above.
###### ######
At the time of this writing, [XMPP] refers to this document for rules Although [XMPP-OLD] defined its own rules, [XMPP] re-uses the rules
regarding application service identity verification in XMPP. in this document regarding application service identity verification
in XMPP.
A.6. NNTP (2006) A.6. NNTP (2006)
In 2006, [NNTP-TLS] specified the following text regarding In 2006, [NNTP-TLS] specified the following text regarding
application service identity verification in NNTP: application service identity verification in NNTP:
###### ######
5. Security Considerations 5. Security Considerations
[...] [...]
During the TLS negotiation, the client MUST check its understanding During the TLS negotiation, the client MUST check its understanding
of the server hostname against the server's identity as presented in of the server hostname against the server's identity as presented in
the server Certificate message, in order to prevent man-in-the-middle the server Certificate message, in order to prevent man-in-the-middle
attacks. Matching is performed according to these rules: attacks. Matching is performed according to these rules:
o The client MUST use the server hostname it used to open the o The client MUST use the server hostname it used to open the
 End of changes. 114 change blocks. 
427 lines changed or deleted 603 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/