draft-saintandre-tls-server-id-check-04.txt   draft-saintandre-tls-server-id-check-05.txt 
Network Working Group P. Saint-Andre, Ed. Network Working Group P. Saint-Andre, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP J. Hodges, Ed. Intended status: BCP J. Hodges, Ed.
Expires: November 1, 2010 PayPal Expires: November 13, 2010 PayPal
April 30, 2010 May 12, 2010
Representation and Verification of Application Server Identity in Representation and Verification of Domain-Based Application Server
Certificates Used with Transport Layer Security (TLS) Identity in Certificates Used with Transport Layer Security
draft-saintandre-tls-server-id-check-04 draft-saintandre-tls-server-id-check-05
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 November 1, 2010. This Internet-Draft will expire on November 13, 2010.
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 12 skipping to change at page 2, line 12
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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7 1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 8
1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 8
1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 7 1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
2. Representation of Server Identity . . . . . . . . . . . . . . 8 2. Representation of Server Identity . . . . . . . . . . . . . . 8
2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 8 2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 8
2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 9 2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 9
3. Verification of Server Identity . . . . . . . . . . . . . . . 10 3. Verification of Server Identity . . . . . . . . . . . . . . . 11
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Constructing an Ordered List of Reference Identifiers . . 10 3.2. Constructing an Ordered List of Reference Identifiers . . 11
3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 12 3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 13
3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 13 3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 13
3.4.1. Checking of Traditional Domain Names . . . . . . . . . 13 3.4.1. Checking of Traditional Domain Names . . . . . . . . . 14
3.4.2. Checking of Internationalized Domain Names . . . . . . 13 3.4.2. Checking of Internationalized Domain Names . . . . . . 14
3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 14 3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 15
3.4.4. Checking of DNS Domain Names in Common Names . . . . . 14 3.4.4. Checking of DNS Domain Names in Common Names . . . . . 15
3.5. Verifying an Application Type . . . . . . . . . . . . . . 15 3.5. Verifying an Application Type . . . . . . . . . . . . . . 16
3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 16 3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 16
3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 16 3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 17
3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 16 3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 17
3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 16 3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 17
3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 17 3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 17 4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 18
4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 17 4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 18
4.3. Internationalized Doman Names . . . . . . . . . . . . . . 18 4.3. Internationalized Doman Names . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.2. Informative References . . . . . . . . . . . . . . . . . . 19 6.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 23
A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 22 A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 24
A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 23 A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 24
A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 25 A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 26
A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 28 A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 29
A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 29 A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 30
A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 30 A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 31
A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 31 A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 32
A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 32 A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 34
A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 33 A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 35
A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 34 A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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], it application server using Transport Layer Security [TLS] (or, less
references some conception of the server's identity while attempting commonly, [DTLS]), it references some conception of the server's
to establish a secure connection (e.g., "the web site at identity while attempting to establish a secure connection (e.g.,
example.com"). Likewise, during TLS negotiation the server presents "the web site at example.com"). Likewise, during TLS negotiation the
its conception of the server's identity in the form of a public-key server presents its conception of the server's identity in the form
certificate that was issued by a certification authority in the of a public-key certificate that was issued by a certification
context of the Internet Public Key Infrastructure using X.509 [PKIX]. authority in the context of the Internet Public Key Infrastructure
Only a match between the client's reference identity and the server's using X.509 [PKIX]. Only a match between the client's reference
presented identity enables the client to be sure that the certificate identity and the server's presented identity enables the client to be
can legitimately be used to secure the connection. sure that the certificate can legitimately be used to secure 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 24 skipping to change at page 5, line 24
To codify best current practices regarding the implementation and To codify best current practices regarding the implementation and
deployment of secure PKIX-based authentication, this document deployment of secure PKIX-based authentication, this document
specifies recommended procedures for representing and verifying specifies recommended procedures for representing and verifying
server identities in certificates intended for use in applications server identities in certificates intended for use in applications
employing TLS. employing TLS.
1.2. Scope 1.2. Scope
This document applies only to server identities associated with DNS This document applies only to server identities associated with DNS
domain names, only to TLS, and only to PKIX-based systems. Similar domain names, only to TLS, and only to PKIX-based systems. As a
considerations might apply to client identities (e.g., for mutual result, the following scenarios are out of scope for this document:
authentication), to identifiers other than DNS domain names (e.g., IP
addresses), to security protocols other than TLS (e.g., [IPSEC] and o Client or end-user identities. It is true that certificates
[DTLS]), and to keys or certificates created outside the context of containing such identities can be used for mutual authentication
PKIX-based systems (e.g., on networks that use a web of trust model between a client and server or between two clients, thus enabling
based on [OPENPGP] or that are not directly connected to the public stronger client-server security or end-to-end security. However,
Internet and therefore cannot depend on Certificate Revocation Lists certification authorities, application developers, and service
(CRLs) or the Online Certificate Status Protocol (OCSP)). Although operators have less experience with client certificates than with
those scenarios might be able to re-use some aspects of the server certificates, thus gives us fewer models from which to
representation and verification rules provided here, they are outside generalize.
the scope of this document and need to be addressed by separate
specifications. o Identifiers other than DNS domain names. It is true that some
certification authorities issue server certificates based on
identifiers such as IP addresses. However, 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 first place.
o Security protocols other than [TLS] or [DTLS]. It is true that
some application technologies are built upon security foundations
such as [IPSEC]. However, here again the Internet community has
less experience with such technologies.
o Keys or certificates employed outside the context of PKIX-based
systems. It is true that some application technologies use a web
of trust model based on [OPENPGP], that some application
technologies (mostly) use self-signed certificates, and that some
networks are not directly connected to the public Internet and
therefore cannot depend on Certificate Revocation Lists (CRLs) or
the Online Certificate Status Protocol [OCSP] to check CA-issued
certificates. However, the syntax of OpenPGP keys differs
significantly from X.509 certificates, the data in self-signed
certificates has not been certified in any way, and checking of
CA-issued certificates via CRLs or OSCP is critically important to
maintaining the security of PKIX-based systems.
Therefore, although the foregoing scenarios are of inherent interest
and might be able to re-use many aspects of the representation and
verification rules provided here, they are outside the scope of this
document and need to be addressed by separate specifications.
Furthermore, this document also does not address various
certification authority policies, such as:
o Whether to issue certificates based on IP addresses instead of or
in addition to DNS domain names.
o What information will and will not be represented in a certificate
(e.g., whether to support the SRVName and
uniformResourceIdentifier extensions).
o How to certify or validate the information contained in a
certificate.
1.3. Terminology 1.3. Terminology
Because the concept of "identity" is too vague to be actionable in Because the concept of "identity" is too vague to be actionable in
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.
skipping to change at page 6, line 28 skipping to change at page 7, line 17
* 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
uniformResourceName uniformResourceName
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. controlled by a natural person. (Other specifications related to
security and application protocols often refer to this as a "user
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.
skipping to change at page 7, line 32 skipping to change at page 8, line 21
in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; in [TERMS]: "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. Discussion Venue 1.4. 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 direct 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>.
1.5. Contributors 1.5. 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.6. 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, Scott Cantor, for their feedback and suggestions: Nelson Bolyard, Scott Cantor,
Dave Crocker, Cyrus Daboo, Philip Guenther, Bruno Harbulot, David Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Bruno
Harrington, Paul Hoffman, Scott Lawrence, Alexey Melnikov, Ludwig Harbulot, David Harrington, Paul Hoffman, Geoff Keating, Scott
Nussel, Joe Orton, Tom Petch, Tim Polk, Pete Resnick, Joe Salowey, Lawrence, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom
and Dan Wing. Petch, Yngven Pettersen, Tim Polk, Pete Resnick, Martin Rex, Joe
Salowey, Rob Stradling, Dan Wing, and Dan Winship.
2. Representation of Server Identity 2. Representation of Server Identity
This section enumerates the rules for representing application server This section enumerates the rules for representing application server
identity in PKIX certificates. First we provide a brief tutorial identity in PKIX certificates. First we provide a brief tutorial
about subject naming, then we provide the rules. about subject naming, then we provide the rules.
2.1. Subject Naming in PKIX Certificates 2.1. 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
skipping to change at page 8, line 25 skipping to change at page 9, line 14
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 a X.501 type The subject field of a PKIX certificate is defined as an X.501 type
Name [PKIX] and known as a Distinguished Name (DN). See also [X.501] Name and known as a Distinguished Name (DN) -- see [X.501] and
A DN is an ordered sequence of attribute type and attribute value [PKIX]. A DN is an ordered sequence of Relative Distinguished Name
pairs (termed "attribute value assertions (AVAs)"), where the (RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
attributes are to be those of the subject. Each AVA is also termed a value pairs [LDAP-DN], each of which asserts some attribute about the
"Relative Distinguished Name (RDN)". The RDNs are ordered in the DN subject of the certificate. The RDNs are ordered in the DN sequence
sequence from most general to most specific. from most general to most specific.
Note that certificates are binary objects -- they are encoded using Note that certificates are binary objects -- they are encoded using
distinguished encoding rules (DER). Thus, displayable (aka distinguished encoding rules (DER). Thus, displayable (a.k.a.
printable) renderings of certificate subject (and issuer) names means printable) renderings of certificate subject (and issuer) names means
that the DER-encoded sequences are decoded and converted into a that the DER-encoded sequences are decoded and converted into a
"string representation" of a DN before being rendered. Often such a "string representation" of a DN before being rendered. Often such a
DN string representation is ordered from left-to-right, most specific DN string representation is ordered from left-to-right, most specific
to most general. See [LDAP-AUTH] for details. to most general. See [LDAP-AUTH] 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 DNS domain name [PKIX] o dNSName -- a DNS domain name [PKIX]
o SRVName -- a service name [SRVNAME] o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME]
o uniformResourceIdentifier -- a URI [URI] [PKIX] o uniformResourceIdentifier -- a Uniform Resource Identifier [URI]
[PKIX]
2.2. PKIX Certificate Name Rules 2.2. PKIX Certificate Name Rules
The following rules apply to the representation of application server When a certification authority issues a certificate based on the DNS
identities in PKIX certificates issued by certification authorities. domain name at which the server will provide the relevant service,
the following rules apply to the representation of application server
1. The certification authority MUST issue the certificate based on identities.
the DNS domain name (not an IP address) at which the server will
provide the relevant service.
2. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName
identifier of type dNSName). identifier of type dNSName).
3. 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]).
4. If the service using the certificate deploys a technology in 3. If the service using the certificate deploys a technology in
which a server is typically associated with a URI (e.g., this is which a server is typically associated with a URI (e.g., this is
true of [SIP]), then the certificate SHOULD include an URI-ID true of [SIP]), then the certificate SHOULD include an URI-ID
(i.e., a subjectAltName identifier of type (i.e., a subjectAltName identifier of type
uniformResourceIdentifier); the scheme SHALL be that of the uniformResourceIdentifier); the scheme SHALL be that of the
protocol associated with the application type and the authority protocol associated with the application type and the authority
component SHALL be the DNS domain name of the service. component SHALL be the DNS domain name of the service.
5. 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.
6. The DNS domain name portion of any identifier type MAY contain 5. The DNS domain name portion of any identifier type MAY contain
one instance of the wildcard character '*' (see [DNS-WILD]) but one instance of the wildcard character '*' (see [DNS-WILD]) but
only as the left-most label of the DNS domain name component of only as the left-most label of the DNS domain name component of
the identifier (following the definition of "label" from the identifier (following the definition of "label" from
[RFC1035]). An application protocol that employs the rules [RFC1035]). An application protocol that employs the rules
defined in this document MUST specify whether the wildcard defined in this document MUST specify whether the wildcard
character is or is not allowed in certificates issued for use character is or is not allowed in certificates issued for use
with that protocol; by default wildcard certificates SHOULD be with that protocol; by default wildcard certificates SHOULD be
disallowed. disallowed.
7. The certificate SHOULD NOT represent the server's DNS domain name 6. The certificate SHOULD NOT represent the server's DNS domain name
in a Relative Distinguished Name (RDN) of type Common Name (CN) in a Relative Distinguished Name (RDN) of type Common Name (CN)
(see [LDAP-SCHEMA]) within the subjectName field, even though it (see [LDAP-SCHEMA]) within the subjectName field, even though it
is recognized that many deployed clients still check for this is recognized that many deployed clients still check for this
legacy identifier configuration within certificate subjectName. legacy identifier configuration within certificate subjectName.
However, if this legacy identifer configuration is employed, then However, if this legacy identifer configuration is employed, then
the server's DNS domain name MUST be placed in the last (most the server's 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. encoded Name within the server's PKIX certificate.
8. The certificate MUST NOT represent the server's DNS domain name 7. The certificate MUST NOT represent the server's DNS domain name
by means of a series of Domain Component (DC) attributes (because by means of a series of Domain Component (DC) attributes (because
the order of Domain Components is not guaranteed, certain attacks the order of Domain Components is not guaranteed, certain attacks
are possible if DC attributes are included). are possible if DC attributes are included).
3. Verification of Server Identity 3. Verification of Server Identity
3.1. Overview 3.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. After the server provides its presented identifiers in the form 2. After the server provides its presented identifiers in the form
of an PKIX certificate, the client checks each of its reference of a PKIX certificate, the client checks each of its reference
identifiers against the presented identifiers for the purpose of identifiers against the presented identifiers for the purpose of
finding a match. finding a match.
3. When checking a reference identifier against a presented 3. When checking a reference identifier against a presented
identifier, the client (a) MUST match the source domain of the identifier, the client (a) MUST match the source domain of the
identifiers and (b) MAY also match the service type of the identifiers and (b) MAY also match the service type of the
identifiers. identifiers.
In addition to checking identifiers, a client MAY complete further In addition to checking identifiers, a client MAY complete further
checks to ensure that the server is authorized to provide the checks to ensure that the server is authorized to provide the
skipping to change at page 11, line 46 skipping to change at page 12, line 32
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.
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. In particular, this means that a client MUST NOT identifiers. In particular, this means that a client MUST NOT
check a series of Domain Component (DC) attributes if included in check a series of Domain Component (DC) attributes if included in
the certificate (because the order of Domain Components is not the certificate (because the order of Domain Components is not
guaranteed, certain attacks are possible if DC attributes are guaranteed, certain attacks are possible if DC attributes are
checked). checked).
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 DNS domain name and an o Reference identifiers that include both a DNS domain name and an
application type MUST be preferred over reference identifiers that application type MUST be preferred over reference identifiers that
include only a DNS domain name. Therefore an SRV-ID or URI-ID is include only a DNS domain name. Therefore an SRV-ID or URI-ID is
to be preferred over a DNS-ID. to be preferred over a DNS-ID.
o A reference identifier of type CN-ID (if included) MUST always be o Notwithstanding any of the foregoing rules, reference identifiers
the lowest-priority reference identifier in the list. 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 To illustrate the ordering rules, consider the case where the inputs
are a source domain of "im.example.com" and an application type of are a source domain of "im.example.com" and an application type of
"XMPP" (for which application servers are discovered via DNS SRV "XMPP" (for which application servers are discovered via DNS SRV
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. An SRV-ID of "_xmpp.im.example.com" 1. An SRV-ID of "_xmpp.im.example.com"
2. A DNS-ID of "im.example.com" 2. A DNS-ID of "im.example.com"
skipping to change at page 13, line 5 skipping to change at page 13, line 36
identifiers and has received the server's presented identifiers in identifiers and has received the server's presented identifiers in
the form of an PKIX certificate, the client checks its reference the form of an 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
sections. sections.
Note: A client MUST NOT seek a match for a reference identifier of Security Note: A client MUST NOT seek a match for a reference
CN-ID if the presented identifiers include an SRV-ID, URI-ID, identifier of CN-ID if the presented identifiers include an
DNS-ID, or any application-specific subjectAltName extensions, and SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
MUST NOT check a Common Name in the certificate if it is other extensions, and MUST NOT check a Common Name in the certificate if
than the last Relative Distinguished Name (RDN) in within the it is other than the last Relative Distinguished Name (RDN) in
sequence of RDNs making up the Distinguished Name within the within the sequence of RDNs making up the Distinguished Name
certificate's subjectName. (Note: The term "last" refers to the within the certificate's subjectName. (The term "last" refers to
DER order, which is often not the string order presented to a the DER order, which is often not the string order presented to a
user; the order that is applied here MUST be the DER order.) user; the order that is applied here MUST be the DER order.)
3.4. Verifying a Domain Name 3.4. Verifying a Domain Name
This document assumes that each reference identifier contains a DNS This document assumes that each reference identifier contains a DNS
domain name that is a "traditional domain name" or an domain name that is a "traditional domain name" or an
"internationalized domain name". The client MUST match the source "internationalized domain name". The client MUST match the source
domain of a reference identifier according to the following rules. domain of a reference identifier according to the following rules.
3.4.1. Checking of Traditional Domain Names 3.4.1. Checking of Traditional Domain Names
skipping to change at page 15, line 6 skipping to change at page 15, line 39
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.
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), the client MAY as a fallback check for a DNS domain name extensions), the client MAY as a fallback check for a DNS domain name
in the value of the last Relative Distinguished Name (RDN), if it is in the value of the last Relative Distinguished Name (RDN), if it is
of type Common Name (CN), within the sequence of RDNs making up the of type Common Name (CN), within the sequence of RDNs making up the
Distinguished Name within the certificate's subjectName. (Note: The Distinguished Name within the certificate's subjectName. (The term
term "last" refers to the DER order, which is often not the string "last" refers to the DER order, which is often not the string order
order presented to a user; the order that is applied here MUST be the presented to a user; the order that is applied here MUST be the DER
DER order.) order.)
In existing certificates, the CN is often used for representing a DNS In existing certificates, the CN is often used for representing a DNS
domain name; for example, consider the following subjectName, where domain name; for example, consider the following subjectName, where
the last RDN is a Common Name that is intended to represent a DNS the last RDN is a Common Name that is intended to represent a DNS
domain name: domain name:
ou=Web Services, c=GB, cn=www.example.com ou=Web Services, c=GB, cn=www.example.com
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 DNS domain name) and the client could choose to matches that of a DNS domain name) and the client could choose to
skipping to change at page 16, line 52 skipping to change at page 17, line 41
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 certificate chain, (b)
accept the certificate either temporarily (i.e., for this accept the certificate either temporarily (i.e., for this
connection attempt only) or permanently (i.e., for all future connection attempt only) or permanently (i.e., for all future
connection attempts), and then (c) continue with the connection connection attempts), and then (c) continue with the connection
attempt. attempt.
If a user permanently accepts a certificate, the client MUST cache If a user permanently accepts a certificate (an action referred to in
the certificate (or some non-forgeable representation such as a hash [WSC-UI] as "pinning"), the client MUST cache the certificate (or
value) and in future connection attempts MUST behave as in "Case #2: some non-forgeable representation such as a hash value) and in future
No Match Found, Cached Certificate". connection attempts MUST behave as in "Case #2: No Match Found,
Cached Certificate".
Note: It is the responsibility of the human user to verify the Security Note: It is the responsibility of the human user to
hash value or fingerprint of the certificate with the server over verify the hash value or fingerprint of the certificate with the
a trusted communication layer. server over a trusted communication layer.
Informational Note: The guidelines provided here are roughly
consistent with those provided for web browsers and other HTTP-
aware interactive clients in [WSC-UI].
3.6.3.2. Automated Client 3.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 18, line 31 skipping to change at page 19, line 24
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.
[LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
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.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
skipping to change at page 20, line 50 skipping to change at page 21, line 44
RFC 5539, May 2009. RFC 5539, May 2009.
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", [NNTP] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006. RFC 3977, October 2006.
[NNTP-TLS] [NNTP-TLS]
Murchison, K., Vinocur, J., and C. Newman, "Using Murchison, K., Vinocur, J., and C. Newman, "Using
Transport Layer Security (TLS) with Network News Transfer Transport Layer Security (TLS) with Network News Transfer
Protocol (NNTP)", RFC 4642, October 2006. Protocol (NNTP)", RFC 4642, October 2006.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet [RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
skipping to change at page 22, line 19 skipping to change at page 23, line 18
[US-ASCII] [US-ASCII]
American National Standards Institute, "Coded Character American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Set - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
[USINGTLS] [USINGTLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium
LastCall WD-wsc-ui-20100309, March 2010,
<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[X.501] International Telecommunications Union, "Information [X.501] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory: Technology - Open Systems Interconnection - The Directory:
Models", ITU-T Recommendation X.501, ISO Standard 9594-2, Models", ITU-T Recommendation X.501, ISO Standard 9594-2,
February 2001. February 2001.
[XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence [XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work
 End of changes. 36 change blocks. 
119 lines changed or deleted 179 lines changed or added

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