draft-ietf-uta-rfc6125bis-01.txt   draft-ietf-uta-rfc6125bis-02.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Mozilla Internet-Draft Mozilla
Obsoletes: 6125 (if approved) J. Hodges Obsoletes: 6125 (if approved) J. Hodges
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: 9 January 2022 R. Salz Expires: 12 March 2022 R. Salz
Akamai Technologies Akamai Technologies
8 July 2021 8 September 2021
Representation and Verification of Domain-Based Application Service Representation and Verification of Domain-Based Application Service
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
Certificates in the Context of Transport Layer Security (TLS) Certificates in the Context of Transport Layer Security (TLS)
draft-ietf-uta-rfc6125bis-01 draft-ietf-uta-rfc6125bis-02
Abstract Abstract
Many application technologies enable secure communication between two Many application technologies enable secure communication between two
entities by means of Transport Layer Security (TLS) with Internet entities by means of Transport Layer Security (TLS) with Internet
Public Key Infrastructure Using X.509 (PKIX) certificates. This Public Key Infrastructure Using X.509 (PKIX) certificates. This
document specifies procedures for representing and verifying the document specifies procedures for representing and verifying the
identity of application services in such interactions. identity of application services in such interactions.
Discussion Venues Discussion Venues
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 9 January 2022. This Internet-Draft will expire on 12 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. How to Read This Document . . . . . . . . . . . . . . . . 4 1.3. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 4
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.4. How to Read This Document . . . . . . . . . . . . . . . . 5
1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5 1.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Overview of Recommendations . . . . . . . . . . . . . . . 6
1.6.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 6 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 6 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 7
1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
2. Naming of Application Services . . . . . . . . . . . . . . . 12 2. Naming of Application Services . . . . . . . . . . . . . . . 12
2.1. Naming Application Services . . . . . . . . . . . . . . . 12 2.1. Naming Application Services . . . . . . . . . . . . . . . 12
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14
3. Designing Application Protocols . . . . . . . . . . . . . . . 15 3. Designing Application Protocols . . . . . . . . . . . . . . . 14
4. Representing Server Identity . . . . . . . . . . . . . . . . 16 4. Representing Server Identity . . . . . . . . . . . . . . . . 15
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Requesting Server Certificates . . . . . . . . . . . . . . . 18 5. Requesting Server Certificates . . . . . . . . . . . . . . . 16
6. Verifying Service Identity . . . . . . . . . . . . . . . . . 19 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 17
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Constructing a List of Reference Identifiers . . . . . . 19 6.2. Constructing a List of Reference Identifiers . . . . . . 18
6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 22 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 22 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 21
6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 24 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 22
6.4.1. Checking of Traditional Domain Names . . . . . . . . 24 6.4.1. Checking of Traditional Domain Names . . . . . . . . 22
6.4.2. Checking of Internationalized Domain Names . . . . . 24 6.4.2. Checking of Internationalized Domain Names . . . . . 22
6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 24 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 23
6.5. Matching the Application Service Type Portion . . . . . . 25
6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 25 6.5. Matching the Application Service Type Portion . . . . . . 23
6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 26 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 24
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 24
6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 26 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 26 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 24
6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 26 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 24
6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 26 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 27 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 25
7.3. Internationalized Domain Names . . . . . . . . . . . . . 28 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 26
7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 28 7.3. Internationalized Domain Names . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
1.1. Motivation 1.1. Motivation
The visible face of the Internet largely consists of services that The visible face of the Internet largely consists of services that
employ a client-server architecture in which an interactive or employ a client-server architecture in which an interactive or
automated client communicates with an application service in order to automated client communicates with an application service in order to
retrieve or upload information, communicate with other entities, or retrieve or upload information, communicate with other entities, or
access a broader network of services. When a client communicates access a broader network of services. When a client communicates
skipping to change at page 4, line 30 skipping to change at page 4, line 30
The primary audience for this document consists of application The primary audience for this document consists of application
protocol designers, who can reference this document instead of protocol designers, who can reference this document instead of
defining their own rules for the representation and verification of defining their own rules for the representation and verification of
application service identity. Secondarily, the audience consists of application service identity. Secondarily, the audience consists of
certification authorities, service providers, and client developers certification authorities, service providers, and client developers
from technology communities that might reuse the recommendations in from technology communities that might reuse the recommendations in
this document when defining certificate issuance policies, generating this document when defining certificate issuance policies, generating
certificate signing requests, or writing software algorithms for certificate signing requests, or writing software algorithms for
identity matching. identity matching.
1.3. How to Read This Document 1.3. Changes since RFC 6125
This document revises and obsoletes [VERIFY] based on the decade of
experience and changes since it was first published. The major
changes, in no particular order, include:
* All references have been updated to the current latest version.
* The TLS SNI extension is no longer new, it is commonplace.
* The only legal place for a certificate wildcard name is as the
left-most component in a domain name.
* It is no longer allowed to use the commonName RDN, known as "CN-
ID", to represent the server identity; only the subjectAltNames
extension is used.
* References to the X.500 directory, the survey of prior art, and
the sample text in Appendix A have been removed.
1.4. How to Read This Document
This document is longer than the authors would have liked because it This document is longer than the authors would have liked because it
was necessary to carefully define terminology, explain the underlying was necessary to carefully define terminology, explain the underlying
concepts, define the scope, and specify recommended behavior for both concepts, define the scope, and specify recommended behavior for both
certification authorities and application software implementations. certification authorities and application software implementations.
The following sections are of special interest to various audiences: The following sections are of special interest to various audiences:
* Protocol designers might want to first read the checklist in * Protocol designers might want to first read the checklist in
Section 3. Section 3.
* Certification authorities might want to first read the * Certification authorities might want to first read the
recommendations for representation of server identity in recommendations for representation of server identity in
Section 4. Section 4.
* Service providers might want to first read the recommendations for * Service providers might want to first read the recommendations for
requesting of server certificates in Section 5. requesting of server certificates in Section 5.
* Software implementers might want to first read the recommendations * Software implementers might want to first read the recommendations
for verification of server identity in Section 6. for verification of server identity in Section 6.
The sections on terminology (Section 1.7), naming of application The sections on terminology (Section 1.8), naming of application
services (Section 2), document scope (Section 1.6), and the like services (Section 2), document scope (Section 1.7), and the like
provide useful background information regarding the recommendations provide useful background information regarding the recommendations
and guidelines that are contained in the above-referenced sections, and guidelines that are contained in the above-referenced sections,
but are not absolutely necessary for a first reading of this but are not absolutely necessary for a first reading of this
document. document.
1.4. Applicability 1.5. Applicability
This document does not supersede the rules for certificate issuance This document does not supersede the rules for certificate issuance
or validation provided in [PKIX]. Therefore, [PKIX] is authoritative or validation provided in [PKIX]. Therefore, [PKIX] is authoritative
on any point that might also be discussed in this document. on any point that might also be discussed in this document.
Furthermore, [PKIX] also governs any certificate-related topic on Furthermore, [PKIX] also governs any certificate-related topic on
which this document is silent, including but not limited to which this document is silent, including but not limited to
certificate syntax, certificate extensions such as name constraints certificate syntax, certificate extensions such as name constraints
and extended key usage, and handling of certification paths. and extended key usage, and handling of certification paths.
This document addresses only name forms in the leaf "end entity" This document addresses only name forms in the leaf "end entity"
skipping to change at page 5, line 35 skipping to change at page 6, line 12
ensure proper authentication, application clients need to verify the ensure proper authentication, application clients need to verify the
entire certification path per [PKIX]. entire certification path per [PKIX].
This document also does not supersede the rules for verifying service This document also does not supersede the rules for verifying service
identity provided in specifications for existing application identity provided in specifications for existing application
protocols published prior to this document. However, the procedures protocols published prior to this document. However, the procedures
described here can be referenced by future specifications, including described here can be referenced by future specifications, including
updates to specifications for existing application protocols if the updates to specifications for existing application protocols if the
relevant technology communities agree to do so. relevant technology communities agree to do so.
1.5. Overview of Recommendations 1.6. Overview of Recommendations
To orient the reader, this section provides an informational overview To orient the reader, this section provides an informational overview
of the recommendations contained in this document. of the recommendations contained in this document.
The previous version of this specification, [VERIFY], surveyed the The previous version of this specification, [VERIFY], surveyed the
current practice from many IETF standards and tried to generalize current practice from many IETF standards and tried to generalize
best practices. This document takes the lessons learned in the past best practices. This document takes the lessons learned in the past
decade and codifies them as best practices. decade and codifies them as best practices.
For the primary audience of application protocol designers, this For the primary audience of application protocol designers, this
skipping to change at page 6, line 20 skipping to change at page 6, line 46
* Move toward including and checking even more specific * Move toward including and checking even more specific
subjectAlternativeName extensions where appropriate for using the subjectAlternativeName extensions where appropriate for using the
protocol (e.g., uniformResourceIdentifier and the otherName form protocol (e.g., uniformResourceIdentifier and the otherName form
SRVName). SRVName).
* Constrain and simplify the validation of wildcard certificates * Constrain and simplify the validation of wildcard certificates
(e.g., a certificate containing an identifier for (e.g., a certificate containing an identifier for
"*.example.com"). "*.example.com").
1.6. Scope 1.7. Scope
1.7.1. In Scope
1.6.1. In Scope
This document applies only to service identities associated with This document applies only to service identities associated with
fully qualified DNS domain names, only to TLS and DTLS (or the older fully qualified DNS domain names, only to TLS and DTLS, and only to
Secure Sockets Layer (SSL) technology), and only to PKIX-based PKIX-based systems. As a result, the scenarios described in the
systems. As a result, the scenarios described in the following following section are out of scope for this specification (although
section are out of scope for this specification (although they might they might be addressed by future specifications).
be addressed by future specifications).
1.6.2. Out of Scope 1.7.2. Out of Scope
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
* Client or end-user identities. * Client or end-user identities.
Certificates representing client or end-user identities (e.g., the Certificates representing client or end-user identities (e.g., the
rfc822Name identifier) can be used for mutual authentication rfc822Name identifier) can be used for mutual authentication
between a client and server or between two clients, thus enabling between a client and server or between two clients, thus enabling
stronger client-server security or end-to-end security. However, stronger client-server security or end-to-end security. However,
certification authorities, application developers, and service certification authorities, application developers, and service
operators have less experience with client certificates than with operators have less experience with client certificates than with
server certificates, thus giving us fewer models from which to server certificates, thus giving us fewer models from which to
generalize and a less solid basis for defining best practices. generalize and a less solid basis for defining best practices.
* Identifiers other than fully qualified DNS domain names. * Identifiers other than fully qualified DNS domain names.
Some certification authorities issue server certificates based on For example, this specification does not discuss IP addresses or
IP addresses, but preliminary evidence indicates that such other attributes within a certificate beyond the subjectAltName
certificates are a very small percentage (less than 1%) of issued extension. The focus of this document is on application service
certificates. Furthermore, IP addresses are not necessarily identities, not specific resources located at such services.
reliable identifiers for application services because of the Therefore this document discusses Uniform Resource Identifiers
existence of private internets [PRIVATE], host mobility, multiple [URI] only as a way to communicate a DNS domain name (via the URI
interfaces on a given host, Network Address Translators (NATs) "host" component or its equivalent), not as a way to communicate
resulting in different addresses for a host from different other aspects of a service such as a specific resource (via the
locations on the network, the practice of grouping many hosts URI "path" component) or parameters (via the URI "query"
together behind a single IP address, etc. Most fundamentally, component).
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. We prefer to define best practices for the much more
common use case and not to complicate the rules in this
specification.
Furthermore, we focus here on application service identities, not
specific resources located at such services. Therefore this
document discusses Uniform Resource Identifiers [URI] only as a
way to communicate a DNS domain name (via the URI "host" component
or its equivalent), not as a way to communicate other aspects of a
service such as a specific resource (via the URI "path" component)
or parameters (via the URI "query" component).
We also do not discuss attributes unrelated to DNS domain names,
such as those defined in [X.520] and other such specifications
(e.g., organizational attributes, geographical attributes, company
logos, and the like).
* Security protocols other than [TLS], [DTLS], or the older Secure * Security protocols other than [TLS] or [DTLS].
Sockets Layer (SSL) technology.
Although other secure, lower-layer protocols exist and even employ Although other secure, lower-layer protocols exist and even employ
PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases
can differ from those of TLS-based and DTLS-based application can differ from those of TLS-based and DTLS-based application
technologies. Furthermore, application technologies have less technologies. Furthermore, application technologies have less
experience with IPsec than with TLS, thus making it more difficult experience with IPsec than with TLS, thus making it more difficult
to gather feedback on proposed best practices. to gather feedback on proposed best practices.
* Keys or certificates employed outside the context of PKIX-based * Keys or certificates employed outside the context of PKIX-based
systems. systems.
skipping to change at page 8, line 45 skipping to change at page 9, line 10
resolution process. Thus the resolution process itself is out of resolution process. Thus the resolution process itself is out of
scope for this specification. scope for this specification.
* User interface issues. * User interface issues.
In general, such issues are properly the responsibility of client In general, such issues are properly the responsibility of client
software developers and standards development organizations software developers and standards development organizations
dedicated to particular application technologies (see, for dedicated to particular application technologies (see, for
example, [WSC-UI]). example, [WSC-UI]).
1.7. Terminology 1.8. 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.
application service provider: An organization or individual that application service provider: An organization or individual that
hosts or deploys an application service. hosts or deploys an application service.
application service type: A formal identifier for the application application service type: A formal identifier for the application
protocol used to provide a particular kind of application service protocol used to provide a particular kind of application service
at a domain; the application service type typically takes the form at a domain; the application service type typically takes the form
of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service
[DNS-SRV]. [DNS-SRV].
attribute-type-and-value pair: A colloquial name for the ASN.1-based
construction comprising a Relative Distinguished Name (RDN), which
itself is a building-block component of Distinguished Names. See
Section 2 of [LDAP-DN].
automated client: A software agent or device that is not directly automated client: A software agent or device that is not directly
controlled by a human user. controlled by a human user.
delegated domain: A domain name or host name that is explicitly delegated domain: A domain name or host name that is explicitly
configured for communicating with the source domain, by either (a) configured for communicating with the source domain, by either (a)
the human user controlling an interactive client or (b) a trusted the human user controlling an interactive client or (b) a trusted
administrator. In case (a), one example of delegation is an administrator. In case (a), one example of delegation is an
account setup that specifies the domain name of a particular host account setup that specifies the domain name of a particular host
to be used for retrieving information or connecting to a network, to be used for retrieving information or connecting to a network,
which might be different from the server portion of the user's which might be different from the server portion of the user's
skipping to change at page 11, line 14 skipping to change at page 11, line 17
a client within a PKIX certificate when the client attempts to a client within a PKIX certificate when the client attempts to
establish secure communication with the server; the certificate establish secure communication with the server; the certificate
can include one or more presented identifiers of different types, can include one or more presented identifiers of different types,
and if the server hosts more than one domain then the certificate and if the server hosts more than one domain then the certificate
might present distinct identifiers for each domain. might present distinct identifiers for each domain.
reference identifier: An identifier, constructed from a source reference identifier: An identifier, constructed from a source
domain and optionally an application service type, used by the domain and optionally an application service type, used by the
client for matching purposes when examining presented identifiers. client for matching purposes when examining presented identifiers.
Relative Distinguished Name (RDN): The ASN.1-based construction
comprising a Relative Distinguished Name (RDN), which itself is a
building-block component of Distinguished Names. See [LDAP-DN],
Section 2.
source domain: The fully qualified DNS domain name that a client source domain: The fully qualified DNS domain name that a client
expects an application service to present in the certificate expects an application service to present in the certificate
(e.g., "www.example.com"), typically input by a human user, (e.g., "www.example.com"), typically input by a human user,
configured into a client, or provided by reference such as in a configured into a client, or provided by reference such as in a
hyperlink. The combination of a source domain and, optionally, an hyperlink. The combination of a source domain and, optionally, an
application service type enables a client to construct one or more application service type enables a client to construct one or more
reference identifiers. reference identifiers.
subjectAltName entry: An identifier placed in a subjectAltName subjectAltName entry: An identifier placed in a subjectAltName
extension. extension.
subjectAltName extension: A standard PKIX certificate extension subjectAltName extension: A standard PKIX certificate extension
[PKIX] enabling identifiers of various types to be bound to the [PKIX] enabling identifiers of various types to be bound to the
certificate subject -- in addition to, or in place of, identifiers certificate subject.
that may be embedded within or provided as a certificate's subject
field.
subject field: The subject field of a PKIX certificate identifies
the entity associated with the public key stored in the subject
public key field (see Section 4.1.2.6 of [PKIX]).
subject name: In an overall sense, a subject's name(s) can be subject name: In this specification, the term refers to the name of
represented by or in the subject field, the subjectAltName a PKIX certificate's subject, encoded in a certificate's subject
extension, or both (see [PKIX] for details). More specifically, field (see [PKIX], Section 4.1.2.6).
the term often refers to the name of a PKIX certificate's subject,
encoded as the X.501 type Name and conveyed in a certificate's
subject field (see Section 4.1.2.6 of [PKIX]).
TLS client: An entity that assumes the role of a client in a TLS client: An entity that assumes the role of a client in a
Transport Layer Security [TLS] negotiation. In this specification Transport Layer Security [TLS] negotiation. In this specification
we generally assume that the TLS client is an (interactive or we generally assume that the TLS client is an (interactive or
automated) application client; however, in application protocols automated) application client; however, in application protocols
that enable server-to-server communication, the TLS client could that enable server-to-server communication, the TLS client could
be a peer application service. be a peer application service.
TLS server: An entity that assumes the role of a server in a TLS server: An entity that assumes the role of a server in a
Transport Layer Security [TLS] negotiation; in this specification Transport Layer Security [TLS] negotiation; in this specification
skipping to change at page 13, line 5 skipping to change at page 13, line 5
service at example.com), whereas other names are restricted because service at example.com), whereas other names are restricted because
they can be used in only one type of service (e.g., a special-purpose they can be used in only one type of service (e.g., a special-purpose
certificate that can be used only for an IMAP service). This certificate that can be used only for an IMAP service). This
dimension matters most for certificate issuance. dimension matters most for certificate issuance.
Therefore, we can categorize the identifier types of interest as Therefore, we can categorize the identifier types of interest as
follows: follows:
* A DNS-ID is direct and unrestricted. * A DNS-ID is direct and unrestricted.
* An SRV-ID can be either direct or (more typically) indirect, and * An SRV-ID is typically indirect but can be direct, and is
is restricted. restricted.
* A URI-ID is direct and restricted. * A URI-ID is direct and restricted.
We summarize this taxonomy in the following table.
+-----------+-----------+---------------+
| | Direct | Restricted |
+-----------+-----------+---------------+
| DNS-ID | Yes | No |
+-----------+-----------+---------------+
| SRV-ID | Either | 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. Ideally, protocol specifications that certification authorities. Ideally, protocol specifications that
reference this document will specify which identifiers are mandatory- reference this document will specify which identifiers are mandatory-
to-implement by servers and clients, which identifiers ought to be to-implement by servers and clients, which identifiers ought to be
supported by certificate issuers, and which identifiers ought to be supported by certificate issuers, and which identifiers ought to be
requested by application service providers. Because these requested by application service providers. Because these
skipping to change at page 14, line 25 skipping to change at page 14, line 10
conforms to the overall form of a domain name (informally, dot- conforms to the overall form of a domain name (informally, dot-
separated letter-digit-hyphen labels) but includes at least one separated letter-digit-hyphen labels) but includes at least one
label containing appropriately encoded Unicode code points label containing appropriately encoded Unicode code points
outside the traditional US-ASCII range. That is, it contains at outside the traditional US-ASCII range. That is, it contains at
least one U-label or A-label, but otherwise may contain any least one U-label or A-label, but otherwise may contain any
mixture of NR-LDH labels, A-labels, or U-labels, as described in mixture of NR-LDH labels, A-labels, or U-labels, as described in
[IDNA-DEFS] and the associated documents. [IDNA-DEFS] and the associated documents.
2.3. Subject Naming in PKIX Certificates 2.3. Subject Naming in PKIX Certificates
In theory, the Internet Public Key Infrastructure using X.509 [PKIX]
employs the global directory service model defined in [X.500] and
[X.501]. Under that model, information is held in a directory
information base (DIB) and entries in the DIB are organized in a
hierarchy called the directory information tree (DIT). An object or
alias entry in that hierarchy consists of a set of attributes (each
of which has a defined type and one or more values) and is uniquely
identified by a Distinguished Name (DN). The DN of an entry is
constructed by combining the Relative Distinguished Names of its
superior entries in the tree (all the way down to the root of the
DIT) with one or more specially nominated attributes of the entry
itself (which together comprise the Relative Distinguished Name (RDN)
of the entry, so-called because it is relative to the Distinguished
Names of the superior entries in the tree). The entry closest to the
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
concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify
entities, but such certificates are not necessarily part of a global
directory information base. Specifically, the subject field of a
PKIX certificate is an X.501 type Name that "identifies the entity
associated with the public key stored in the subject public key
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
certificate contains a subject alternative name ("subjectAltName")
extension that includes at least one subjectAltName entry, because
the subjectAltName extension allows various identities to be bound to
the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName
extension itself is a sequence of typed entries, where each type is a
distinct kind of identifier.
For our purposes, an application service can be identified by a name For our purposes, an application service can be identified by a name
or names carried in one or more of the following identifier types or names carried in one or more of the following identifier types
within subjectAltName entries: within subjectAltName entries:
* DNS-ID * DNS-ID
* SRV-ID * SRV-ID
* URI-ID * URI-ID
The Common Name RDN should not be used to identify a service. The Common Name RDN MUST NOT be used to identify a service. Reasons
Reasons for this include: for this include:
* It is not strongly typed and therefore suffers from ambiguities in * It is not strongly typed and therefore suffers from ambiguities in
interpretation. interpretation.
* It can appear more than once in the Subject Name. * It can appear more than once in the Subject Name.
Likewise, other RDN's within the Subject Name SHOULD NOT be used to For similar reasons, other RDN's within the Subject Name MUST NOT be
identify a service. used to identify a service.
3. Designing Application Protocols 3. Designing Application Protocols
This section provides guidelines for designers of application This section provides guidelines for designers of application
protocols, in the form of a checklist to follow when reusing the protocols, in the form of a checklist to follow when reusing the
recommendations provided in this document. recommendations provided in this document.
* Does your technology use DNS SRV records to resolve the DNS domain * If your technology does not use DNS SRV records to resolve the DNS
names of application services? If so, consider recommending or domain names of application services then consider stating that
requiring support for the SRV-ID identifier type in PKIX SRV-ID as defined in this document is not supported. Note that
certificates issued and used in your technology community. (Note many existing application technologies use DNS SRV records to
that many existing application technologies use DNS SRV records to
resolve the DNS domain names of application services, but do not resolve the DNS domain names of application services, but do not
rely on representations of those records in PKIX certificates by rely on representations of those records in PKIX certificates by
means of SRV-IDs as defined in [SRVNAME].) means of SRV-IDs as defined in [SRVNAME].
* Does your technology use URIs to identify application services? * If your technology does not use use URIs to identify application
If so, consider recommending or requiring support for the URI-ID services, then consider stating that URI-ID as defined in this
identifier type. (Note that many existing application document is not supported. Note that many existing application
technologies use URIs to identify application services, but do not technologies use URIs to identify application services, but do not
rely on representation of those URIs in PKIX certificates by means rely on representation of those URIs in PKIX certificates by means
of URI-IDs.) of URI-IDs.
* Does your technology need to allow the wildcard character in DNS
domain names? If so, consider recommending support for wildcard
certificates, and specify exactly where the wildcard character is
allowed to occur (e.g., only the complete left-most label of a DNS
domain name).
Sample text is provided under Appendix A. * If your technology disallows the wildcard character in DNS domain
names, then state the wildcard certificates as defined in this
document are not supported.
4. Representing Server Identity 4. Representing Server Identity
This section provides rules and guidelines for issuers of This section provides rules and guidelines for issuers of
certificates. certificates.
4.1. Rules 4.1. Rules
When a certification authority issues a certificate based on the When a certification authority issues a certificate based on the
fully qualified DNS domain name at which the application service fully qualified DNS domain name at which the application service
skipping to change at page 17, line 20 skipping to change at page 16, line 15
4. The certificate MAY include other application-specific 4. The certificate MAY include other application-specific
identifiers for types that were defined before publication of identifiers for types that were defined before publication of
[SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names
or URI schemes do not exist; however, such application-specific or URI schemes do not exist; however, such application-specific
identifiers are not applicable to all application technologies identifiers are not applicable to all application technologies
and therefore are out of scope for this specification. and therefore are out of scope for this specification.
5. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 5. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-
ID as further explained under Section 7.4. ID as further explained under Section 7.4.
6. Unless a specification that reuses this one allows continued
support for the wildcard character "*", the DNS domain name
portion of a presented identifier SHOULD NOT contain the wildcard
character, whether as the complete left-most label within the
identifier (following the description of labels and domain names
in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment
thereof (e.g., "*oo.example.com", "f*o.example.com", or
"fo*.example.com"). A more detailed discussion of so-called
"wildcard certificates" is provided under Section 7.2.
4.2. Examples 4.2. Examples
Consider a simple website at "www.example.com", which is not Consider a simple website at "www.example.com", which is not
discoverable via DNS SRV lookups. Because HTTP does not specify the discoverable via DNS SRV lookups. Because HTTP does not specify the
use of URIs in server certificates, a certificate for this service use of URIs in server certificates, a certificate for this service
might include only a DNS-ID of "www.example.com". might include only a DNS-ID of "www.example.com".
Consider an IMAP-accessible email server at the host Consider an IMAP-accessible email server at the host
"mail.example.net" servicing email addresses of the form "mail.example.net" servicing email addresses of the form
"user@example.net" and discoverable via DNS SRV lookups on the "user@example.net" and discoverable via DNS SRV lookups on the
skipping to change at page 20, line 34 skipping to change at page 19, line 24
the data via [DNSSEC], or obtaining the data from a third-party the data via [DNSSEC], or obtaining the data from a third-party
domain mapping service in which a human user has explicitly placed domain mapping service in which a human user has explicitly placed
trust and with which the client communicates over a connection or trust and with which the client communicates over a connection or
association that provides both mutual authentication and integrity association that provides both mutual authentication and integrity
checking). These considerations apply only to extraction of the checking). These considerations apply only to extraction of the
source domain from the inputs; naturally, if the inputs themselves source domain from the inputs; naturally, if the inputs themselves
are invalid or corrupt (e.g., a user has clicked a link provided by a are invalid or corrupt (e.g., a user has clicked a link provided by a
malicious entity in a phishing attack), then the client might end up malicious entity in a phishing attack), then the client might end up
communicating with an unexpected application service. communicating with an unexpected application service.
Example: Given an input URI of <sips:alice@example.net>, a client For example, given an input URI of <sips:alice@example.net>, a client
would derive the application service type "sip" from the "scheme" would derive the application service type "sip" from the scheme and
and parse the domain name "example.net" from the "host" component parse the domain name "example.net" from the host component.
(or its equivalent).
Each reference identifier in the list SHOULD be based on the source Each reference identifier in the list SHOULD be based on the source
domain and SHOULD NOT be based on a derived domain (e.g., a host name domain and SHOULD NOT be based on a derived domain (e.g., a host name
or domain name discovered through DNS resolution of the source or domain name discovered through DNS resolution of the source
domain). This rule is important because only a match between the domain). This rule is important because only a match between the
user inputs and a presented identifier enables the client to be sure user inputs and a presented identifier enables the client to be sure
that the certificate can legitimately be used to secure the client's that the certificate can legitimately be used to secure the client's
communication with the server. There is only one scenario in which communication with the server. There is only one scenario in which
it is acceptable for an interactive client to override the it is acceptable for an interactive client to override the
recommendation in this rule and therefore communicate with a domain recommendation in this rule and therefore communicate with a domain
skipping to change at page 22, line 5 skipping to change at page 20, line 33
deployment environments, a client that is built to connect only to a deployment environments, a client that is built to connect only to a
particular kind of service (e.g., only IM services) might be particular kind of service (e.g., only IM services) might be
configured to accept as valid only certificates that include an SRV- configured to accept as valid only certificates that include an SRV-
ID for that application service type; in this case, the client would ID for that application service type; in this case, the client would
include only SRV-IDs matching the application service type in its include only SRV-IDs matching the application service type in its
list of reference identifiers (not, for example, DNS-IDs). By list of reference identifiers (not, for example, DNS-IDs). By
contrast, a more lenient client (even one built to connect only to a contrast, a more lenient client (even one built to connect only to a
particular kind of service) might include both SRV-IDs and DNS-IDs in particular kind of service) might include both SRV-IDs and DNS-IDs in
its list of reference identifiers. its list of reference identifiers.
Implementation Note: The client does not need to construct the
foregoing identifiers in the actual formats found in a certificate
(e.g., as ASN.1 types); it only needs to construct the functional
equivalent of such identifiers for matching purposes.
6.2.2. Examples 6.2.2. Examples
A web browser that is connecting via HTTPS to the website at A web browser that is connecting via HTTPS to the website at
"www.example.com" would have a single reference identifier: a DNS-ID "www.example.com" would have a single reference identifier: a DNS-ID
of "www.example.com". of "www.example.com".
A mail user agent that is connecting via IMAPS to the email service A mail user agent that is connecting via IMAPS to the email service
at "example.net" (resolved as "mail.example.net") might have three at "example.net" (resolved as "mail.example.net") might have three
reference identifiers: an SRV-ID of "_imaps.example.net" (see reference identifiers: an SRV-ID of "_imaps.example.net" (see
[EMAIL-SRV]), and DNS-IDs of "example.net" and "mail.example.net". [EMAIL-SRV]), and DNS-IDs of "example.net" and "mail.example.net".
skipping to change at page 22, line 48 skipping to change at page 21, line 22
Once the client has constructed its list of reference identifiers and Once the client has constructed its list of reference identifiers and
has received the server's presented identifiers in the form of a PKIX has received the server's presented identifiers in the form of a PKIX
certificate, the client checks its reference identifiers against the certificate, the client checks its reference identifiers against the
presented identifiers for the purpose of finding a match. The search presented identifiers for the purpose of finding a match. The search
fails if the client exhausts its list of reference identifiers fails if the client exhausts its list of reference identifiers
without finding a match. The search succeeds if any presented without finding a match. The search succeeds if any presented
identifier matches one of the reference identifiers, at which point identifier matches one of the reference identifiers, at which point
the client SHOULD stop the search. the client SHOULD stop the search.
Implementation Note: A client might be configured to perform
multiple searches, i.e., to match more than one reference
identifier. Although such behavior is not forbidden by this
specification, rules for matching multiple reference identifiers
are a matter for implementation or future specification.
Before applying the comparison rules provided in the following Before applying the comparison rules provided in the following
sections, the client might need to split the reference identifier sections, the client might need to split the reference identifier
into its DNS domain name portion and its application service type into its DNS domain name portion and its application service type
portion, as follows: portion, as follows:
* A reference identifier of type DNS-ID does not include an * A reference identifier of type DNS-ID does not include an
application service type portion and thus can be used directly as application service type portion and thus can be used directly as
the DNS domain name for comparison purposes. As an example, a the DNS domain name for comparison purposes. As an example, a
DNS-ID of "www.example.com" would result in a DNS domain name DNS-ID of "www.example.com" would result in a DNS domain name
portion of "www.example.com". portion of "www.example.com".
skipping to change at page 24, line 14 skipping to change at page 22, line 23
6.4. Matching the DNS Domain Name Portion 6.4. Matching the DNS Domain Name Portion
The client MUST match the DNS domain name portion of a reference The client MUST match the DNS domain name portion of a reference
identifier according to the following rules (and SHOULD also check identifier according to the following rules (and SHOULD also check
the application service type as described under Section 6.5). The the application service type as described under Section 6.5). The
rules differ depending on whether the domain to be checked is a rules differ depending on whether the domain to be checked is a
"traditional domain name" or an "internationalized domain name" (as "traditional domain name" or an "internationalized domain name" (as
defined under Section 2.2). Furthermore, to meet the needs of defined under Section 2.2). Furthermore, to meet the needs of
clients that support presented identifiers containing the wildcard clients that support presented identifiers containing the wildcard
character "*", we define a supplemental rule for so-called "wildcard character "*", we define a supplemental rule for such "wildcard
certificates". certificates".
6.4.1. Checking of Traditional Domain Names 6.4.1. Checking of Traditional Domain Names
If the DNS domain name portion of a reference identifier is a If the DNS domain name portion of a reference identifier is a
"traditional domain name", then matching of the reference identifier "traditional domain name", then matching of the reference identifier
against the presented identifier is performed by comparing the set of against the presented identifier is performed by comparing the set of
domain name labels using a case-insensitive ASCII comparison, as domain name labels using a case-insensitive ASCII comparison, as
clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
to "www.example.com" for comparison purposes). Each label MUST match to "www.example.com" for comparison purposes). Each label MUST match
skipping to change at page 24, line 43 skipping to change at page 23, line 7
any U-labels [IDNA-DEFS] in the domain name to A-labels before any U-labels [IDNA-DEFS] in the domain name to A-labels before
checking the domain name. In accordance with [IDNA-PROTO], A-labels checking the domain name. In accordance with [IDNA-PROTO], A-labels
MUST be compared as case-insensitive ASCII. Each label MUST match in MUST be compared as case-insensitive ASCII. Each label MUST match in
order for the domain names to be considered to match, except as order for the domain names to be considered to match, except as
supplemented by the rule about checking of wildcard labels supplemented by the rule about checking of wildcard labels
(Section 6.4.3; but see also Section 7.2 regarding wildcards in (Section 6.4.3; but see also Section 7.2 regarding wildcards in
internationalized domain names). internationalized domain names).
6.4.3. Checking of Wildcard Certificates 6.4.3. Checking of Wildcard Certificates
A client employing this specification's rules MAY match the reference A client MAY match the reference identifier against a presented
identifier against a presented identifier whose DNS domain name identifier whose DNS domain name portion contains the wildcard
portion contains the wildcard character "*" as part or all of a label character "*" in a label (following the description of labels and
(following the description of labels and domain names in domain names in [DNS-CONCEPTS]), provided these requirements are met:
[DNS-CONCEPTS]), provided the requirements listed below are met.
For information regarding the security characteristics of wildcard
certificates, see Section 7.2.
A client MUST NOT use the wildcard identifier if the reference 1. There is only one wildcard character.
identifier does not follow the following rules:
1. There is more than one wildcard character. 2. The wildcard character appears only as the content of the left-
most label.
2. The wildcard appears other than in the left-most label (e.g., do 3. The wildcard character is not embedded in an A-label or U-label
not match "bar.*.example.net"). [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO].
3. The wildcard is not the first character (e.g., do not match A wildcard in a presented identifier can only match exactly one label
"w*.example.com") in a reference identifier. Note that this is not the same as DNS
wildcard matching, where the "*" label always matches at least one
whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3
and [DNS-WILDCARDS].
4. The wildcard character is embedded in an A-label or U-label For information regarding the security characteristics of wildcard
[IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. certificates, see Section 7.2.
6.5. Matching the Application Service Type Portion 6.5. Matching the Application Service Type Portion
When a client checks identifiers of type SRV-ID and URI-ID, it MUST When a client checks identifiers of type SRV-ID and URI-ID, it MUST
check not only the DNS domain name portion of the identifier but also check not only the DNS domain name portion of the identifier but also
the application service type portion. The client does this by the application service type portion. The client does this by
splitting the identifier into the DNS domain name portion and the splitting the identifier into the DNS domain name portion and the
application service type portion (as described under Section 6.3), application service type portion (as described under Section 6.3),
then checking both the DNS domain name portion (as described under then checking both the DNS domain name portion (as described under
Section 6.4) and the application service type portion as described in Section 6.4) and the application service type portion as described in
skipping to change at page 26, line 29 skipping to change at page 24, line 37
reference identifier, then the service identity check has succeeded. reference identifier, then the service identity check has succeeded.
In this case, the client MUST use the matched reference identifier as In this case, the client MUST use the matched reference identifier as
the validated identity of the application service. the validated identity of the application service.
6.6.2. Case #2: No Match Found, Pinned Certificate 6.6.2. Case #2: No Match Found, Pinned Certificate
If the client does not find a presented identifier matching any of If the client does not find a presented identifier matching any of
the reference identifiers but the client has previously pinned the the reference identifiers but the client has previously pinned the
application service's certificate to one of the reference identifiers application service's certificate to one of the reference identifiers
in the list it constructed for this communication attempt (as in the list it constructed for this communication attempt (as
"pinning" is explained under Section 1.7), and the presented "pinning" is explained under Section 1.8), and the presented
certificate matches the pinned certificate (including the context as certificate matches the pinned certificate (including the context as
described under Section 7.1), then the service identity check has described under Section 7.1), then the service identity check has
succeeded. succeeded.
6.6.3. Case #3: No Match Found, No Pinned Certificate 6.6.3. Case #3: No Match Found, No Pinned Certificate
If the client does not find a presented identifier matching any of If the client does not find a presented identifier matching any of
the reference identifiers and the client has not previously pinned the reference identifiers and the client has not previously pinned
the certificate to one of the reference identifiers in the list it the certificate to one of the reference identifiers in the list it
constructed for this communication attempt, then the client MUST constructed for this communication attempt, then the client MUST
skipping to change at page 27, line 5 skipping to change at page 25, line 14
6.6.4. Fallback 6.6.4. Fallback
If the client is an interactive client that is directly controlled by If the client is an interactive client that is directly controlled by
a human user, then it SHOULD inform the user of the identity mismatch a human user, then it SHOULD inform the user of the identity mismatch
and automatically terminate the communication attempt with a bad and automatically terminate the communication attempt with a bad
certificate error; this behavior is preferable because it prevents certificate error; this behavior is preferable because it prevents
users from inadvertently bypassing security protections in hostile users from inadvertently bypassing security protections in hostile
situations. situations.
Security Warning: Some interactive clients give advanced users the Some interactive clients give advanced users the option of proceeding
option of proceeding with acceptance despite the identity with acceptance despite the identity mismatch. Although this
mismatch, thereby "pinning" the certificate to one of the behavior can be appropriate in certain specialized circumstances, it
reference identifiers in the list constructed by the client for needs to be handled with extreme caution, for example by first
this communication attempt. Although this behavior can be encouraging even an advanced user to terminate the communication
appropriate in certain specialized circumstances, in general it attempt and, if the advanced user chooses to proceed anyway, by
ought to be exposed only to advanced users. Even then it needs to forcing the user to view the entire certification path before
be handled with extreme caution, for example by first encouraging proceeding.
even an advanced user to terminate the communication attempt and,
if the advanced user chooses to proceed anyway, by forcing the
user to view the entire certification path and only then allowing
the user to pin the certificate (on a temporary or permanent
basis, at the user's option).
Otherwise, if the client is an automated application not directly Otherwise, if the client is an automated application not directly
controlled by a human user, then it SHOULD terminate the controlled by a human user, then it SHOULD terminate the
communication attempt with a bad certificate error and log the error communication attempt with a bad certificate error and log the error
appropriately. An automated application MAY provide a configuration appropriately. An automated application MAY provide a configuration
setting that disables this behavior, but MUST enable the behavior by setting that disables this behavior, but MUST enable the behavior by
default. default.
7. Security Considerations 7. Security Considerations
7.1. Pinned Certificates 7.1. Pinned Certificates
As defined under Section 1.7, a certificate is said to be "pinned" to As defined under Section 1.8, a certificate is said to be "pinned" to
a DNS domain name when a user has explicitly chosen to associate a a DNS domain name when a user has explicitly chosen to associate a
service's certificate with that DNS domain name despite the fact that service's certificate with that DNS domain name despite the fact that
the certificate contains some other DNS domain name (e.g., the user the certificate contains some other DNS domain name (e.g., the user
has explicitly approved "apps.example.net" as a domain associated has explicitly approved "apps.example.net" as a domain associated
with a source domain of "example.com"). The cached name association with a source domain of "example.com"). The cached name association
MUST take account of both the certificate presented and the context MUST take account of both the certificate presented and the context
in which it was accepted or configured (where the "context" includes in which it was accepted or configured (where the "context" includes
the chain of certificates from the presented certificate to the trust the chain of certificates from the presented certificate to the trust
anchor, the source domain, the application service type, the anchor, the source domain, the application service type, the
service's derived domain and port number, and any other relevant service's derived domain and port number, and any other relevant
information provided by the user or associated by the client). information provided by the user or associated by the client).
7.2. Wildcard Certificates 7.2. Wildcard Certificates
This document states that the wildcard character "*" SHOULD NOT be Wildcard certificates, those that have an identifier with "*" as the
included in presented identifiers but SHOULD be checked by left-most DNS label, automatically vouch for any single-label host
application clients if the requirements specified in Section 6.4.3 names within their domain, but not multiple levels of domains. This
are met. can be convenient for administrators but also poses the risk of
vouching for rogue or buggy hosts. See for example [Defeating-SSL]
Wildcard certificates automatically vouch for any and all host names (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
within their domain. This can be convenient for administrators but
also poses the risk of vouching for rogue or buggy hosts. See for
example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes]
(slides 38-40).
Protection against a wildcard that identifies a so-called "public Protection against a wildcard that identifies a so-called "public
suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this
document. document.
7.3. Internationalized Domain Names 7.3. Internationalized Domain Names
Allowing internationalized domain names can lead to the inclusion of Allowing internationalized domain names can lead to the inclusion of
visually similar (so-called "confusable") characters in certificates; visually similar (so-called "confusable") characters in certificates;
for discussion, see for example [IDNA-DEFS]. for discussion, see for example [IDNA-DEFS].
7.4. Multiple Identifiers 7.4. Multiple Identifiers
A given application service might be addressed by multiple DNS domain A given application service might be addressed by multiple DNS domain
names for a variety of reasons, and a given deployment might service names for a variety of reasons, and a given deployment might service
multiple domains (e.g., in so-called "virtual hosting" environments). multiple domains or protocols. The client SHOULD use the TLS Server
In the default TLS handshake exchange, the client is not able to Name Identification (SNI) extension as discussed in [TLS],
indicate the DNS domain name with which it wants to communicate, and Section 4.4.2.2.
the TLS server returns only one certificate for itself. Absent an
extension to TLS, a typical workaround used to facilitate mapping an
application service to multiple DNS domain names is to embed all of
the domain names into a single certificate.
A more recent approach, formally specified in [TLS-EXT], is for the
client to use the TLS "Server Name Indication" (SNI) extension when
sending the client_hello message, stipulating the DNS domain name it
desires or expects of the service. The service can then return the
appropriate certificate in its Certificate message, and that
certificate can represent a single DNS domain name.
To accommodate the workaround that was needed before the development To accommodate the workaround that was needed before the development
of the SNI extension, this specification allows multiple DNS-IDs, of the SNI extension, this specification allows multiple DNS-IDs,
SRV-IDs, or URI-IDs in a certificate. SRV-IDs, or URI-IDs in a certificate.
8. References 8. References
8.1. Normative References 8.1. Normative References
[DNS-CONCEPTS] [DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities", Mockapetris, P.V., "Domain names - concepts and
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
<https://www.rfc-editor.org/rfc/rfc1034>. November 1987, <https://doi.org/10.17487/RFC1034>.
[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,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>. <https://doi.org/10.17487/RFC2782>.
[DNS-WILDCARDS]
Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://doi.org/10.17487/RFC4592>.
[IDNA-DEFS] [IDNA-DEFS]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>. <https://doi.org/10.17487/RFC5890>.
[IDNA-PROTO] [IDNA-PROTO]
Klensin, J., "Internationalized Domain Names in Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/rfc/rfc5891>. <https://doi.org/10.17487/RFC5891>.
[LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006, RFC 4514, DOI 10.17487/RFC4514, June 2006,
<https://www.rfc-editor.org/rfc/rfc4514>. <https://doi.org/10.17487/RFC4514>.
[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, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://doi.org/10.17487/RFC5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://doi.org/10.17487/RFC2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://doi.org/10.17487/RFC8174>.
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, DOI 10.17487/RFC4985, August 2007, RFC 4985, DOI 10.17487/RFC4985, August 2007,
<https://www.rfc-editor.org/rfc/rfc4985>. <https://doi.org/10.17487/RFC4985>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://doi.org/10.17487/RFC3986>.
8.2. Informative References 8.2. Informative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>. <https://doi.org/10.17487/RFC5234>.
[Defeating-SSL] [Defeating-SSL]
Marlinspike, M., "New Tricks for Defeating SSL in Marlinspike, M., "New Tricks for Defeating SSL in
Practice", BlackHat DC, February 2009, Practice", BlackHat DC, February 2009,
<http://www.blackhat.com/presentations/bh-dc- <http://www.blackhat.com/presentations/bh-dc-
09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating- 09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-
SSL.pdf>. SSL.pdf>.
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343, Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006, DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/rfc/rfc4343>. <https://doi.org/10.17487/RFC4343>.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/rfc/rfc4033>. <https://doi.org/10.17487/RFC4033>.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
<https://www.rfc-editor.org/rfc/rfc4347>. January 2012, <https://doi.org/10.17487/RFC6347>.
[EMAIL-SRV] [EMAIL-SRV]
Daboo, C., "Use of SRV Records for Locating Email Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/rfc/rfc6186>. <https://doi.org/10.17487/RFC6186>.
[EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And
Management Of Extended Validation Certificates", October Management Of Extended Validation Certificates", October
2009, <http://www.cabforum.org/Guidelines_v1_2.pdf>. 2009, <http://www.cabforum.org/Guidelines_v1_2.pdf>.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Protocol (HTTP/1.1): Message Syntax and Routing",
Transfer Protocol -- HTTP/1.1", RFC 2616, RFC 7230, DOI 10.17487/RFC7230, June 2014,
DOI 10.17487/RFC2616, June 1999, <https://doi.org/10.17487/RFC7230>.
<https://www.rfc-editor.org/rfc/rfc2616>.
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/rfc/rfc2818>. <https://doi.org/10.17487/RFC2818>.
[HTTPSbytes] [HTTPSbytes]
Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu
Dhabi, November 2010, <https://media.blackhat.com/bh-ad- Dhabi, November 2010, <https://media.blackhat.com/bh-ad-
10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me- 10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me-
slides.pdf>. slides.pdf>.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/rfc/rfc4301>. December 2005, <https://doi.org/10.17487/RFC4301>.
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002, RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/rfc/rfc3403>. <https://doi.org/10.17487/RFC3403>.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [OCSP] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Adams, "X.509 Internet Public Key Infrastructure Online Galperin, S., and C. Adams, "X.509 Internet Public Key
Certificate Status Protocol - OCSP", RFC 2560, Infrastructure Online Certificate Status Protocol - OCSP",
DOI 10.17487/RFC2560, June 1999, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/rfc/rfc2560>. <https://doi.org/10.17487/RFC6960>.
[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, Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007, DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/rfc/rfc4880>. <https://doi.org/10.17487/RFC4880>.
[PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.
[S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958,
January 2005, <https://www.rfc-editor.org/rfc/rfc3958>. January 2005, <https://doi.org/10.17487/RFC3958>.
[SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>. <https://doi.org/10.17487/RFC4949>.
[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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>. <https://doi.org/10.17487/RFC3261>.
[SIP-CERTS] [SIP-CERTS]
Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010, RFC 5922, DOI 10.17487/RFC5922, June 2010,
<https://www.rfc-editor.org/rfc/rfc5922>. <https://doi.org/10.17487/RFC5922>.
[SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009, DOI 10.17487/RFC5630, October 2009,
<https://www.rfc-editor.org/rfc/rfc5630>. <https://doi.org/10.17487/RFC5630>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Extensions: Extension Definitions", RFC 6066, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
DOI 10.17487/RFC6066, January 2011, <https://doi.org/10.17487/RFC8446>.
<https://www.rfc-editor.org/rfc/rfc6066>.
[US-ASCII] American National Standards Institute, "Coded Character [US-ASCII] 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.
[VERIFY] Saint-Andre, P. and J. Hodges, "Representation and [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/rfc/rfc6125>. 2011, <https://doi.org/10.17487/RFC6125>.
[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User
Interface Guidelines", World Wide Web Consortium LastCall Interface Guidelines", World Wide Web Consortium LastCall
WD-wsc-ui-20100309, March 2010, WD-wsc-ui-20100309, March 2010,
<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>. <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[X.500] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Overview of concepts, models and services",
ITU-T Recommendation X.500, ISO Standard 9594-1, August
2005.
[X.501] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Models", ITU-T Recommendation X.501, ISO Standard 9594-2,
August 2005.
[X.509] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks",
ITU-T Recommendation X.509, ISO Standard 9594-8, August
2005.
[X.520] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - The Directory:
Selected attribute types", ITU-T Recommendation X.509,
ISO Standard 9594-6, August 2005.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/rfc/rfc6120>. March 2011, <https://doi.org/10.17487/RFC6120>.
Appendix A. Sample Text
At the time of this writing, two application technologies reuse the
recommendations in this specification: email [EMAIL-SRV] and XMPP
[XMPP]. Here we include the text from [XMPP] to illustrate the
thought process that might be followed by protocol designers for
other application technologies. Specifically, because XMPP uses DNS
SRV records for resolution of the DNS domain names for application
services, the XMPP specification recommends the use of SRV-IDs.
The text regarding certificate issuance is as follows:
######
In a PKIX certificate to be presented by an XMPP server (i.e., a
"server certificate"), the certificate MUST include one or more XMPP
addresses (i.e., domainparts) associated with XMPP services hosted at
the server. The rules and guidelines defined in this specification
apply to XMPP server certificates, with the following XMPP-specific
considerations:
* Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
client and server software implementations. Certification
authorities that issue XMPP-specific certificates MUST support the
DNS-ID identifier type. XMPP service providers SHOULD include the
DNS-ID identifier type in certificate requests.
* Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for
XMPP client and server software implementations (for verification
purposes XMPP client implementations need to support only the
"_xmpp-client" application service type, whereas XMPP server
implementations need to support both the "_xmpp-client" and
"_xmpp-server" application service types). Certification
authorities that issue XMPP-specific certificates SHOULD support
the SRV-ID identifier type. XMPP service providers SHOULD include
the SRV-ID identifier type in certificate requests.
* Support for the XmppAddr identifier type is encouraged in XMPP
client and server software implementations for the sake of
backward-compatibility, but is no longer encouraged in
certificates issued by certification authorities or requested by
XMPP service providers.
* DNS domain names in server certificates MAY contain the wildcard
character "*" as the complete left-most label within the
identifier.
######
The text regarding certificate verification is as follows:
######
For server certificates, the rules and guidelines defined in this
specification apply, with the proviso that the XmppAddr identifier is
allowed as a reference identifier.
The identities to be checked are set as follows:
* The initiating entity sets its reference identifier to the 'to'
address it communicates in the initial stream header; i.e., this
is the identity it expects the receiving entity to provide in a
PKIX certificate.
* The receiving entity sets its reference identifier to the 'from'
address communicated by the initiating entity in the initial
stream header; i.e., this is the identity that the initiating
entity is trying to assert.
######
Acknowledgements Acknowledgements
We gratefully acknowledge everyone who contributed to the previous We gratefully acknowledge everyone who contributed to the previous
version of this document, [VERIFY]. version of this document, [VERIFY].
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Mozilla Mozilla
United States of America United States of America
Email: stpeter@mozilla.com Email: stpeter@mozilla.com
Jeff Hodges Jeff Hodges
Google Google
United States of America United States of America
 End of changes. 77 change blocks. 
406 lines changed or deleted 203 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/