< draft-saintandre-tls-server-id-check-08.txt   draft-saintandre-tls-server-id-check-09.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco
Intended status: BCP J. Hodges Intended status: BCP J. Hodges
Expires: January 13, 2011 PayPal Expires: February 7, 2011 PayPal
July 12, 2010 August 6, 2010
Representation and Verification of Domain-Based Application Service 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-08 draft-saintandre-tls-server-id-check-09
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 services in representing and verifying the identity of application services 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 January 13, 2011. This Internet-Draft will expire on February 7, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6
1.4. Contributors . . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10 1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 11
1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 10 1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.7. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 11
2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Naming Application Services . . . . . . . . . . . . . . . 11 2.1. Naming Application Services . . . . . . . . . . . . . . . 11
2.2. Subject Naming in PKIX Certificates . . . . . . . . . . . 12 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 13
3. Representation of Server Identity . . . . . . . . . . . . . . 14 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 13
4. Verification of Server Identity . . . . . . . . . . . . . . . 15 3. Representation of Server Identity . . . . . . . . . . . . . . 15
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Verification of Server Identity . . . . . . . . . . . . . . . 16
4.2. Constructing an Ordered List of Reference Identifiers . . 16 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 17 4.2. Constructing a List of Reference Identifiers . . . . . . . 17
4.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 18
4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 18 4.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 18
4.4.1. Checking of Traditional Domain Names . . . . . . . . . 18 4.4.1. Checking of Traditional Domain Names . . . . . . . . . 19
4.4.2. Checking of Internationalized Domain Names . . . . . . 18 4.4.2. Checking of Internationalized Domain Names . . . . . . 19
4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 19 4.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 19
4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 19 4.4.4. Checking of Common Names . . . . . . . . . . . . . . . 19
4.5. Verifying an Application Type . . . . . . . . . . . . . . 20 4.5. Verifying an Application Type . . . . . . . . . . . . . . 20
4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 20 4.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 20
4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 20 4.6.2. Case #2: No Match Found, Cached Certificate . . . . . 21
4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 21 4.6.3. Case #3: No Match Found, Uncached Certificate . . . . 21
4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 21 4.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 21
4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 22 4.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 22 5.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 22
5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 22 5.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 22
5.3. Internationalized Domain Names . . . . . . . . . . . . . . 22 5.3. Internationalized Domain Names . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 services 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 services 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, Datagram Transport Layer Security [DTLS]), it references
identity while attempting to establish a secure connection (e.g., some conception of the server's identity while attempting to
"the web site at example.com"). Likewise, during TLS negotiation the establish a secure connection (e.g., "the web site at example.com").
server presents its conception of the server's identity in the form Likewise, during TLS negotiation the server presents its conception
of a public-key certificate that was issued by a certification of the server's identity in the form of a public-key certificate that
authority (CA) in the context of the Internet Public Key was issued by a certification authority (CA) in the context of the
Infrastructure using X.509 [PKIX]. Informally, we can think of these Internet Public Key Infrastructure using X.509 [PKIX]. Informally,
identities as the client's "reference identity" and the server's we can think of these identities as the client's "reference identity"
"presented identity" (these rough ideas are defined more precisely and the server's "presented identity" (these rough ideas are defined
later in this document through the concept of particular more precisely later in this document through the concept of
identifiers). In general, a client needs to verify that the server's particular identifiers). In general, a client needs to verify that
presented identity matches its reference identity so that it can be the server's presented identity matches its reference identity so
sure that the certificate can legitimately be used to authenticate that it can be sure that the certificate can legitimately be used to
the connection. 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 5, line 27 skipping to change at page 5, line 27
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.
Therefore, to codify best current practices regarding the Therefore, to codify best current practices regarding the
implementation and deployment of secure PKIX-based authentication, implementation and deployment of secure PKIX-based authentication,
this document specifies recommended procedures for representing and this document specifies recommended procedures for representing and
verifying server identities in certificates intended for use in verifying server identities in certificates intended for use in
applications employing TLS. applications employing TLS.
1.2. Scope 1.2. Applicability
1.2.1. In Scope This document does not supersede the rules for certificate validation
provided in [PKIX]; specifically, in order to ensure proper
authentication, application clients need to verify the entire
certification path (this document addresses only the DNS domain name
of the application service itself, not the entire trust chain). This
document also does not supersede the rules for verifying server
identity provided in existing application protocol specifications,
such as those mentioned under Appendix A. However, it is the intent
of the authors that the best current practices described here can be
referenced by future specifications. It is also expected that this
document will be updated or obsoleted in the future as best practices
for issuance and verification of PKIX certificates continue to evolve
through more widespread implementation and deployment of TLS-
protected application services over the Internet.
1.3. Scope
1.3.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 or DTLS (or the older
Secure Sockets Layer (SSL) technology), 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.3.2. Out of Scope
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
o Client or end-user identities. o Client or end-user identities.
Certificates representing client or end-user identities (e.g., the Certificates representing client or end-user identities (e.g., the
rfc822Name identifier) can be used for mutual authentication rfc822Name identifier) can be used for mutual authentication
between a client and server or between two clients, thus enabling between a client and server or between two clients, thus enabling
stronger client-server security or end-to-end security. However, stronger client-server security or end-to-end security. However,
certification authorities, application developers, and service certification authorities, application developers, and service
skipping to change at page 6, line 23 skipping to change at page 6, line 39
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 Furthermore, we focus here on the verification of application
service identities, not specific resources located at such
services, e.g., a specific web page that can be accessed at a
particular Uniform Resource Identifier [URI] whose authority
component is the DNS domain name of the application service. We
also do not address identifiers derived from Naming Authority
Pointer (NAPTR) DNS resource records [NAPTR] and related
technologies such as [S-NAPTR], since such identifiers cannot be
validated in a trusted manner in the absence of [DNSSEC].
Finally, we do not discuss attributes unrelated to DNS domain
names, such as those defined in [X.520] and other such names, such as those defined in [X.520] and other such
specification (e.g., organizational attributes, geographical specifications (e.g., organizational attributes, geographical
attributes, company logos, and the like). attributes, company logos, and the like).
o Security protocols other than [TLS] or [DTLS]. o Security protocols other than [TLS], [DTLS], or the older Secure
Sockets Layer (SSL) technology.
Although other secure, lower-layer protocols exist and even employ Although other secure, lower-layer protocols exist and even employ
PKIX certificates at times, e.g. [IPSEC], their use cases can PKIX certificates at times, e.g. IPsec [IPSEC], their use cases
differ from those of TLS-based or DTLS-based application can differ from those of TLS-based or DTLS-based application
technologies. Furthermore, application technologies have less technologies. Furthermore, application technologies have less
experience with IPsec than with TLS, thus making it more difficult experience with IPsec than with TLS, thus making it more difficult
to gather feedback on proposed best practices. to gather feedback on proposed best practices.
o Keys or certificates employed outside the context of PKIX-based o Keys or certificates employed outside the context of PKIX-based
systems. systems.
Some deployed application technologies use a web of trust model Some deployed application technologies use a web of trust model
based on or similar to [OPENPGP], or use self-signed certificates, based on or similar to OpenPGP [OPENPGP], or use self-signed
or are deployed on networks are not directly connected to the certificates, or are deployed on networks are not directly
public Internet and therefore cannot depend on Certificate connected to the public Internet and therefore cannot depend on
Revocation Lists (CRLs) or the Online Certificate Status Protocol Certificate Revocation Lists (CRLs) or the Online Certificate
[OCSP] to check CA-issued certificates. However, the syntax of Status Protocol [OCSP] to check CA-issued certificates. However,
OpenPGP keys differs essentially from X.509 certificates, the data the syntax of OpenPGP differs essentially from that of X.509, the
in self-signed certificates has not been certified by a third data in self-signed certificates has not been certified by a third
party in any way, and checking of CA-issued certificates via CRLs party in any way, and checking of CA-issued certificates via CRLs
or OSCP is critically important to maintaining the security of or OSCP is critically important to maintaining the security of
PKIX-based systems. Attempting to define best practices for such PKIX-based systems. Attempting to define best practices for such
technologies would unduly complicate the rules defined in this technologies would unduly complicate the rules defined in this
specification. specification.
Furthermore, this document also does not address various 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
skipping to change at page 7, line 31 skipping to change at page 8, line 13
application service types. application service types.
o How to certify or validate other kinds of information that might o How to certify or validate other kinds of information that might
be included in a certificate (e.g., organization name). 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.4. Terminology
Because many concepts related to "identity" are often too vague to be Because many concepts related to "identity" are often too vague to be
actionable in application protocols, we define a set of more concrete actionable in application protocols, we define a set of more concrete
terms for use in this specification. terms for use in this specification.
application service: A service on the Internet that enables application service: A service on the Internet that enables
interactive and automated clients to connect for the purpose of interactive and automated clients to connect for the purpose of
retrieving or uploading information, communicating with other retrieving or uploading information, communicating with other
entities, or connecting to a broader network of services. entities, or connecting to a broader network of services.
skipping to change at page 8, line 39 skipping to change at page 9, line 19
* URI-ID = a subjectAltName entry of type * URI-ID = a subjectAltName entry of type
uniformResourceIdentifier; see [PKIX] uniformResourceIdentifier; see [PKIX]
indirect name: A name for an application service that is resolved by indirect name: A name for an application service that is resolved by
a client based on a direct name provided by a user, resulting in a a client based on a direct name provided by a user, resulting in a
target domain and (optionally) a service type. 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, such as [WSC-UI], often refer
agent", e.g., [WSC-UI].) to this entity as a "user agent", however that term is neither
entirely accurate nor consistent with the terminology of common
application protocols such as [HTTP].)
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.
skipping to change at page 10, line 20 skipping to change at page 11, line 5
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.5. Contributors
The following individuals made important contributions to the text of The following individuals made important contributions to the text 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.6. 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, Wan-Teh Chang, Dave Crocker, Cyrus Daboo,
Philip Guenther, Bruno Harbulot, David Harrington, Paul Hoffman, Love Charles Gardiner, Philip Guenther, Bruno Harbulot, Wes Hardaker,
Hornquist Astrand, Harry Hotz, Geoff Keating, Scott Lawrence, Matt David Harrington, Paul Hoffman, Love Hornquist Astrand, Harry Hotz,
McCutchen, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey
Petch, Yngve Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, Martin Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve
Rex, Joe Salowey, Rob Stradling, Peter Sylvester, Dan Wing, and Dan Pettersen, Tim Polk, Eric Rescorla, Pete Resnick, Martin Rex, Joe
Winship. Salowey, Stefan Santesson, Rob Stradling, Peter Sylvester, Paul
Tiemann, Dan Wing, and Dan Winship.
1.6. Discussion Venue 1.7. 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>.
skipping to change at page 11, line 30 skipping to change at page 12, line 16
From the perspective of the application service, some names are From the perspective of the application service, some names are
unrestricted because they can be used in any type of service (e.g., a unrestricted because they can be used in any type of service (e.g., a
certificate might be re-used for both the HTTP service and the IMAP certificate might be re-used for both the HTTP service and the IMAP
service at example.com) whereas other names are restricted because service at example.com) whereas other names are restricted because
they can be used in only one type of service (e.g., a special-purpose they can be used in only one type of service (e.g., a special-purpose
certificate that can be used only for an IMAP service). This certificate that can be used only for an IMAP service). This
dimension matters 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 is direct (provided by a user) and unrestricted (can be
(can be used for any application). used for any application).
o A DNS-ID identifier is direct (provided by a user) and o A DNS-ID is direct (provided by a user) and unrestricted (can be
unrestricted (can be used for any application). used for any application).
o An SRV-ID identifier is indirect (resolved by a client) and o An SRV-ID can be either direct (provided by a user) or more
restricted (can be used for only a single application). typically indirect (resolved by a client) and is 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 is direct (provided by a user) and restricted (can be
(can be used for only a single application). 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 |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| DNS-ID | Yes | No | | DNS-ID | Yes | No |
+-----------+-----------+---------------+ +-----------+-----------+---------------+
| SRV-ID | No | Yes | | SRV-ID | Either | 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, application service providers, and client implementations, application service providers, and
certification authorities. Protocol specifications that reference certification authorities. Protocol specifications that reference
skipping to change at page 12, line 37 skipping to change at page 13, line 15
requirements differ across applications, it is impossible to requirements differ across applications, it is impossible to
categorically stipulate universal rules (e.g., that all software categorically stipulate universal rules (e.g., that all software
implementations, service providers, and certification authorities for implementations, service providers, and certification authorities for
all application protocols need to use or support DNS-IDs as a all application protocols need to use or support DNS-IDs as a
baseline for the purpose of interoperability); however, it is baseline for the purpose of interoperability); however, it is
preferable that each application protocol will at least define a 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,
application service providers, and CAs actively using or supporting application service providers, and CAs actively using or supporting
that technology. that technology.
2.2. Subject Naming in PKIX Certificates 2.2. DNS Domain Names
For the purposes of this specification, the name of an application
service MUST be a DNS domain name that conforms to one of the
following forms:
1. A "traditional domain name", i.e., a fully-qualified domain name
or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH
labels" as defined in [IDNA-DEFS]. Informally, such labels are
constrained to [US-ASCII] letters, digits, and the hyphen, with
the hyphen prohibited in the first character position.
Additional qualifications apply (please refer to the above-
referenced specifications for details) but they are not germane
to this specification.
2. An "internationalized domain name", i.e., a DNS domain name that
conforms to the overall form of a domain name (dot-separated
labels) but that can include Unicode code points outside the
traditional US-ASCII range or, more precisely, either U-labels or
A-labels as described in [IDNA-DEFS] and the associated
documents.
2.3. Subject Naming in PKIX Certificates
In theory, the Internet Public Key Infrastructure using X.509 [PKIX] In theory, the Internet Public Key Infrastructure using X.509 [PKIX]
employs the global directory service model defined in [X.500] and employs the global directory service model defined in [X.500] and
[X.501]. In this model, information is held in a directory [X.501]. In that model, information is held in a directory
information base (DIB) and entries in the DIB are organized in a information base (DIB) and entries in the DIB are organized in a
hierarchy called the directory information tree (DIT). An entry in hierarchy called the directory information tree (DIT). An object or
that hierarchy consists of a set of attributes (each of which has a alias entry in that hierarchy consists of a set of attributes (each
defined type and one or more values) and is uniquely identified by a of which has a defined type and one or more values) and is uniquely
Distinguished Name (DN). The DN of an entry is constructed by identified by a Distinguished Name (DN). The DN of an entry is
combining one or more specially-nominated attributes of the entry constructed by combining the Distinguished Name of its superior
itself (which together comprise the Relative Distinguished Name (RDN) entries in the tree (all the way down to the root of the DIT) with
of the entry) with the Distinguished Name of its superior entries in one or more specially-nominated attributes of the entry itself (which
the tree, up to the root of the DIT. An RDN is a set (i.e., an together comprise the Relative Distinguished Name (RDN) of the entry,
unordered group) of attribute-type-and-value pairs (see also so-called because it is relative to the Distinguished Names of the
[LDAP-DN]), each of which asserts some attribute about the entry. superior entries in the tree). The entry closest to the root is
sometimes referred to as the "most significant" entry and the entry
farthest from the root is sometimes referred to as the "least
significant" entry. An RDN is a set (i.e., an unordered group) of
attribute-type-and-value pairs (see also [LDAP-DN]), each of which
asserts some attribute about the entry.
In practice, the certificates used in [X.509] and [PKIX] borrow key In practice, the certificates used in [X.509] and [PKIX] borrow key
concepts of X.500 and X.501 (e.g., DNs and RDNs) to identify concepts of X.500 and X.501 (e.g., DNs and RDNs) to identify
entities, but such certificates are not necessarily part of a global entities, but such certificates are not necessarily part of a global
directory information base. Specifically, the subject field of a directory information base. Specifically, the subject field of a
PKIX certificate is an X.501 type Name that "identifies the entity PKIX certificate is an X.501 type Name that "identifies the entity
associated with the public key stored in the subject public key associated with the public key stored in the subject public key
field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly
acceptable for the subject field to be empty, as long as the acceptable for the subject field to be empty, as long as the
certificate contains a subjectAltName extension that includes at certificate contains a subjectAltName extension that includes at
skipping to change at page 13, line 33 skipping to change at page 14, line 40
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]
We recognize that existing certificates often use a CN-ID in the We recognize that existing certificates often use a CN-ID in the
subject field to represent a fully-qualified DNS domain name; for subject field to represent a fully-qualified DNS domain name; for
example, consider the following subjectName, where the attribute of example, consider the following subject name, where the attribute of
type Common Name contains a string whose form matches that of a type Common Name contains a string whose form matches that of a
fully-qualified DNS domain name of "www.example.com": fully-qualified DNS domain name of "www.example.com":
cn=www.example.com,c=GB,ou=Web Services cn=www.example.com,c=GB,ou=Web Services
However, in general, this specification recommends and prefers use of However, in general, this specification recommends and prefers use of
subjectAltName entries over use of the subject field where possible, subjectAltName entries over use of the subject field where possible,
as more completely described in the following sections. as more completely described in the following sections.
Implementation Note: Confusion sometimes arises from different Implementation Note: Confusion sometimes arises from different
skipping to change at page 14, line 11 skipping to change at page 15, line 22
sequences into a "string representation" before being displayed. sequences into a "string representation" before being displayed.
Because a Distinguished Name (DN) is an ordered sequence, order is Because a Distinguished Name (DN) is an ordered sequence, order is
preserved in the string representation of a DN. However, because preserved in the string representation of a DN. However, because
a Relative Distinguished Name (RDN) is an unordered group of a Relative Distinguished Name (RDN) is an unordered group of
attribute-type-and-value pairs, the string representation of an attribute-type-and-value pairs, the string representation of an
RDN can differ from the canonical DER encoding. Furthermore, RDN can differ from the canonical DER encoding. Furthermore,
various specifications refer to the order of RDNs using various specifications refer to the order of RDNs using
terminology that is not directly related to the information terminology that is not directly related to the information
hierarchy, such as "most specific" vs. "least specific", "left- hierarchy, such as "most specific" vs. "least specific", "left-
most" vs. "right-most", "first" vs. "last", or "most significant" most" vs. "right-most", "first" vs. "last", or "most significant"
vs. "least significant" (see for example [LDAP-DN]). In this vs. "least significant" (see for example [LDAP-DN]). To reduce
specification we avoid such terms in an effort to reduce confusion, in this specification we avoid such terms and instead
confusion. use the terms provided under Section 1.4; in particular, we do not
use the term "(most specific) Common Name field in the Subject
field" from [HTTP-TLS] and instead state that a CN-ID is a
Relative Distinguished Name (RDN) in the certificate subject that
contains one and only one attribute-type-and-value pair of type
Common Name (thus removing the possibility that an RDN might
contain multiple AVAs of type CN, one of which would be considered
"most specific").
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 application service fully-qualified DNS domain name at which the application service
provider will provide the relevant application, the following rules provider will provide the relevant application, the following rules
apply to the representation of application service identities. apply to the representation of application service identities.
1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
entry of type dNSName) if possible as a baseline for entry of type dNSName) if possible as a baseline for
skipping to change at page 14, line 50 skipping to change at page 16, line 23
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 CN-ID, even though many deployed clients DNS domain name in a CN-ID, even though many deployed clients
still check for this legacy identifier configuration within still check for this legacy identifier configuration within
certificate subjectName. If a CN-ID is included, the certificate subject name.
certificate's subject field SHOULD NOT contain more than one
CN-ID, 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 certificate MAY contain more than one DNS-ID, but SHOULD NOT
contain more than one CN-ID.
7. The fully-qualified DNS domain name portion of a DNS-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 reference the rules defined in this document
MUST specify whether the wildcard character is or is not allowed can specify that the wildcard character is not allowed in
in certificates issued under that profile; by default wildcard certificates used by the relevant application protocol or
certificates SHOULD NOT be allowed. community of interest.
4. Verification of Server Identity 4. Verification of Server Identity
4.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 application service's
performing the following actions: identity by performing the following actions:
1. Before connecting to the server, the client constructs an ordered 1. Before connecting to the server, the client constructs a list of
list of reference identifiers against which to check the reference identifiers against which to check the presented
presented identifiers. 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.
3. The client checks each of its reference identifiers against the 3. The client checks each of its reference identifiers against the
presented identifiers for the purpose of finding a match. presented identifiers for the purpose of finding a match.
4. When checking a reference identifier against a presented 4. When checking a reference identifier against a presented
identifier, the client (a) MUST match the source domain (or, in identifier, the client (a) MUST match the source domain (or, in
some cases, target domain) of the identifiers and (b) MAY also some cases, target domain) of the identifiers and (b) MAY also
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
identity presented in a certificate, and therefore methods for application service identity presented in a certificate, and
doing so (e.g., consulting local policy information) are out of therefore methods for doing so (e.g., consulting local policy
scope for this document. information) are out of scope for this document.
4.2. Constructing an Ordered List of Reference Identifiers 4.2. Constructing a List of Reference Identifiers
Before connecting to the server, the client MUST construct an ordered Before connecting to the server, the client MUST construct a list of
list of acceptable reference identifiers. 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 domain name 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 a service type. yield a source domain and a service type.
The client might need to derive the source domain and service type The client might need to derive the source domain and service type
from the input(s) it has received. The derived data MUST include from the input(s) it has received. The derived data MUST include
only information that can be securely parsed out of the inputs (e.g., only information that can be securely parsed out of the inputs (e.g.,
extracting the fully-qualified DNS domain name from the authority extracting the fully-qualified DNS domain name from the authority
component of a URI or extracting the service type from the scheme of component of a URI or extracting the service type from the scheme of
a URI) or information for which the derivation is performed in a a URI) or information for which the derivation is performed in a
secure manner (e.g., using [DNSSEC]). secure manner (e.g., using [DNSSEC]).
skipping to change at page 16, line 46 skipping to change at page 18, line 13
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 service type is typically discovered by means o If a server for the service type is typically discovered by means
of DNS SRV records , then the list SHOULD include an SRV-ID. of DNS SRV records, then the list SHOULD include an SRV-ID.
o If a server for the service type is typically associated with a o If a server for the service type is typically associated with a
URI, then the list SHOULD include a URI-ID URI, 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.
The client does not need to actually construct the foregoing Implementation Note: The client does not need to actually
identifiers in the formats found in a certificate (e.g., as ASN.1 construct the foregoing identifiers in the formats found in a
object identifiers), only the functional equivalent of such certificate (e.g., as ASN.1 types), only the functional equivalent
identifiers for matching purposes. 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 and MUST NOT check for such RDNs in the presented the Common Name and MUST NOT check for such RDNs in the presented
identifiers. identifiers.
The client then orders the list in accordance with the following
rules:
o Reference identifiers that include the source domain MUST be
preferred over reference identifiers that include a target domain
(if any).
o Reference identifiers that include both a fully-qualified DNS
domain name and a service type MUST be preferred over reference
identifiers that include only a fully-qualified DNS domain name.
Therefore an SRV-ID or URI-ID is to be preferred over a DNS-ID.
o Notwithstanding any of the foregoing rules, reference identifiers
of type CN-ID (if included) MUST always be the lowest-priority
reference identifiers in the list.
To illustrate the ordering rules, consider the case where the inputs
are a source domain of "im.example.com" and a service type of "XMPP"
(for which application services are discovered via DNS SRV records)
and the user of the client has also explicitly configured a target
domain of "hosting.example.net". In this case, the ordered list
would be:
1. SRV-ID of "_xmpp.im.example.com"
2. DNS-ID of "im.example.com"
3. SRV-ID of "_xmpp.hosting.example.net"
4. DNS-ID of "hosting.example.net"
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 list of reference identifiers and
identifiers and has received the server's presented identifiers in has received the server's presented identifiers in the form of a PKIX
the form of a PKIX certificate, the client checks its reference certificate, the client checks its reference identifiers against the
identifiers against the presented identifiers for the purpose of presented identifiers for the purpose of finding a match. It does so
finding a match. It does so by seeking a match in preference order by seeking a match and aborting the search if any presented
and aborting the search if any presented identifier matches one of identifier matches one of its reference identifiers. The search
its reference identifiers. The search fails if the client exhausts fails if the client exhausts its list of reference identifiers
its list of reference identifiers without finding a match. Detailed without finding a match. Detailed comparison rules for finding a
comparison rules for finding a match are provided in the following 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
entry types supported by the client. entry types supported by the client.
4.4. Verifying a Domain Name 4.4. Verifying a Domain Name
This document assumes that each reference identifier contains a The client MUST match the source domain of a reference identifier
fully-qualified DNS domain name that is a "traditional domain name" according to the following rules, depending on whether the source
or an "internationalized domain name". The client MUST match the domain is a "traditional domain name" or an "internationalized domain
source domain of a reference identifier according to the following name" as previously defined.
rules.
4.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
formal and accurate name: "traditional US-ASCII letter-digit-hyphen
DNS domain name". Traditional domain names are defined in
[DNS-CONCEPTS] and [DNS] in conjunction with [HOSTS] as further
explained in [IDNA2003]. In essence, a traditional domain name
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.,
"www.example.com"). Labels nominally consist of only [US-ASCII]
uppercase and lowercase letters, digits, and hyphen. There are
additional qualifications (please refer to the above-referenced
specifications for details) but they are not germane to this
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 name
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.
4.4.2. Checking of Internationalized Domain Names 4.4.2. Checking of Internationalized Domain Names
The term "internationalized domain name" refers to a DNS domain name
that conforms to the overall form of a domain name (dot-separated
labels) but that can include Unicode code points outside the
traditional US-ASCII range, as explained by and [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
every label in the domain name to an A-label before checking the every label in the domain name to an A-label before checking the
domain anme. domain name.
4.4.3. Checking of Wildcard Labels 4.4.3. Checking of Wildcard Labels
Unless forbidden by a specification that profiles the best practices A client employing this specification's rules MAY match the reference
defined herein, a client employing this specification's rules MAY identifier against a presented identifier containing one instance of
match the reference identifier against a presented identifier the wildcard character '*', but only as the left-most label of the
containing one instance of the wildcard character '*', but only as domain name, e.g. *.example.com (following the definition of "label"
the left-most label of the domain name, e.g. *.example.com (following 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).
A specification that references the rules defined in this document
can specify that the wildcard character is not allowed in
certificates used by the relevant application protocol or community
of interest.
4.4.4. Checking of Common Names 4.4.4. Checking of Common Names
As noted, a client MUST NOT seek a match for a reference identifier As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include 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 entry types 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 a Therefore, if and only if the set of identifiers does not include a
subjectAltName entry of type dNSName, SRVName, or subjectAltName entry of type dNSName, SRVName, or
uniformResourceIdentifier (or any application-specific subjectAltName uniformResourceIdentifier (or any application-specific subjectAltName
entry types 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 string whose form matches that of a fully-qualified DNS check for a string whose form matches that of a fully-qualified DNS
domain name in the CN-ID. If the client chooses to compare a domain name in the CN-ID. If the client chooses to compare a
reference identifier of type CN-ID against that string, it MUST reference identifier of type CN-ID against that string, it MUST
follow the comparison rules for the source domain of an identifier of 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. 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 A client SHOULD check not only the domain name but also the service
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 one kind of service, such as a web site, an designed to connect to one kind of service, such as a web site, an
email service, or an instant messaging service. email service, or an instant messaging service.
The service type is verified by means of either an SRV-ID or URI-ID. The service type is verified by means of either an SRV-ID or URI-ID.
4.5.1. SRV-ID 4.5.1. SRV-ID
skipping to change at page 21, line 20 skipping to change at page 21, line 32
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 service 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 service. 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 SHOULD inform the user of the identity
mismatch and terminate the connection automatically with a bad
1. Automatically terminate the connection with a bad certificate certificate error; this behavior is preferable because it prevents
error; or the majority of users from inadvertently bypassing security
protections in hostile situations.
2. Actively warn the user that the certificate is untrusted and
encourage the user to terminate the connection, but give advanced
users the option to (a) view the entire certification path, (b)
accept the certificate for this application service either
temporarily (i.e., for this connection attempt only) or
permanently (i.e., for all future connection attempts) despite
the identity mismatch, and then (c) continue with the connection
attempt.
If a user permanently accepts a certificate for this application
service despite an identity mismatch (an action referred to in
[WSC-UI] as "pinning"), the client MUST cache the certificate (or
some non-forgeable representation such as a hash value) and in future
connection attempts MUST behave as in "Case #2: No Match Found,
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
verify the hash value or fingerprint of the certificate with the
server over a trusted communication layer.
Informational Note: The guidelines provided here are roughly Security Note: Many existing interactive user agents give advanced
consistent with those provided for web browsers and other HTTP- users the option of proceeding despite an identity mismatch.
aware interactive clients in [WSC-UI]. Although this behavior can be appropriate in certain specialized
circumstances, in general it needs to be handled with extreme
caution, for example by first encouraging the user to terminate
the connection, forcing the user to view the entire certification
path, and allowing the user to accept the certificate only on a
temporary basis (i.e., for this connection attempt and all
subsequent connection attempts for the life of the application
session).
4.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.
skipping to change at page 23, line 24 skipping to change at page 23, line 24
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,
February 2000. February 2000.
[IDNA2003] [IDNA-DEFS]
Faltstrom, P., Hoffman, P., and A. Costello, Klensin, J., "Internationalized Domain Names for
"Internationalizing Domain Names in Applications (IDNA)", Applications (IDNA): Definitions and Document Framework",
RFC 3490, March 2003. RFC 5890, August 2010.
[IDNA2008]
Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol",
draft-ietf-idnabis-protocol-18 (work in progress),
January 2010.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.,
skipping to change at page 24, line 32 skipping to change at page 24, line 28
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[GIST] Schulzrinne, H. and M. Stiemerling, "GIST: General [GIST] Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[HOSTS] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP-TLS] [HTTP-TLS]
Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[IDNA-DEFS] [IDNA2003]
Klensin, J., "Internationalized Domain Names for Faltstrom, P., Hoffman, P., and A. Costello,
Applications (IDNA): Definitions and Document Framework", "Internationalizing Domain Names in Applications (IDNA)",
draft-ietf-idnabis-defs-13 (work in progress), RFC 3490, March 2003.
January 2010.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, [IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 25, line 29 skipping to change at page 25, line 21
[LDAP-SCHEMA] [LDAP-SCHEMA]
Sciberras, A., "Lightweight Directory Access Protocol Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, (LDAP): Schema for User Applications", RFC 4519,
June 2006. June 2006.
[LDAP-TLS] [LDAP-TLS]
Hodges, J., Morgan, R., and M. Wahl, "Lightweight Hodges, J., Morgan, R., and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000. Layer Security", RFC 2830, May 2000.
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[NETCONF-SSH] [NETCONF-SSH]
Wasserman, M. and T. Goddard, "Using the NETCONF Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)", RFC 4742, Configuration Protocol over Secure SHell (SSH)", RFC 4742,
December 2006. December 2006.
[NETCONF-TLS] [NETCONF-TLS]
Badra, M., "NETCONF over Transport Layer Security (TLS)", Badra, M., "NETCONF over Transport Layer Security (TLS)",
skipping to change at page 26, line 20 skipping to change at page 26, line 17
[PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [PRIVATE] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[PKIX-OLD] [PKIX-OLD]
Housley, R., Ford, W., Polk, T., and D. Solo, "Internet Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999. Profile", RFC 2459, January 1999.
[S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[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]
skipping to change at page 32, line 14 skipping to change at page 32, line 14
available subjectAltName types to which the reference identity can be available subjectAltName types to which the reference identity can be
mapped; however, the reference identity should only be mapped to mapped; however, the reference identity should only be mapped to
types for which the mapping is either inherently secure (e.g., types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure of type dNSName) or for which the mapping is performed in a secure
manner (e.g., using [DNSSEC], or using user- or admin-configured manner (e.g., using [DNSSEC], or using user- or admin-configured
host-to-address/address-to-host lookup tables). host-to-address/address-to-host lookup tables).
The server's identity may also be verified by comparing the reference The server's identity may also be verified by comparing the reference
identity to the Common Name (CN) [LDAP-SCHEMA] value in the last identity to the Common Name (CN) [LDAP-SCHEMA] value in the last
Relative Distinguished Name (RDN) of the subjectName field of the Relative Distinguished Name (RDN) of the subject name field of the
server's certificate (where "last" refers to the DER-encoded order, server's certificate (where "last" refers to the DER-encoded order,
not the order of presentation in a string representation of DER- not the order of presentation in a string representation of DER-
encoded data). This comparison is performed using the rules for encoded data). This comparison is performed using the rules for
comparison of DNS names in Section 3.1.3.1, below, with the exception comparison of DNS names in Section 3.1.3.1, below, with the exception
that no wildcard matching is allowed. Although the use of the Common that no wildcard matching is allowed. Although the use of the Common
Name value is existing practice, it is deprecated, and Certification Name value is existing practice, it is deprecated, and Certification
Authorities are encouraged to provide subjectAltName values instead. Authorities are encouraged to provide subjectAltName values instead.
Note that the TLS implementation may represent DNs in certificates Note that the TLS implementation may represent DNs in certificates
according to X.500 or other conventions. For example, some X.500 according to X.500 or other conventions. For example, some X.500
implementations order the RDNs in a DN using a left-to-right (most implementations order the RDNs in a DN using a left-to-right (most
skipping to change at page 41, line 21 skipping to change at page 41, line 21
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 Systems, Inc. Cisco
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 2211 North First Street
 End of changes. 65 change blocks. 
238 lines changed or deleted 246 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/