< draft-saintandre-tls-server-id-check-06.txt   draft-saintandre-tls-server-id-check-07.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco Systems, Inc.
Intended status: BCP J. Hodges Intended status: BCP J. Hodges
Expires: December 13, 2010 PayPal Expires: January 1, 2011 PayPal
June 11, 2010 June 30, 2010
Representation and Verification of Domain-Based Application Server Representation and Verification of Domain-Based Application Server
Identity in Certificates Used with Transport Layer Security Identity in Certificates Used with Transport Layer Security
draft-saintandre-tls-server-id-check-06 draft-saintandre-tls-server-id-check-07
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 servers in
such interactions. such interactions.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 13, 2010. This Internet-Draft will expire on January 1, 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
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 . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9
1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9
2. Representation of Server Identity . . . . . . . . . . . . . . 9 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 9 2.1. Naming Applications . . . . . . . . . . . . . . . . . . . 10
2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 10 2.2. Subject Naming in PKIX Certificates . . . . . . . . . . . 11
3. Verification of Server Identity . . . . . . . . . . . . . . . 12 3. Representation of Server Identity . . . . . . . . . . . . . . 12
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Verification of Server Identity . . . . . . . . . . . . . . . 13
3.2. Constructing an Ordered List of Reference Identifiers . . 12 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 14 4.2. Constructing an Ordered List of Reference Identifiers . . 14
3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 15 4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 16
3.4.1. Checking of Traditional Domain Names . . . . . . . . . 15 4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 16
3.4.2. Checking of Internationalized Domain Names . . . . . . 16 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 16
3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 16 4.4.2. Checking of Internationalized Domain Names . . . . . . 17
3.4.4. Checking of DNS Domain Names in Common Names . . . . . 17 4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 17
3.5. Verifying an Application Type . . . . . . . . . . . . . . 17 4.4.4. Checking of DNS Domain Names in Common Names . . . . . 18
3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. Verifying an Application Type . . . . . . . . . . . . . . 18
3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 18 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 18 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 19
3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 18 4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 19
3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 18 4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 19
3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 19 4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 20
4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 20 5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 21
4.3. Internationalized Domain Names . . . . . . . . . . . . . . 20 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 22
A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 25 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 26
A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 26 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 26
A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 27 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 27
A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 30 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 28
A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 31 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 31
A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 32 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 33
A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 33 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 34
A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 35 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 35
A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 36 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 36
A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 37 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
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 server 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 server 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 in the context of the Internet Public Key Infrastructure authority (CA) in the context of the Internet Public Key
using X.509 [PKIX]. Informally, we can think of these identities as Infrastructure using X.509 [PKIX]. Informally, we can think of these
the client's "reference identity" and the server's "presented identities as the client's "reference identity" and the server's
identity" (these rough ideas are defined more precisely later in this "presented identity" (these rough ideas are defined more precisely
document through the concept of particular identifiers). In general, later in this document through the concept of particular
a client needs to verify that the server's presented identity matches identifiers). In general, a client needs to verify that the server's
its reference identity so that it can be sure that the certificate presented identity matches its reference identity so that it can be
can legitimately be used to authenticate the connection. sure that the certificate can legitimately be used to authenticate
the connection.
Many application technologies adhere to the pattern outlined here, Many application technologies adhere to the pattern outlined here,
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 7, line 33 skipping to change at page 7, line 38
application protocols, we define a set of more concrete terms: application protocols, we define a set of more concrete terms:
application server: A service on the Internet that enables application server: A service on the Internet that enables
interactive clients and automated clients to connect for the interactive clients and automated clients to connect for the
purpose of retrieving or uploading information, communicate with purpose of retrieving or uploading information, communicate with
other entities, or connect to a broader network of services. other entities, or connect to a broader network of services.
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.
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 value subject that contains one and only one attribute-type-and-value
assertion (AVA) whose attribute type is Common Name (CN) pair of type Common Name (CN)
* DC-ID = a series of Domain Component (DC) attributes in the
certificate subject, with one RDN per domain label and one DC
in each RDN.
* DNS-ID = a subjectAltName identifier of type dNSName * DNS-ID = a subjectAltName identifier of type dNSName
* SRV-ID = the SRVName form of otherName from the GeneralName * SRV-ID = the SRVName form of otherName from the GeneralName
structure in SubjectAltName structure in SubjectAltName
* URI-ID = a subjectAltName identifier of type * URI-ID = a subjectAltName identifier of type
uniformResourceIdentifier uniformResourceIdentifier
indirect name: A name that is indirectly resolved by a client based
on a direct name provided by a user.
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].
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 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
application at a 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 URI scheme or a DNS SRV
Service. Service.
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 server to present in the certificate.
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
application at a 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", "certificate", "credential", "identity", "certification authority", "certification path", "certificate",
"self-signed certificate", "trust", "trust anchor", "trust chain", "credential", "identity", "self-signed certificate", "trust", "trust
"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 [TERMS]: "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 significant contributions to the text
of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga. of 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, for their feedback and suggestions: Nelson Bolyard, Kaspar Brand, Ben
Scott Cantor, Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Campbell, Scott Cantor, Dave Crocker, Cyrus Daboo, Charles Gardiner,
Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Harry Hotz, Philip Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Love
Geoff Keating, Scott Lawrence, Matt McCutchen, Alexey Melnikov, Eddy Hornquist Astrand, Harry Hotz, Geoff Keating, Scott Lawrence, Matt
Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngven Pettersen, Tim McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom
Polk, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Rob Petch, Yngven Pettersen, Tim Polk, Eric Rescorla, Pete Resnick,
Stradling, Peter Sylvester, Dan Wing, Dan Winship, and Kurt Zeilenga. Martin Rex, Joe Salowey, Rob Stradling, Peter Sylvester, Dan Wing,
and Dan 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. Representation of Server Identity 2. Names
This section enumerates the rules for representing application server This section provides an overview of naming of Internet applications,
identity in PKIX certificates. First we provide a brief tutorial followed by a brief tutorial about subject naming in PKIX.
about subject naming, then we provide the rules.
2.1. Subject Naming in PKIX Certificates 2.1. Naming Applications
This specification assumes that an Internet application is named
based on a DNS domain name (e.g., "example.com") -- supplemented in
some circumstances by an application type (e.g., "the IMAP server at
example.com").
From the perspective of the application client or user, some names
are direct because they are provided directly by the user (e.g., via
runtime input or prior configuration) whereas other names are
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
using DNS SRV records). This dimension matters for certificate
verification.
From the perspective of the application server or service provider,
some names are unrestricted because they can be used in any kind of
application (e.g., a certificate might be re-used for both the HTTP
service and the IMAP service at example.com) whereas other names are
restricted because they can be used in only one kind of application
(e.g., a special-purpose certificate that can be used only for an
IMAP service). This dimension matters for certificate issuance.
Therefore:
o A CN-ID identifier is direct (provided by a user) and unrestricted
(can be used for any application).
o A DNS-ID identifier is direct (provided by a user) and
unrestricted (can be used for any application).
o An SRV-ID identifier is indirect (resolved by a client) and
restricted (can be used for only a single application).
o A URI-ID identifier is direct (provided by a user) and restricted
(can be used for only a single application).
We summarize this taxonomy in the following table.
+-----------+-----------+---------------+
| | Direct | Restricted |
+-----------+-----------+---------------+
| CN-ID | Yes | No |
+-----------+-----------+---------------+
| DNS-ID | Yes | No |
+-----------+-----------+---------------+
| SRV-ID | No | Yes |
+-----------+-----------+---------------+
| URI-ID | Yes | Yes |
+-----------+-----------+---------------+
When implementing software, deploying services, and issuing
certificates for secure PKIX-based authentication, it is important to
keep these distinctions in mind. In particular, best practices
differ somewhat for application server implementations, application
client implementations, service providers, and certification
authorities. Protocol specifications that reference this document
MUST specify which identifiers are mandatory-to-implement by servers
and clients, which identifiers are to be preferred by service
providers, and which identifiers ought to be supported by certificate
issuers. Because these requirements differ across applications, it
is impossible to categorically stipulate universal rules (e.g., that
all software implementations, service providers, and certification
authorities for all application protocols need to use or support DNS-
IDs as 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,
service providers, and CAs actively using or supporting that
technology.
2.2. Subject Naming in PKIX Certificates
The application server is the subject of a server certificate. As The application server is the subject of a server certificate. As
[PKIX] says, "[the] subject field identifies the entity associated [PKIX] says, "[the] subject field identifies the entity associated
with the public key stored in the subject public key field." with the public key stored in the subject public key field."
The application server is identified by a name or names carried in The application server is identified by a name or names carried in
the subject field and/or the subjectAltName extension of the the subject field and/or the subjectAltName extension of the
certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details. certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details.
This section only briefly introduces distinguished names and their This section only briefly introduces distinguished names and their
components, as well as subjectAltNames and the particular components, as well as subjectAltNames and the particular
subjectAltName extension types explicitly mentioned in this subjectAltName extension types explicitly mentioned in this
specification. specification.
The subject field of a PKIX certificate is defined as an X.501 type The subject field of a PKIX certificate is defined as an X.501 type
Name and known as a Distinguished Name (DN) -- see [X.501] and Name and known as a Distinguished Name (DN) -- see [X.501] and
[PKIX]. A DN is an ordered sequence of Relative Distinguished Names [PKIX]. A DN is an ordered sequence of Relative Distinguished Names
(RDNs), where each RDN is a set (i.e., an unordered group) of type- (RDNs), where each RDN is a set (i.e., an unordered group) of
and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], attribute-type-and-value pairs [LDAP-DN], each of which asserts some
each of which asserts some attribute about the subject of the attribute about the subject of the certificate. In the DER encoding
certificate. In the DER encoding of a DN, the RDNs are always in of a DN, the RDNs are always in order from most significant to least
order from most significant to least significant (i.e., the first RDN significant (i.e., the first RDN is most significant and the last RDN
is most significant and the last RDN is least significant); however, is least significant); however, in the string representation of a DN
in the string representation of a DN as used in various protocols and as used in various protocols and data formats, the RDNs might be
data formats, the RDNs might be ordered from most significant to ordered from most significant to least significant (e.g., this is
least significant (e.g., this is true of LDAP) or from least true of LDAP) or from least significant to most significant.
significant to most significant.
Note that certificates are binary objects -- they are encoded using It is perfectly acceptable for a PKIX certificate to have an empty
distinguished encoding rules (DER). Thus, displayable (a.k.a. subject field as long as there is at least one subjectAltName entry.
printable) renderings of certificate subject (and issuer) names means
that the DER-encoded sequences are decoded and converted into a Certificates are binary objects -- they are encoded using
"string representation" of a DN before being rendered. Often such a distinguished encoding rules (DER). Thus, the generation of
DN string representation is ordered from left-to-right, most specific displayable (a.k.a. printable) renderings of certificate subject and
to most general. See [LDAP-DN] for details. 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 Certificate subjects may also have "alternative" names. These are
represented within certificates using the SubjectAltName field. This represented within certificates using the SubjectAltName field. This
field is a sequence of typed fields, where each type is a distinct field is a sequence of typed fields, where each type is a distinct
type of identifier. For example, the subjectAltName identifier types type of identifier. For example, the subjectAltName identifier types
noted in this specification are: 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]
2.2. PKIX Certificate Name Rules 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 server will provide the fully-qualified DNS domain name at which the service provider will
relevant service, the following rules apply to the representation of provide the relevant application, the following rules apply to the
application server identities. representation of application server identities.
1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
identifier of type dNSName). identifier of type dNSName).
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., an instance of the SRVName form
of otherName from the GeneralName structure in the subjectAltName of otherName from the GeneralName structure in the subjectAltName
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
skipping to change at page 11, line 42 skipping to change at page 13, line 28
configuration within certificate subjectName. However, if this configuration within certificate subjectName. However, if this
legacy identifer configuration is employed, then the server's legacy identifer configuration is employed, then the server's
fully-qualified DNS domain name MUST be placed in the last (most fully-qualified DNS domain name MUST be placed in the last (most
specific) RDN within the RDN sequence making up the certificate's specific) RDN within the RDN sequence making up the certificate's
subjectName, as the order of RDNs is determined by the DER- subjectName, as the order of RDNs is determined by the DER-
encoded Name within the server's PKIX certificate. Furthermore, encoded Name within the server's PKIX certificate. Furthermore,
the certificate's subject Distinguished Name SHOULD NOT contain the certificate's subject Distinguished Name SHOULD NOT contain
more than one Common Name attribute, and MUST NOT contain RDNs more than one Common Name attribute, and MUST NOT contain RDNs
which consist of multiple Common Name attributes. which consist of multiple Common Name attributes.
6. The certificate SHOULD NOT represent the server's fully-qualified 6. The fully-qualified DNS domain name portion of the DN-ID or CN-ID
DNS domain name by means of a DC-ID, i.e., a series of Domain
Component (DC) attributes in the certificate subject, with one
RDN per domain label and one DC in each RDN. Although (for
example) <dc=www,dc=example,dc=com> could be used to represent
the DNS domain name "www.example.com", given the fact that the
DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED.
7. 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.
3. Verification of Server Identity 4. Verification of Server Identity
3.1. Overview 4.1. Overview
At a high level, the client verifies the server's identity by At a high level, the client verifies the server's identity by
performing the following actions: performing the following actions:
1. Before connecting to the server, the client constructs an ordered 1. Before connecting to the server, the client constructs an ordered
list of reference identifiers against which to check the list of reference identifiers against which to check the
presented identifiers. presented identifiers.
2. The server provides its identifiers in the form of a PKIX 2. The server provides its identifiers in the form of a PKIX
certificate. certificate.
skipping to change at page 12, line 40 skipping to change at page 14, line 24
match the service type of the identifiers. match the service type of the identifiers.
Implementation Note: Naturally, in addition to checking Implementation Note: Naturally, in addition to checking
identifiers, a client might complete further checks to ensure that identifiers, a client might complete further checks to ensure that
the server is authorized to provide the requested service. the server is authorized to provide the requested service.
However, such checking is not a matter of verifying the server However, such checking is not a matter of verifying the server
identity presented in a certificate, and therefore methods for identity presented in a certificate, and therefore methods for
doing so (e.g., consulting local policy information) are out of doing so (e.g., consulting local policy information) are out of
scope for this document. scope for this document.
3.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 an application type.
skipping to change at page 13, line 21 skipping to change at page 14, line 50
the scheme of a URI) or information for which the derivation is the scheme of a URI) or information for which the derivation is
performed in a secure manner (e.g., using [DNSSEC]). performed in a 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 a hostname 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 4 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 application type, the client constructs a list of reference
identifiers in accordance with the following rules: identifiers 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
skipping to change at page 13, line 45 skipping to change at page 15, line 26
o If a server for the application type is typically discovered by o If a server for the application type is typically discovered by
means of DNS SRV records , then the list SHOULD include an SRV-ID. means 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 application type is typically associated with
a URI, then the list SHOULD include a URI-ID a 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.
o The list SHOULD NOT include a DC-ID; however, the DC-ID (if
included) MUST be constructed only from the source domain and
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.
Security Note: A client MUST NOT construct a reference identifier Security Note: A client MUST NOT construct a reference identifier
corresponding to Relative Distinguished Names (RDNs) other than corresponding to Relative Distinguished Names (RDNs) other than
the Common Name or Domain Components (DCs) and MUST NOT check for the Common Name and MUST NOT check for such RDNs in the presented
such RDNs in the presented 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 an application type MUST be preferred over
skipping to change at page 14, line 45 skipping to change at page 16, line 18
records) and the user of the client has also explicitly configured a records) and the user of the client has also explicitly configured a
target domain of "hosting.example.net". In this case, the ordered target domain of "hosting.example.net". In this case, the ordered
list would be: list 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"
3.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
identifiers and has received the server's presented identifiers in identifiers and has received the server's presented identifiers in
the form of a PKIX certificate, the client checks its reference the form of a PKIX certificate, the client checks its reference
identifiers against the presented identifiers for the purpose of identifiers against the presented identifiers for the purpose of
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
skipping to change at page 15, line 20 skipping to change at page 16, line 41
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 extensions supported by the client. Furthermore, a client SHALL
check only against the last Common Name RDN in the sequence of check only against the last Common Name RDN in the sequence of
RDNs making up the Distinguished Name within the certificate's RDNs making up the Distinguished Name within the certificate's
subjectName (where the term "last" refers to the DER order, which 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 often not the string order presented to a user; the order that
is applied here MUST be the DER order). is applied here MUST be the DER order).
3.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.
3.4.1. Checking of Traditional Domain Names 4.4.1. Checking of Traditional Domain Names
The term "traditional domain name" is a contraction of this more The term "traditional domain name" is a contraction of this more
formal and accurate name: "traditional US-ASCII letter-digit-hyphen formal and accurate name: "traditional US-ASCII letter-digit-hyphen
DNS domain name". Traditional domain names are defined in DNS domain name". Traditional domain names are defined in
[DNS-CONCEPTS] and [DNS] in conjunction with [HOSTS] as further [DNS-CONCEPTS] and [DNS] in conjunction with [HOSTS] as further
explained in [IDNA2003]. In essence, a traditional domain name explained in [IDNA2003]. In essence, a traditional domain name
consists of a set of one or more labels (e.g., "www", "example", and consists of a set of one or more labels (e.g., "www", "example", and
"com"), with the labels usually shown separated by dots (e.g., "com"), with the labels usually shown separated by dots (e.g.,
"www.example.com"). Labels nominally consist of only [US-ASCII] "www.example.com"). Labels nominally consist of only [US-ASCII]
uppercase and lowercase letters, digits, and hyphen. There are uppercase and lowercase letters, digits, and hyphen. There are
skipping to change at page 16, line 5 skipping to change at page 17, line 23
specification. specification.
If the source domain of a reference identifier is a "traditional If the source domain of a reference identifier is a "traditional
domain name", then matching of the reference identifier against the domain name", then matching of the reference identifier against the
presented identifier is performed by comparing the set of domain presented identifier is performed by comparing the set of domain
components using a case-insensitive ASCII comparison, as clarified by components using a case-insensitive ASCII comparison, as clarified by
[DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to
"www.example.com" for comparison purposes). Each label MUST match in "www.example.com" for comparison purposes). Each label MUST match in
order for the names to be considered to match. order for the names to be considered to match.
3.4.2. Checking of Internationalized Domain Names 4.4.2. Checking of Internationalized Domain Names
[[ Editorial Note: This section needs to be updated to reflect
[IDNA2008]. ]]
The term "internationalized domain name" refers to a DNS domain name The term "internationalized domain name" refers to a DNS domain name
that conforms to the overall form of a domain name (dot-separated that conforms to the overall form of a domain name (dot-separated
labels) but that can include Unicode code points outside the labels) but that can include Unicode code points outside the
traditional US-ASCII range, as explained by [IDNA2003] and traditional US-ASCII range, as explained by and [IDNA2008].
[IDNA2008].
If the source domain of a reference identifier is an If the source domain of a reference identifier is an
internationalized domain name, then an implementation MUST convert internationalized domain name, then an implementation MUST convert
the domain name to the ASCII Compatible Encoding (ACE) format as every label in the domain name to an A-label before checking the
specified in Section 4 of [IDNA2003] before comparison; specifically, domain anme.
the conversion operation specified in Section 4 of [IDNA2003] MUST be
performed as follows:
o In step 1, the domain name SHALL be considered a "stored string".
o In step 3, set the flag called "UseSTD3ASCIIRules".
o In step 4, process each label with the "ToASCII" operation.
o In step 5, change all label separators to U+002E (full stop).
After performing the "to-ASCII" conversion with regard to an
internationalized domain name, the DNS labels and names MUST be
compared for equality according to the rules specified in Section 3
of [IDNA2003], i.e. once all label separators are replaced with
U+002E (dot) they are compared in a case-insensitive manner.
3.4.3. Checking of Wildcard Labels 4.4.3. Checking of Wildcard Labels
Unless forbidden by a specification that profiles the best practices Unless forbidden by a specification that profiles the best practices
defined herein, a client employing this specification's rules MAY defined herein, a client employing this specification's rules MAY
match the reference identifier against a presented identifier match the reference identifier against a presented identifier
containing one instance of the wildcard character '*', but only as containing one instance of the wildcard character '*', but only as
the left-most label of the domain name, e.g. *.example.com (following the left-most label of the domain name, e.g. *.example.com (following
the definition of "label" from [DNS]). the definition of "label" from [DNS]).
If such a wildcard identifier is presented, the wildcard MUST be used If such a wildcard identifier is presented, the wildcard MUST be used
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).
3.4.4. Checking of DNS Domain Names in Common Names 4.4.4. Checking of DNS Domain Names in 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 extensions
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
subjectAltName extensions of type dNSName, SRVName, or subjectAltName extensions 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 extensions supported by the client), the client MAY as a fallback
skipping to change at page 17, line 34 skipping to change at page 18, line 36
subjectName, where the last RDN is a Common Name that is intended to subjectName, where the last RDN is a Common Name that is intended to
represent a fully-qualified DNS domain name: represent a fully-qualified DNS domain name:
cn=www.example.com,c=GB,ou=Web Services cn=www.example.com,c=GB,ou=Web Services
Here the Common Name is "www.example.com" (a string whose form Here the Common Name is "www.example.com" (a string whose form
matches that of a fully-qualified DNS domain name) and the client matches that of a fully-qualified DNS domain name) and the client
could choose to compare a reference identifier of type CN-ID against could choose to compare a reference identifier of type CN-ID against
that string. When doing so, the client MUST follow the comparison 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, rules for the source domain of an identifier of type DNS-ID, SRV-ID,
or URI-ID, as described under Section 3.4. or URI-ID, as described under Section 4.4.
3.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 application
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 a specific kind of service, such as a web
site, an email service, or an instant messaging service. site, an email service, or an instant messaging service.
The application type is verified by means of either an SRV-ID or The application type is verified by means of either an SRV-ID or
URI-ID. URI-ID.
3.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.
3.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 therefore does not need to be included in any the URI, and therefore does not need to be included in any
comparison. comparison.
3.6. Outcome 4.6. Outcome
The outcome of the checking procedure is one of the following cases. The outcome of the checking procedure is one of the following cases.
3.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, matching has succeeded. In this case, the
client MUST use the matched reference identifier as the validated client MUST use the matched reference identifier as the validated
identity of the server. identity of the server.
3.6.2. Case #2: No Match Found, Cached Certificate 4.6.2. Case #2: No Match Found, Cached 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 but a natural person has permanently accepted reference identifiers but a natural person has permanently accepted
the certificate during a previous connection attempt or via the certificate during a previous connection attempt or via
configured preferences, the certificate is cached. In this case, the configured preferences, the certificate is cached. In this case, the
client MUST verify that the presented certificate matches the cached client MUST verify that the presented certificate matches the cached
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. connection was successfully negotiated (where causes of change
include but are not limited to changes in the DNS domain name,
identifiers, issuer, certification path, and expiration date).
3.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 server 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 server.
Instead, the client MUST proceed as follows. Instead, the client MUST proceed as follows.
3.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 certificate chain, (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 server 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 server 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 3.6.2. Cached Certificate" Section 4.6.2. However, the client MUST provide
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.
Informational Note: The guidelines provided here are roughly Informational Note: The guidelines provided here are roughly
consistent with those provided for web browsers and other HTTP- consistent with those provided for web browsers and other HTTP-
aware interactive clients in [WSC-UI]. aware interactive clients in [WSC-UI].
3.6.3.2. Automated Client 4.6.3.2. Automated Client
If the client is an automated application that is not directly If the client is an automated application that is not directly
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.
4. Security Considerations 5. Security Considerations
5.1. Service Delegation
4.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 application type MUST be provided by a human user
(e.g. when specifying the server portion of the user's account name (e.g. when specifying the server portion of the user's account name
on the server or when explicitly configuring the client to connect to on the server or when explicitly configuring the client to connect to
a particular host or URI as in [SIP-LOC]) and MUST NOT be derived a particular host or URI as in [SIP-LOC]) and MUST NOT be derived
from the user inputs in an automated fashion (e.g., a hostname from the user inputs in an automated fashion (e.g., a hostname
address discovered through DNS resolution of the source domain). address discovered through DNS resolution of the source domain).
This rule is important because only a match between the user inputs This rule is important because only a match between the user inputs
(in the form of a reference identifier) and a presented identifier (in 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 hostname
(called a "target domain") to be checked for connection purposes. (called a "target domain") to be checked for connection purposes.
4.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].
4.3. Internationalized Domain Names 5.3. Internationalized Domain Names
In addition to the wildcard certificate attacks previously mentioned, In addition to the wildcard certificate attacks previously mentioned,
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. IANA Considerations 6. IANA Considerations
This document has no actions for the IANA. This document specifies no actions for the IANA.
6. References 7. References
6.1. Normative References 7.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 21, line 11 skipping to change at page 22, line 20
Faltstrom, P., Hoffman, P., and A. Costello, Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[IDNA2008] [IDNA2008]
Klensin, J., "Internationalized Domain Names in Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", Applications (IDNA): Protocol",
draft-ietf-idnabis-protocol-18 (work in progress), draft-ietf-idnabis-protocol-18 (work in progress),
January 2010. January 2010.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol [LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(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.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
6.2. Informative References 7.2. Informative References
[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", February 2009, <http://www.blackhat.com/
presentations/bh-dc-09/Marlinspike/ 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.
skipping to change at page 31, line 42 skipping to change at page 33, line 4
form of the server hostname derived from an insecure remote source form of the server hostname derived from an insecure remote source
(e.g., insecure DNS lookup). CNAME canonicalization is not done. (e.g., insecure DNS lookup). CNAME canonicalization is not done.
If a subjectAltName extension of type dNSName is present in the If a subjectAltName extension of type dNSName is present in the
certificate, it SHOULD be used as the source of the server's certificate, it SHOULD be used as the source of the server's
identity. identity.
Matching is case-insensitive. Matching is case-insensitive.
A "*" wildcard character MAY be used as the leftmost name A "*" wildcard character MAY be used as the leftmost name
component in the certificate. For example, *.example.com would component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc., but would not match match a.example.com, foo.example.com, etc., but would not match
example.com. example.com.
If the certificate contains multiple names (e.g., more than one If the certificate contains multiple names (e.g., more than one
dNSName field), then a match with any one of the fields is dNSName field), then a match with any one of the fields is
considered acceptable. considered acceptable.
###### ######
A.5. XMPP (2004) A.5. XMPP (2004)
In 2004, [XMPP] specified the following text regarding server In 2004, [XMPP] specified the following text regarding server
identity verification in XMPP: identity verification in XMPP:
###### ######
14.2. Certificate Validation 14.2. Certificate Validation
When an XMPP peer communicates with another peer securely, it MUST When an XMPP peer communicates with another peer securely, it MUST
validate the peer's certificate. There are three possible cases: validate the peer's certificate. There are three possible cases:
Case #1: The peer contains an End Entity certificate which appears Case #1: The peer contains an End Entity certificate which appears
to be certified by a chain of certificates terminating in a trust to be certified by a certification path terminating in a trust
anchor (as described in Section 6.1 of [PKIX]). anchor (as described in Section 6.1 of [PKIX]).
Case #2: The peer certificate is certified by a Certificate Case #2: The peer certificate is certified by a Certificate
Authority not known to the validating peer. Authority not known to the validating peer.
Case #3: The peer certificate is self-signed. Case #3: The peer certificate is self-signed.
In Case #1, the validating peer MUST do one of two things: In Case #1, the validating peer MUST do one of two things:
1. Verify the peer certificate according to the rules of [PKIX]. 1. Verify the peer certificate according to the rules of [PKIX].
The certificate SHOULD then be checked against the expected The certificate SHOULD then be checked against the expected
identity of the peer following the rules described in [HTTP-TLS], identity of the peer following the rules described in [HTTP-TLS],
except that a subjectAltName extension of type "xmpp" MUST be except that a subjectAltName extension of type "xmpp" MUST be
used as the identity if present. If one of these checks fails, used as the identity if present. If one of these checks fails,
user-oriented clients MUST either notify the user (clients MAY user-oriented clients MUST either notify the user (clients MAY
give the user the opportunity to continue with the connection in give the user the opportunity to continue with the connection in
any case) or terminate the connection with a bad certificate any case) or terminate the connection with a bad certificate
error. Automated clients SHOULD terminate the connection (with a error. Automated clients SHOULD terminate the connection (with a
bad certificate error) and log the error to an appropriate audit bad certificate error) and log the error to an appropriate audit
log. Automated clients MAY provide a configuration setting that log. Automated clients MAY provide a configuration setting that
disables this check, but MUST provide a setting that enables it. disables this check, but MUST provide a setting that enables it.
2. The peer SHOULD show the certificate to a user for approval, 2. The peer SHOULD show the certificate to a user for approval,
including the entire certificate chain. 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, [XMPPBIS] refers to this document for At the time of this writing, [XMPPBIS] refers to this document for
rules regarding server identity verification in XMPP. rules regarding server identity verification in XMPP.
A.6. NNTP (2006) A.6. NNTP (2006)
In 2006, [NNTP-TLS] specified the following text regarding server In 2006, [NNTP-TLS] specified the following text regarding server
identity verification in NNTP: 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
skipping to change at page 38, line 21 skipping to change at page 39, line 31
For TLS authentication with pre-shared keys, the identity in the For TLS authentication with pre-shared keys, the identity in the
psk_identity_hint (for the server identity, i.e. the Responding node) psk_identity_hint (for the server identity, i.e. the Responding node)
or psk_identity (for the client identity, i.e. the Querying node) or psk_identity (for the client identity, i.e. the Querying node)
MUST be compared to the identities in the APD. MUST be compared to the identities in the APD.
###### ######
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Cisco Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
Jeff Hodges Jeff Hodges
PayPal PayPal
Email: Jeff.Hodges@PayPal.com Email: Jeff.Hodges@PayPal.com
 End of changes. 70 change blocks. 
175 lines changed or deleted 235 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/