draft-saintandre-tls-server-id-check-07.txt   draft-saintandre-tls-server-id-check-08.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: BCP J. Hodges Intended status: BCP J. Hodges
Expires: January 1, 2011 PayPal Expires: January 13, 2011 PayPal
June 30, 2010 July 12, 2010
Representation and Verification of Domain-Based Application Server Representation and Verification of Domain-Based Application Service
Identity in Certificates Used with Transport Layer Security Identity in Certificates Used with Transport Layer Security
draft-saintandre-tls-server-id-check-07 draft-saintandre-tls-server-id-check-08
Abstract Abstract
Many application technologies enable a secure connection between two Many application technologies enable a secure connection between two
entities using certificates in the context of Transport Layer entities using certificates in the context of Transport Layer
Security (TLS). This document specifies best current practices for Security (TLS). This document specifies best current practices for
representing and verifying the identity of application servers in representing and verifying the identity of application services in
such interactions. 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 January 1, 2011. This Internet-Draft will expire on January 13, 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 15 skipping to change at page 2, line 15
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 10
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 10
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Naming Applications . . . . . . . . . . . . . . . . . . . 10 2.1. Naming Application Services . . . . . . . . . . . . . . . 10
2.2. Subject Naming in PKIX Certificates . . . . . . . . . . . 11 2.2. Subject Naming in PKIX Certificates . . . . . . . . . . . 12
3. Representation of Server Identity . . . . . . . . . . . . . . 12 3. Representation of Server Identity . . . . . . . . . . . . . . 13
4. Verification of Server Identity . . . . . . . . . . . . . . . 13 4. Verification of Server Identity . . . . . . . . . . . . . . . 15
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Constructing an Ordered List of Reference Identifiers . . 14 4.2. Constructing an Ordered List of Reference Identifiers . . 15
4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 16 4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 17
4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 16 4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 18
4.4.1. Checking of Traditional Domain Names . . . . . . . . . 16 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 18
4.4.2. Checking of Internationalized Domain Names . . . . . . 17 4.4.2. Checking of Internationalized Domain Names . . . . . . 18
4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 17 4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 18
4.4.4. Checking of DNS Domain Names in Common Names . . . . . 18 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 19
4.5. Verifying an Application Type . . . . . . . . . . . . . . 18 4.5. Verifying an Application Type . . . . . . . . . . . . . . 19
4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 19 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 20
4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 19 4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 20
4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 19 4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 20
4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 20 4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 21
4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 20 4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 21 5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 22
5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 21 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 22
5.3. Internationalized Domain Names . . . . . . . . . . . . . . 21 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 27
A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 26 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 28
A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 27 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 28 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 30
A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 31 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 33
A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 33 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 34 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 35
A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 35 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 36
A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 36 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 38
A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 37 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 39
A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 38 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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 consists of services that employ a
client-server architecture in which an interactive or automated client-server architecture in which an interactive or automated
client connects to an application server in order to retrieve or client connects to an application services in order to retrieve or
upload information, communicate with other entities, or access a upload information, communicate with other entities, or access a
broader network of services. When a client connects to an broader network of services. When a client connects to an
application server using Transport Layer Security [TLS] (or, less application services using Transport Layer Security [TLS] (or, less
commonly, [DTLS]), it references some conception of the server's commonly, [DTLS]), it references some conception of the server's
identity while attempting to establish a secure connection (e.g., identity while attempting to establish a secure connection (e.g.,
"the web site at example.com"). Likewise, during TLS negotiation the "the web site at example.com"). Likewise, during TLS negotiation the
server presents its conception of the server's identity in the form server presents its conception of the server's identity in the form
of a public-key certificate that was issued by a certification of a public-key certificate that was issued by a certification
authority (CA) in the context of the Internet Public Key authority (CA) in the context of the Internet Public Key
Infrastructure using X.509 [PKIX]. Informally, we can think of these Infrastructure using X.509 [PKIX]. Informally, we can think of these
identities as the client's "reference identity" and the server's identities as the client's "reference identity" and the server's
"presented identity" (these rough ideas are defined more precisely "presented identity" (these rough ideas are defined more precisely
later in this document through the concept of particular later in this document through the concept of particular
skipping to change at page 5, line 21 skipping to change at page 5, line 21
[SIP-CERTS] [SIP-CERTS]
o The General Internet Signalling Transport [GIST] o The General Internet Signalling Transport [GIST]
Application protocols have traditionally specified their own rules Application protocols have traditionally specified their own rules
for representing and verifying server identities. Unfortunately, for representing and verifying server identities. Unfortunately,
this divergence of approaches has caused some confusion among this divergence of approaches has caused some confusion among
certification authorities, application developers, and protocol certification authorities, application developers, and protocol
designers. designers.
To codify best current practices regarding the implementation and Therefore, to codify best current practices regarding the
deployment of secure PKIX-based authentication, this document implementation and deployment of secure PKIX-based authentication,
specifies recommended procedures for representing and verifying this document specifies recommended procedures for representing and
server identities in certificates intended for use in applications verifying server identities in certificates intended for use in
employing TLS. applications employing TLS.
1.2. Scope 1.2. Scope
1.2.1. In Scope 1.2.1. In Scope
This document applies only to server identities associated with This document applies only to server identities associated with
fully-qualified DNS domain names, only to TLS, and only to PKIX-based fully-qualified DNS domain names, only to TLS, and only to PKIX-based
systems. As a result, the scenarios described in the following systems. As a result, the scenarios described in the following
section are out of scope for this specification (although they might section are out of scope for this specification (although they might
be addressed by future specifications). be addressed by future specifications).
1.2.2. Out of Scope 1.2.2. Out of Scope
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 gives 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 (e.g., IP o Identifiers other than fully-qualified DNS domain names.
addresses).
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 of issued certificates certificates are a very small percentage of issued certificates
(e.g., less than 1%). Furthermore, IP addresses are not (e.g., less than 1%). Furthermore, IP addresses are not
necessarily reliable identifiers for application servers because necessarily reliable identifiers for application services because
of the existence of private internets [PRIVATE], host mobility, of the existence of private internets [PRIVATE], host mobility,
multiple interfaces on a given host, Network Address Translators multiple interfaces on a given host, Network Address Translators
(NATs) resulting in different addresses for a host from different (NATs) 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 do not discuss attributes unrelated to DNS domain
names, such as those defined in [X.520] and other such
specification (e.g., organizational attributes, geographical
attributes, company logos, and the like).
o Security protocols other than [TLS] or [DTLS]. o Security protocols other than [TLS] or [DTLS].
Although other secure, lower-layer protocols exist and also at Although other secure, lower-layer protocols exist and even employ
times employ PKIX certificates, e.g. [IPSEC], their use cases can PKIX certificates at times, e.g. [IPSEC], their use cases can
differ from those of TLS-based or DTLS-based application differ from those of TLS-based or DTLS-based application
technologies. Furtermore, 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], or use self-signed certificates, based on or similar to [OPENPGP], or use self-signed certificates,
or are deployed on networks are not directly connected to the or are deployed on networks are not directly connected to the
public Internet and therefore cannot depend on Certificate public Internet and therefore cannot depend on Certificate
Revocation Lists (CRLs) or the Online Certificate Status Protocol Revocation Lists (CRLs) or the Online Certificate Status Protocol
[OCSP] to check CA-issued certificates. However, the syntax of [OCSP] to check CA-issued certificates. However, the syntax of
OpenPGP keys differs significantly from X.509 certificates, the OpenPGP keys differs essentially from X.509 certificates, the data
data in self-signed certificates has not been certified by a in self-signed certificates has not been certified by a third
third-party in any way, and checking of CA-issued certificates via party in any way, and checking of CA-issued certificates via CRLs
CRLs or OSCP is critically important to maintaining the security or OSCP is critically important to maintaining the security of
of PKIX-based systems. Attempting to define best practices for PKIX-based systems. Attempting to define best practices for such
such technologies would unduly complicate the rules defined in technologies would unduly complicate the rules defined in this
this specification. specification.
Furthermore, this document also does not address various Furthermore, this document also does not address various
certification authority policies, such as: certification authority policies, such as:
o What classes and types of certificates to issue and whether to o What classes and types 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 Class 2 certificates but not in Class 1 or Extended character in Class 2 certificates but not in Class 1 or Extended
Validation certificates). Validation certificates).
o Whether to issue certificates based on IP addresses (or some other o Whether to issue certificates based on IP addresses (or some other
form, such as relative domain names) in addition to fully- form, such as relative domain names) in addition to fully-
qualified DNS domain names. qualified DNS domain names.
o Which identifiers to include (e.g., whether to include the SRVName o Which identifiers to include (e.g., whether to include the SRVName
and uniformResourceIdentifier extensions). and uniformResourceIdentifier extensions).
o How to certify or validate the information contained in a o How to certify or validate fully-qualified domain names and
certificate. application service types.
o How to certify or validate other kinds of information that might
be included in a certificate (e.g., organization name).
Finally, this specification is mostly silent about user interface Finally, this specification is mostly silent about user interface
issues, which in general are properly the responsibility of client issues, which in general are properly the responsibility of client
software developers and standards development organizations dedicated software developers and standards development organizations dedicated
to particular application technologies (see for example [WSC-UI]. to particular application technologies (see for example [WSC-UI]).
1.3. Terminology 1.3. Terminology
Because the concept of "identity" is too vague to be actionable in Because many concepts related to "identity" are often too vague to be
application protocols, we define a set of more concrete terms: actionable in application protocols, we define a set of more concrete
terms for use in this specification.
application server: A service on the Internet that enables application service: A service on the Internet that enables
interactive clients and automated clients to connect for the interactive and automated clients to connect for the purpose of
purpose of retrieving or uploading information, communicate with retrieving or uploading information, communicating with other
other entities, or connect to a broader network of services. entities, or connecting to a broader network of services.
application service provider: An organization or individual that
hosts or deploys an application service.
attribute-type-and-value pair: The ASN.1 structure for a
distinguished name as described in [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 natural person. controlled by a natural person.
direct name: A name that is provided directly to a client by a user. direct name: A name for an application service that is provided
directly to a client by a user, resulting in a source domain and
(optionally) a service type.
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 also used for matching be included in a certificate and therefore also used for matching
purposes; the types covered in this specification are: purposes; the types covered in this specification are:
* CN-ID = a Relative Distinguished Name (RDN) in the certificate * CN-ID = a Relative Distinguished Name (RDN) in the certificate
subject that contains one and only one attribute-type-and-value subject that contains one and only one attribute-type-and-value
pair of type Common Name (CN) pair of type Common Name (CN); see [PKIX] and also
[LDAP-SCHEMA]
* DNS-ID = a subjectAltName identifier of type dNSName * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX]
* SRV-ID = the SRVName form of otherName from the GeneralName * SRV-ID = a subjectAltName entry of type otherName whose name
structure in SubjectAltName form is SRVName; see [SRVNAME]
* URI-ID = a subjectAltName identifier of type * URI-ID = a subjectAltName entry of type
uniformResourceIdentifier uniformResourceIdentifier; see [PKIX]
indirect name: A name that is indirectly resolved by a client based indirect name: A name for an application service that is indirectly
on a direct name provided by a user. resolved by a client based on a direct name provided by a user,
resulting in a target domain and (optionally) a service type.
interactive client: A software agent or device that is directly interactive client: A software agent or device that is directly
controlled by a natural person. (Other specifications related to controlled by a natural person. (Other specifications related to
security and application protocols often refer to this as a "user security and application protocols often refer to this as a "user
agent", e.g., [WSC-UI].) agent", e.g., [WSC-UI].)
PKIX certificate: An X.509v3 certificate generated and employed in PKIX certificate: An X.509v3 certificate generated and employed in
the context of the Internet Public Key Infrastructure using X.509 the context of the Internet Public Key Infrastructure using X.509
[PKIX]. [PKIX].
skipping to change at page 8, line 36 skipping to change at page 9, line 10
a client within the server's PKIX certificate when the client a client within the server's PKIX certificate when the client
attempts to establish a secure connection with the server; the attempts to establish a secure connection with the server; the
certificate can include one or more presented identifiers of certificate can include one or more presented identifiers of
different types. different types.
reference identifier: An identifier that is used by the client for reference identifier: An identifier that is used by the client for
matching purposes when checking the presented identifiers; the matching purposes when checking the presented identifiers; the
client can attempt to match multiple reference identifiers of client can attempt to match multiple reference identifiers of
different types. different types.
restricted name: A name that can be used only for one kind of restricted name: A name that can be used only for one type of
application at a service provider. service at an application service provider.
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 URI scheme or a DNS SRV type typically takes the form of a Uniform Resource Identifier
Service. scheme [URI] or a DNS SRV Service [DNS-SRV].
source domain: The fully-qualified DNS domain name that a client source domain: The fully-qualified DNS domain name that a client
expects an application server to present in the certificate. expects an application service to present in the certificate.
subjectAltName entry: A specific identifier placed in the
subjectAltName extension.
subjectAltName extension: The subject alternative name structure of
an X.509v3 certificate as described in [PKIX].
subject name: The subject field of an X.509v3 certificate as
described in [PKIX].
TLS client: An entity that assumes the role of a client in a
Transport Layer Security [TLS] negotiation; in this specfication
we generally assume that the TLS client is an (interactive or
automated) application client, however in application protocols
that enable server-to-server communication the TLS client could be
a peer application service.
TLS server: An entity that assumes the role of a server in a
Transport Layer Security [TLS] negotiation; in this specfication
we assume that the TLS server is an application service.
target domain: A domain name or host name that a client has derived target 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) or that a natural person directly controlling a [DNS-SRV] lookup) or that a natural person directly controlling
an interactive client has explicitly configured for connecting to an interactive client has explicitly configured for connecting to
the source domain. the source domain.
unrestricted name: A name that can be used for any kind of unrestricted name: A name that can be used for any service type at
application at a service provider. an application service provider.
Most security-related terms in this document are to be understood in Most security-related terms in this document are to be understood in
the sense defined in [SECTERMS]; such terms include, but are not the sense defined in [SECTERMS]; such terms include, but are not
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 following capitalized keywords are to be interpreted as described The following capitalized keywords are to be interpreted as described
in [KEYWORDS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; in [KEYWORDS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT";
"SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY",
"OPTIONAL". "OPTIONAL".
1.4. Contributors 1.4. Contributors
The following individuals made significant contributions to the text The following individuals made important contributions to the text of
of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
1.5. Acknowledgements 1.5. Acknowledgements
The editors and contributors wish to thank the following individuals The editors and contributors wish to thank the following individuals
for their feedback and suggestions: Nelson Bolyard, Kaspar Brand, Ben for their feedback and suggestions: Nelson Bolyard, Kaspar Brand, Ben
Campbell, Scott Cantor, Dave Crocker, Cyrus Daboo, Charles Gardiner, Campbell, Scott Cantor, Dave Crocker, Cyrus Daboo, Charles Gardiner,
Philip Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Love Philip Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Love
Hornquist Astrand, Harry Hotz, Geoff Keating, Scott Lawrence, Matt Hornquist Astrand, Harry Hotz, Geoff Keating, Scott Lawrence, Matt
McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom
Petch, Yngven Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, Petch, Yngve Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, Martin
Martin Rex, Joe Salowey, Rob Stradling, Peter Sylvester, Dan Wing, Rex, Joe Salowey, Rob Stradling, Peter Sylvester, Dan Wing, and Dan
and Dan Winship. Winship.
1.6. Discussion Venue 1.6. Discussion Venue
[[ RFC Editor: please remove this section. ]] [[ RFC Editor: please remove this section. ]]
The editors are actively seeking input from certification The editors are actively seeking input from certification
authorities, application developers, and protocol designers regarding authorities, application developers, and protocol designers regarding
the recommendations in this document. Please send feedback to the the recommendations in this document. Please send feedback to the
editors directly or post to the <certid@ietf.org> mailing list, for editors directly or post to the <certid@ietf.org> mailing list, for
which archives and subscription information are available at which archives and subscription information are available at
<https://www.ietf.org/mailman/listinfo/certid>. <https://www.ietf.org/mailman/listinfo/certid>.
2. Names 2. Names
This section provides an overview of naming of Internet applications, This section discusses naming of application services on the
followed by a brief tutorial about subject naming in PKIX. Internet, followed by a brief tutorial about subject naming in PKIX.
2.1. Naming Applications 2.1. Naming Application Services
This specification assumes that an Internet application is named 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 an application 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 the user (e.g., via are direct because they are provided directly by the user (e.g., via
runtime input or prior configuration) whereas other names are runtime input or prior configuration) whereas other names are
indirect because they are resolved by the client based on input indirect because they are resolved by the client based on input
provided by the user (e.g., a target name resolved from a source name provided directly by the user (e.g., a target name resolved from a
using DNS SRV records). This dimension matters for certificate source name using DNS SRV records). This dimension matters for
verification. certificate verification.
From the perspective of the application server or service provider, From the perspective of the application service, some names are
some names are unrestricted because they can be used in any kind of unrestricted because they can be used in any type of service (e.g., a
application (e.g., a certificate might be re-used for both the HTTP certificate might be re-used for both the HTTP service and the IMAP
service and the IMAP service at example.com) whereas other names are service at example.com) whereas other names are restricted because
restricted because they can be used in only one kind of application they can be used in only one type of service (e.g., a special-purpose
(e.g., a special-purpose certificate that can be used only for an certificate that can be used only for an IMAP service). This
IMAP service). This dimension matters for certificate issuance. dimension matters for certificate issuance.
Therefore: Therefore:
o A CN-ID identifier is direct (provided by a user) and unrestricted o A CN-ID identifier is direct (provided by a user) and unrestricted
(can be used for any application). (can be used for any application).
o A DNS-ID identifier is direct (provided by a user) and o A DNS-ID identifier is direct (provided by a user) and
unrestricted (can be used for any application). unrestricted (can be used for any application).
o An SRV-ID identifier is indirect (resolved by a client) and o An SRV-ID identifier is indirect (resolved by a client) and
restricted (can be used for only a single application). restricted (can be used for only a single application).
o A URI-ID identifier is direct (provided by a user) and restricted o A URI-ID identifier is direct (provided by a user) and restricted
(can be used for only a single application). (can be used for only a single application).
We summarize this taxonomy in the following table. We summarize this taxonomy in the following table.
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| | Direct | Restricted | | | Direct | Restricted |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| CN-ID | Yes | No | | CN-ID | Yes | No |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
skipping to change at page 11, line 4 skipping to change at page 11, line 49
| | Direct | Restricted | | | Direct | Restricted |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| CN-ID | Yes | No | | CN-ID | Yes | No |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| DNS-ID | Yes | No | | DNS-ID | Yes | No |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| SRV-ID | No | Yes | | SRV-ID | No | Yes |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| URI-ID | Yes | Yes | | URI-ID | Yes | Yes |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
When implementing software, deploying services, and issuing When implementing software, deploying services, and issuing
certificates for secure PKIX-based authentication, it is important to certificates for secure PKIX-based authentication, it is important to
keep these distinctions in mind. In particular, best practices keep these distinctions in mind. In particular, best practices
differ somewhat for application server implementations, application differ somewhat for application server implementations, application
client implementations, service providers, and certification client implementations, application service providers, and
authorities. Protocol specifications that reference this document certification authorities. Protocol specifications that reference
MUST specify which identifiers are mandatory-to-implement by servers this document MUST specify which identifiers are mandatory-to-
and clients, which identifiers are to be preferred by service implement by servers and clients, which identifiers are to be
providers, and which identifiers ought to be supported by certificate preferred by application service providers, and which identifiers
issuers. Because these requirements differ across applications, it ought to be supported by certificate issuers. Because these
is impossible to categorically stipulate universal rules (e.g., that requirements differ across applications, it is impossible to
all software implementations, service providers, and certification categorically stipulate universal rules (e.g., that all software
authorities for all application protocols need to use or support DNS- implementations, service providers, and certification authorities for
IDs as a baseline for the purpose of interoperability); however, it all application protocols need to use or support DNS-IDs as a
is preferable that each application protocol will at least define a baseline for the purpose of interoperability); however, it is
preferable that each application protocol will at least define a
baseline that applies to the community of software developers, baseline that applies to the community of software developers,
service providers, and CAs actively using or supporting that application service providers, and CAs actively using or supporting
technology. that technology.
2.2. Subject Naming in PKIX Certificates 2.2. Subject Naming in PKIX Certificates
The application server is the subject of a server certificate. As The Internet Public Key Infrastructure using X.509 [PKIX] employs the
[PKIX] says, "[the] subject field identifies the entity associated global directory service model defined in [X.500] and [X.501]. In
with the public key stored in the subject public key field." this model, information is held in a directory information base (DIB)
and entries in the DIB are organized in a hierarchy called the
The application server is identified by a name or names carried in directory information tree (DIT). An entry in that hierarchy
the subject field and/or the subjectAltName extension of the consists of a set of attributes (each of which has a defined type and
certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details. one or more values) and is uniquely identified by a Distinguished
This section only briefly introduces distinguished names and their Name (DN). The DN of an entry is constructed by combining one or
components, as well as subjectAltNames and the particular more specially-nominated attributes of the entry itself (which
subjectAltName extension types explicitly mentioned in this together comprise the Relative Distinguished Name (RDN) of the entry)
specification. with the Distinguished Name of its superior entries in the tree, up
to the root of the DIT. An RDN is a set (i.e., an unordered group)
The subject field of a PKIX certificate is defined as an X.501 type of attribute-type-and-value pairs (see also [LDAP-DN]), each of which
Name and known as a Distinguished Name (DN) -- see [X.501] and asserts some attribute about the entry.
[PKIX]. A DN is an ordered sequence of Relative Distinguished Names
(RDNs), where each RDN is a set (i.e., an unordered group) of
attribute-type-and-value pairs [LDAP-DN], each of which asserts some
attribute about the subject of the certificate. In the DER encoding
of a DN, the RDNs are always in order from most significant to least
significant (i.e., the first RDN is most significant and the last RDN
is least significant); however, in the string representation of a DN
as used in various protocols and data formats, the RDNs might be
ordered from most significant to least significant (e.g., this is
true of LDAP) or from least significant to most significant.
It is perfectly acceptable for a PKIX certificate to have an empty
subject field as long as there is at least one subjectAltName entry.
Certificates are binary objects -- they are encoded using
distinguished encoding rules (DER). Thus, the generation of
displayable (a.k.a. printable) renderings of certificate subject and
issuer names means that the DER-encoded sequences are decoded and
converted into a "string representation" before being rendered.
Because a DN is an ordered sequence, order is preserved in the string
representation of a DN. However, because an RDN is an unordered
group of attribute-type-and-value pairs, the string representation of
an RDN can differ from the canonical DER encoding; in the canonical
encoding, the RDN that is deepest in the tree (and that therefore
distinguishes the relative name) is called the "most specific" RDN.
See [LDAP-DN] for details.
Certificate subjects may also have "alternative" names. These are More specifically, in [X.509] and [PKIX] an application service is
represented within certificates using the SubjectAltName field. This identified by a name or names carried in the subject field and/or the
field is a sequence of typed fields, where each type is a distinct subjectAltName extension of a certificate (as [PKIX] says, "[the]
type of identifier. For example, the subjectAltName identifier types subject field identifies the entity associated with the public key
noted in this specification are: stored in the subject public key field"). The subject field of a
PKIX certificate is an X.501 type Name (see Section 4.1.2.6 of
[PKIX]) and the subject alternative name ("subjectAltName") extension
allows various alternative identities to be bound to the subject (see
Section 4.2.1.6 of [PKIX]). It is perfectly acceptable for a PKIX
certificate to have an empty subject field as long as the certificate
contains a subjectAltName extension that includes at least one
subjectAltName entry. The subjectAltName extension is a sequence of
typed entries, where each type is a distinct kind of identifier. For
example, the subjectAltName entry types noted in this specification
are:
o dNSName -- a (fully-qualified) DNS domain name [PKIX] o dNSName -- a (fully-qualified) DNS domain name [PKIX]
o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME] o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME]
o uniformResourceIdentifier -- a Uniform Resource Identifier [URI] o uniformResourceIdentifier -- a Uniform Resource Identifier [URI]
[PKIX] [PKIX]
Existing certificates often use a CN-ID to represent a fully-
qualified DNS domain name; for example, consider the following
subjectName, where the attribute of type Common Name contains a
string whose form matches that of a fully-qualified DNS domain name
of "www.example.com":
cn=www.example.com,c=GB,ou=Web Services
In general, this specification recommends and prefers use of
subjectAltName entries over use of the subject field where possible,
as more completely described in the following sections.
Implementation Note: Confusion sometimes arises from different
renderings or encodings of the hierarchical information contained
in a certificate. Certificates are binary objects and are encoded
using the Distinguished Encoding Rules (DER) specified in [X.690].
However, some implementations generate displayable (a.k.a.
printable) renderings of certificate issuer, subject, and subject
alternative names, and these renderings convert the DER-encoded
sequences into a "string representation" before being displayed.
Because a Distinguished Name (DN) is an ordered sequence, order is
preserved in the string representation of a DN. However, because
a Relative Distinguished Name (RDN) is an unordered group of
attribute-type-and-value pairs, the string representation of an
RDN can differ from the canonical DER encoding. Furthermore,
various specifications refer to the order of RDNs using
terminology that is not directly related to the information
hierarchy, such as "most specific" vs. "least specific", "left-
most" vs. "right-most", "first" vs. "last", or "most significant"
vs. "least significant" (see for example [LDAP-DN]). In this
specification we avoid such terms in an effort to reduce
confusion.
3. Representation of Server Identity 3. Representation of Server Identity
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 service provider will fully-qualified DNS domain name at which the application service
provide the relevant application, the following rules apply to the provider will provide the relevant application, the following rules
representation of application server identities. apply to the representation of application service identities.
1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
identifier of type dNSName). entry of type dNSName) if possible as a 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" (i.e., an instance of the SRVName form SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type
of otherName from the GeneralName structure in the subjectAltName otherName whose name form is SRVName as specified in [SRVNAME]).
as specified in [SRVNAME]).
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 typically associated with a URI (e.g., this is
true of [SIP]), then the certificate SHOULD include an URI-ID true of [SIP]), then the certificate SHOULD include an URI-ID
(i.e., a subjectAltName identifier of type (i.e., a subjectAltName entry of type uniformResourceIdentifier);
uniformResourceIdentifier); the scheme SHALL be that of the the scheme SHALL be that of the protocol associated with the
protocol associated with the application type and the authority service type and the authority component SHALL be the fully-
component SHALL be the fully-qualified DNS domain name of the qualified DNS domain name of the service.
service.
4. The certificate MAY include other application-specific 4. The certificate MAY include other application-specific
identifiers for types that were defined before specification of identifiers for types that were defined before specification of
the SRVName extension (e.g., XmppAddr for [XMPP]) or for which the SRVName extension (e.g., XmppAddr for [XMPP]) or for which
service names or URI schemes do not exist; however, such service names or URI schemes do not exist; however, such
application-specific identifiers are not generally applicable and application-specific identifiers are not generally applicable and
therefore are out of scope for this specification. therefore are out of scope for this specification.
5. The certificate SHOULD NOT represent the server's fully-qualified 5. The certificate SHOULD NOT represent the server's fully-qualified
DNS domain name in a Relative Distinguished Name (RDN) of type DNS domain name in a CN-ID, even though many deployed clients
Common Name (CN) (see [LDAP-SCHEMA]), even though we recognize still check for this legacy identifier configuration within
that many deployed clients still check for this legacy identifier certificate subjectName. However, the certificate's subject
configuration within certificate subjectName. However, if this Distinguished Name SHOULD NOT contain more than one CN-ID, and
legacy identifer configuration is employed, then the server's MUST NOT contain RDNs which consist of multiple Common Name
fully-qualified DNS domain name MUST be placed in the last (most attributes.
specific) RDN within the RDN sequence making up the certificate's
subjectName, as the order of RDNs is determined by the DER-
encoded Name within the server's PKIX certificate. Furthermore,
the certificate's subject Distinguished Name SHOULD NOT contain
more than one Common Name attribute, and MUST NOT contain RDNs
which consist of multiple Common Name attributes.
6. The fully-qualified DNS domain name portion of the DN-ID or CN-ID 6. The fully-qualified DNS domain name portion of the DN-ID or CN-ID
MAY contain one instance of the wildcard character '*', but only MAY contain one instance of the wildcard character '*', but only
as the left-most label of the domain name component of the as the left-most label of the domain name component of the
identifier (following the definition of "label" from [DNS]). identifier (following the definition of "label" from [DNS]).
Specifications that profile the rules defined in this document Specifications that profile the rules defined in this document
MUST specify whether the wildcard character is or is not allowed MUST specify whether the wildcard character is or is not allowed
in certificates issued under that profile; by default wildcard in certificates issued under that profile; by default wildcard
certificates SHOULD NOT be allowed. certificates SHOULD NOT be allowed.
skipping to change at page 14, line 33 skipping to change at page 15, line 44
4.2. Constructing an Ordered List of Reference Identifiers 4.2. Constructing an Ordered List of Reference Identifiers
Before connecting to the server, the client MUST construct an ordered Before connecting to the server, the client MUST construct an ordered
list of acceptable reference identifiers. list of acceptable reference identifiers.
The inputs here might be a URI that a user has typed into an The inputs here might be a URI that a user has typed into an
interface (e.g., an HTTP URL for a web site), configured account interface (e.g., an HTTP URL for a web site), configured account
information (e.g., the username of an IMAP or POP3 account for information (e.g., the username of an IMAP or POP3 account for
retrieving email), or some other combination of information that can retrieving email), or some other combination of information that can
yield a source domain and an application type. yield a source domain and a service type.
The client might need to derive the source domain and application The client might need to derive the source domain and service type
type from the input(s) it has received. The derived data MUST from the input(s) it has received. The derived data MUST include
include only information that can be securely parsed out of the only information that can be securely parsed out of the inputs (e.g.,
inputs (e.g., extracting the fully-qualified DNS domain name from the extracting the fully-qualified DNS domain name from the authority
authority component of a URI or extracting the application type from component of a URI or extracting the service type from the scheme of
the scheme of a URI) or information for which the derivation is a URI) or information for which the derivation is performed in a
performed in a secure manner (e.g., using [DNSSEC]). secure manner (e.g., using [DNSSEC]).
In some cases the inputs might include more than one fully-qualified In some cases the inputs might include more than one fully-qualified
DNS domain name, because a user might have explicitly configured the DNS domain name, because a user might have explicitly configured the
client to associate a target domain with the source domain. Such client to associate a target domain with the source domain. Such
delegation can occur by means of user-approved DNS SRV records (e.g., delegation can occur by means of user-approved DNS SRV records (e.g.,
_xmpp-server._tcp.im.example.com might yield a hostname of _xmpp-server._tcp.im.example.com might yield an address of
hosting.example.net) or a user-configured lookup table for host-to- hosting.example.net) or a user-configured lookup table for host-to-
address or address-to-host translations (e.g., the Unix "hosts" address or address-to-host translations (e.g., the Unix "hosts"
file). See under Section 5 for further discussion of service file). See under Section 5 for further discussion of service
delegation. delegation.
Using the combination of fully-qualified DNS domain name(s) and Using the combination of fully-qualified DNS domain name(s) and
application type, the client constructs a list of reference service type, the client constructs a list of reference identifiers
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
target domain). target domain).
o If a server for the application type is typically discovered by o If a server for the service type is typically discovered by means
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 application type is typically associated with o If a server for the service type is typically associated with a
a URI, then the list SHOULD include a URI-ID URI, then the list SHOULD include a URI-ID
o The list SHOULD NOT include a CN-ID; however, the CN-ID (if o The list SHOULD NOT include a CN-ID; however, the CN-ID (if
included) MUST be constructed only from the source domain and included) MUST be constructed only from the source domain and
never from a target domain. never from a target domain.
Implementation Note: The client does not need to actually Implementation Note: The client does not need to actually
construct the foregoing identifiers in the formats found in a construct the foregoing identifiers in the formats found in a
certificate (e.g., as ASN.1 object identifiers), only the certificate (e.g., as ASN.1 object identifiers), only the
functional equivalent of such identifiers for matching purposes. functional equivalent of such identifiers for matching purposes.
skipping to change at page 15, line 44 skipping to change at page 17, line 10
identifiers. identifiers.
The client then orders the list in accordance with the following The client then orders the list in accordance with the following
rules: rules:
o Reference identifiers that include the source domain MUST be o Reference identifiers that include the source domain MUST be
preferred over reference identifiers that include a target domain preferred over reference identifiers that include a target domain
(if any). (if any).
o Reference identifiers that include both a fully-qualified DNS o Reference identifiers that include both a fully-qualified DNS
domain name and an application type MUST be preferred over domain name and a service type MUST be preferred over reference
reference identifiers that include only a fully-qualified DNS identifiers that include only a fully-qualified DNS domain name.
domain name. Therefore an SRV-ID or URI-ID is to be preferred Therefore an SRV-ID or URI-ID is to be preferred over a DNS-ID.
over a DNS-ID.
o Notwithstanding any of the foregoing rules, reference identifiers o Notwithstanding any of the foregoing rules, reference identifiers
of type CN-ID (if included) MUST always be the lowest-priority of type CN-ID (if included) MUST always be the lowest-priority
reference identifiers in the list. reference identifiers in the list.
To illustrate the ordering rules, consider the case where the inputs To illustrate the ordering rules, consider the case where the inputs
are a source domain of "im.example.com" and an application type of are a source domain of "im.example.com" and a service type of "XMPP"
"XMPP" (for which application servers are discovered via DNS SRV (for which application services are discovered via DNS SRV records)
records) and the user of the client has also explicitly configured a and the user of the client has also explicitly configured a target
target domain of "hosting.example.net". In this case, the ordered domain of "hosting.example.net". In this case, the ordered list
list would be: would be:
1. SRV-ID of "_xmpp.im.example.com" 1. SRV-ID of "_xmpp.im.example.com"
2. DNS-ID of "im.example.com" 2. DNS-ID of "im.example.com"
3. SRV-ID of "_xmpp.hosting.example.net" 3. SRV-ID of "_xmpp.hosting.example.net"
4. DNS-ID of "hosting.example.net" 4. DNS-ID of "hosting.example.net"
5. CN-ID of "im.example.com" 5. CN-ID of "im.example.com"
4.3. Seeking a Match 4.3. Seeking a Match
Once the client has constructed its order list of reference Once the client has constructed its order list of reference
skipping to change at page 16, line 34 skipping to change at page 17, line 47
finding a match. It does so by seeking a match in preference order finding a match. It does so by seeking a match in preference order
and aborting the search if any presented identifier matches one of and aborting the search if any presented identifier matches one of
its reference identifiers. The search fails if the client exhausts its reference identifiers. The search fails if the client exhausts
its list of reference identifiers without finding a match. Detailed its list of reference identifiers without finding a match. Detailed
comparison rules for finding a match are provided in the following comparison rules for finding a match are provided in the following
sections. sections.
Security Note: A client MUST NOT seek a match for a reference Security Note: A client MUST NOT seek a match for a reference
identifier of CN-ID if the presented identifiers include an identifier of CN-ID if the presented identifiers include an
SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
extensions supported by the client. Furthermore, a client SHALL entry types supported by the client.
check only against the last Common Name RDN in the sequence of
RDNs making up the Distinguished Name within the certificate's
subjectName (where the term "last" refers to the DER order, which
is often not the string order presented to a user; the order that
is applied here MUST be the DER order).
4.4. Verifying a Domain Name 4.4. Verifying a Domain Name
This document assumes that each reference identifier contains a This document assumes that each reference identifier contains a
fully-qualified DNS domain name that is a "traditional domain name" fully-qualified DNS domain name that is a "traditional domain name"
or an "internationalized domain name". The client MUST match the or an "internationalized domain name". The client MUST match the
source domain of a reference identifier according to the following source domain of a reference identifier according to the following
rules. rules.
4.4.1. Checking of Traditional Domain Names 4.4.1. Checking of Traditional Domain Names
skipping to change at page 18, line 7 skipping to change at page 19, line 19
to match only the one position-wise corresponding label (thus to match only the one position-wise corresponding label (thus
*.example.com matches foo.example.com but not bar.foo.example.com or *.example.com matches foo.example.com but not bar.foo.example.com or
example.com). The client MUST fail to match a presented identifier example.com). The client MUST fail to match a presented identifier
in which the wildcard character is contained within a label fragment in which the wildcard character is contained within a label fragment
(e.g., baz*.example.net is not allowed and MUST NOT be taken to match (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
baz1.example.net and baz2.example.net), or in which the wildcard baz1.example.net and baz2.example.net), or in which the wildcard
character does not comprise the left-most label in the presented character does not comprise the left-most label in the presented
identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net
are allowed). are allowed).
4.4.4. Checking of DNS Domain Names in 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 an SRV-ID, URI-ID, of CN-ID if the presented identifiers include an SRV-ID, URI-ID,
DNS-ID, or any application-specific subjectAltName extensions DNS-ID, or any application-specific subjectAltName entry types
supported by the client. supported by the client.
Therefore, if and only if the identity set does not include Therefore, if and only if the identity set does not include a
subjectAltName extensions of type dNSName, SRVName, or subjectAltName entry of type dNSName, SRVName, or
uniformResourceIdentifier (or any application-specific subjectAltName uniformResourceIdentifier (or any application-specific subjectAltName
extensions supported by the client), the client MAY as a fallback entry types supported by the client), the client MAY as a fallback
check for a fully-qualified DNS domain name in the last Common Name check for a string whose form matches that of a fully-qualified DNS
RDN in the sequence of RDNs making up the Distinguished Name within domain name in the CN-ID. If the client chooses to compare a
the certificate's subjectName (where the term "last" refers to the reference identifier of type CN-ID against that string, it MUST
DER order, which is often not the string order presented to a user; follow the comparison rules for the source domain of an identifier of
the order that is applied here MUST be the DER order). type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4.
In existing certificates, the CN is often used for representing a
fully-qualified DNS domain name; for example, consider the following
subjectName, where the last RDN is a Common Name that is intended to
represent a fully-qualified DNS domain name:
cn=www.example.com,c=GB,ou=Web Services
Here the Common Name is "www.example.com" (a string whose form
matches that of a fully-qualified DNS domain name) and the client
could choose to compare a reference identifier of type CN-ID against
that string. When doing so, the client MUST follow the comparison
rules for the source domain of an identifier of type DNS-ID, SRV-ID,
or URI-ID, as described under Section 4.4.
4.5. Verifying an Application Type 4.5. Verifying an Application Type
As specified under the ordering rules for reference identifiers, a As specified under the ordering rules for reference identifiers, a
client SHOULD check not only the domain name but also the application client SHOULD check not only the domain name but also the service
type of the service to which it connects. This is a best practice type of the service to which it connects. This is a best practice
because typically a client is not designed to connect to all kinds of because typically a client is not designed to connect to all kinds of
services using all possible application protocols, but instead is services using all possible application protocols, but instead is
designed to connect to a specific kind of service, such as a web designed to connect to one kind of service, such as a web site, an
site, an email service, or an instant messaging service. email service, or an instant messaging service.
The application type is verified by means of either an SRV-ID or The service type is verified by means of either an SRV-ID or URI-ID.
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., "xmpp") 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. SRV records.
4.5.2. URI-ID 4.5.2. URI-ID
skipping to change at page 19, line 48 skipping to change at page 20, line 43
certificate and (if it is an interactive client) MUST notify the user certificate and (if it is an interactive client) MUST notify the user
if the certificate has changed since the last time a secure if the certificate has changed since the last time a secure
connection was successfully negotiated (where causes of change connection was successfully negotiated (where causes of change
include but are not limited to changes in the DNS domain name, include but are not limited to changes in the DNS domain name,
identifiers, issuer, certification path, and expiration date). identifiers, issuer, certification path, and expiration date).
4.6.3. Case #3: No Match Found, Uncached Certificate 4.6.3. Case #3: No Match Found, Uncached Certificate
If the client finds no presented identifier that matches any of the If the client finds no presented identifier that matches any of the
reference identifiers and a human user has not permanently accepted reference identifiers and a human user has not permanently accepted
the certificate for this application server during a previous the certificate for this application service during a previous
connection attempt, the client MUST NOT consider the certificate to connection attempt, the client MUST NOT consider the certificate to
include a validated identity for the application server. include a validated identity for the application service.
Instead, the client MUST proceed as follows. Instead, the client MUST proceed as follows.
4.6.3.1. Interactive User Agent 4.6.3.1. Interactive User Agent
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 natural person, then it MUST either do one of the following: a natural person, then it MUST either do one of the following:
1. Automatically terminate the connection with a bad certificate 1. Automatically terminate the connection with a bad certificate
error; or error; or
2. Actively warn the user that the certificate is untrusted and 2. Actively warn the user that the certificate is untrusted and
encourage the user to terminate the connection, but give advanced encourage the user to terminate the connection, but give advanced
users the option to (a) view the entire certification path, (b) users the option to (a) view the entire certification path, (b)
accept the certificate for this application server either accept the certificate for this application service either
temporarily (i.e., for this connection attempt only) or temporarily (i.e., for this connection attempt only) or
permanently (i.e., for all future connection attempts) despite permanently (i.e., for all future connection attempts) despite
the identity mismatch, and then (c) continue with the connection the identity mismatch, and then (c) continue with the connection
attempt. attempt.
If a user permanently accepts a certificate for this application If a user permanently accepts a certificate for this application
server despite an identity mismatch (an action referred to in service despite an identity mismatch (an action referred to in
[WSC-UI] as "pinning"), the client MUST cache the certificate (or [WSC-UI] as "pinning"), the client MUST cache the certificate (or
some non-forgeable representation such as a hash value) and in future some non-forgeable representation such as a hash value) and in future
connection attempts MUST behave as in "Case #2: No Match Found, connection attempts MUST behave as in "Case #2: No Match Found,
Cached Certificate" Section 4.6.2. However, the client MUST provide Cached Certificate" Section 4.6.2. However, the client MUST provide
a method for revoking trust in cached certificates. a method for revoking trust in cached certificates.
Security Note: It is the responsibility of the human user to Security Note: It is the responsibility of the human user to
verify the hash value or fingerprint of the certificate with the verify the hash value or fingerprint of the certificate with the
server over a trusted communication layer. server over a trusted communication layer.
skipping to change at page 21, line 7 skipping to change at page 22, line 7
controlled by a natural person, then it SHOULD terminate the controlled by a natural person, then it SHOULD terminate the
connection with a bad certificate error and log the error to an connection with a bad certificate error and log the error to an
appropriate audit log. An automated application MAY provide a appropriate audit log. An automated application MAY provide a
configuration setting that disables this check, but MUST enable the configuration setting that disables this check, but MUST enable the
check by default. check by default.
5. Security Considerations 5. Security Considerations
5.1. Service Delegation 5.1. Service Delegation
When the connecting application is an interactive client, the source When the connecting application is an interactive client, the source
domain name and application type MUST be provided by a human user domain name and service type MUST be provided by a human user (e.g.
(e.g. when specifying the server portion of the user's account name when specifying the server portion of the user's account name on the
on the server or when explicitly configuring the client to connect to server or when explicitly configuring the client to connect to a
a particular host or URI as in [SIP-LOC]) and MUST NOT be derived particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
from the user inputs in an automated fashion (e.g., a hostname the user inputs in an automated fashion (e.g., a host name or domain
address discovered through DNS resolution of the source domain). name discovered through DNS resolution of the source domain). This
This rule is important because only a match between the user inputs rule is important because only a match between the user inputs (in
(in the form of a reference identifier) and a presented identifier the form of a reference identifier) and a presented identifier
enables the client to be sure that the certificate can legitimately enables the client to be sure that the certificate can legitimately
be used to secure the connection. be used to secure the connection.
However, an interactive client MAY provide a configuration setting However, an interactive client MAY provide a configuration setting
that enables a human user to explicitly specify a particular hostname that enables a human user to explicitly specify a particular host
(called a "target domain") to be checked for connection purposes. name or domain name (called a "target domain") to be checked for
connection purposes.
5.2. Wildcard Certificates 5.2. Wildcard Certificates
Allowing the wildcard character in certificates has led to homograph Allowing the wildcard character in certificates has led to homograph
attacks involving non-ASCII characters that look similar to attacks involving non-ASCII characters that look similar to
characters commonly included in HTTP URLs, such as "/" and "?"; for characters commonly included in HTTP URLs, such as "/" and "?"; for
discussion, see for example [Defeating-SSL]. discussion, see for example [Defeating-SSL].
5.3. Internationalized Domain Names 5.3. Internationalized Domain Names
skipping to change at page 25, line 15 skipping to change at page 26, line 15
[SECTERMS] [SECTERMS]
Shirey, R., "Internet Security Glossary, Version 2", Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[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 B. Laboratories, "Domain Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
draft-ietf-sip-domain-certs-06 (work in progress), RFC 5922, June 2010.
March 2010.
[SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation [SIP-LOC] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[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
skipping to change at page 26, line 10 skipping to change at page 27, line 10
[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
Interface Guidelines", World Wide Web Consortium Interface Guidelines", World Wide Web Consortium
LastCall WD-wsc-ui-20100309, March 2010, LastCall WD-wsc-ui-20100309, March 2010,
<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>. <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[X.500] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Overview of concepts, models and services", ITU-
T Recommendation X.500, ISO Standard 9594-1, August 2005.
[X.501] International Telecommunications Union, "Information [X.501] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory: Technology - Open Systems Interconnection - The Directory:
Models", ITU-T Recommendation X.501, ISO Standard 9594-2, Models", ITU-T Recommendation X.501, ISO Standard 9594-2,
February 2001. August 2005.
[X.509] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks", ITU-
T Recommendation X.509, ISO Standard 9594-8, August 2005.
[X.520] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Selected attribute types", ITU-T Recommendation X.509,
ISO Standard 9594-6, August 2005.
[X.690] International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, ISO Standard 8825-1, August 2008.
[XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work
in progress), April 2010. in progress), April 2010.
Appendix A. Prior Art Appendix A. Prior Art
skipping to change at page 39, line 41 skipping to change at page 41, line 18
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600 1899 Wyknoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
Jeff Hodges Jeff Hodges
PayPal PayPal
2211 North First Street
San Jose, California 95131
US
Email: Jeff.Hodges@PayPal.com Email: Jeff.Hodges@PayPal.com
 End of changes. 82 change blocks. 
274 lines changed or deleted 334 lines changed or added

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