draft-ietf-uta-rfc6125bis-02.txt   draft-ietf-uta-rfc6125bis-03.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: 12 March 2022 R. Salz Expires: 16 April 2022 R. Salz
Akamai Technologies Akamai Technologies
8 September 2021 13 October 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-02 draft-ietf-uta-rfc6125bis-03
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.
This document obsoletes RFC 6125.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Using TLS in Discussion of this document takes place on the Using TLS in
Applications Working Group mailing list (uta@ietf.org), which is Applications Working Group mailing list (uta@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/uta/. archived at https://mailarchive.ietf.org/arch/browse/uta/.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/richsalz/draft-ietf-uta-rfc6125bis. https://github.com/richsalz/draft-ietf-uta-rfc6125bis.
skipping to change at page 2, line 4 skipping to change at page 2, line 9
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 12 March 2022.
This Internet-Draft will expire on 16 April 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. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 3
1.3. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 4 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.4. How to Read This Document . . . . . . . . . . . . . . . . 5 1.4. Overview of Recommendations . . . . . . . . . . . . . . . 4
1.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6. Overview of Recommendations . . . . . . . . . . . . . . . 6 1.5.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 5
1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.5.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5
1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 7 2. Naming of Application Services . . . . . . . . . . . . . . . 9
1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3. Designing Application Protocols . . . . . . . . . . . . . . . 10
2. Naming of Application Services . . . . . . . . . . . . . . . 12 4. Representing Server Identity . . . . . . . . . . . . . . . . 11
2.1. Naming Application Services . . . . . . . . . . . . . . . 12 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14 5. Requesting Server Certificates . . . . . . . . . . . . . . . 12
3. Designing Application Protocols . . . . . . . . . . . . . . . 14 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 13
4. Representing Server Identity . . . . . . . . . . . . . . . . 15 6.1. Constructing a List of Reference Identifiers . . . . . . 13
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 15
5. Requesting Server Certificates . . . . . . . . . . . . . . . 16 6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 15
6. Verifying Service Identity . . . . . . . . . . . . . . . . . 17 6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 16
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. Matching the Application Service Type Portion . . . . . . 17
6.2. Constructing a List of Reference Identifiers . . . . . . 18 6.5. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 19
6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 21 7.2. Internationalized Domain Names . . . . . . . . . . . . . 19
6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 22 7.3. Multiple Presented Identifiers . . . . . . . . . . . . . 20
6.4.1. Checking of Traditional Domain Names . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.4.2. Checking of Internationalized Domain Names . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
6.5. Matching the Application Service Type Portion . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 24
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 24
6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 24
6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 24
6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 25
7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 26
7.3. Internationalized Domain Names . . . . . . . . . . . . . 26
7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
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. When a
retrieve or upload information, communicate with other entities, or client communicates with an application service using Transport Layer
access a broader network of services. When a client communicates Security [TLS] or Datagram Transport Layer Security [DTLS], it has
with an application service using Transport Layer Security [TLS] or some notion of the server's identity (e.g., "the website at
Datagram Transport Layer Security [DTLS], it references some notion example.com") while attempting to establish secure communication.
of the server's identity (e.g., "the website at example.com") while Likewise, during TLS negotiation, the server presents its notion of
attempting to establish secure communication. Likewise, during TLS the service's identity in the form of a public-key certificate that
negotiation, the server presents its notion of the service's identity was issued by a certification authority (CA) in the context of the
in the form of a public-key certificate that was issued by a Internet Public Key Infrastructure using X.509 [PKIX]. Informally,
certification authority (CA) in the context of the Internet Public we can think of these identities as the client's "reference identity"
Key Infrastructure using X.509 [PKIX]. Informally, we can think of and the server's "presented identity" (more formal definitions are
these identities as the client's "reference identity" and the given later). A client needs to verify that the server's presented
server's "presented identity" (these rough ideas are defined more identity matches its reference identity so it can authenticate the
precisely later in this document through the concept of particular communication.
identifiers). In general, a client needs to verify that the server's
presented identity matches its reference identity so it can
authenticate the communication.
Many application technologies adhere to the pattern just outlined.
Such protocols have traditionally specified their own rules for
representing and verifying application service identity.
Unfortunately, this divergence of approaches has caused some
confusion among certification authorities, application developers,
and protocol designers.
Therefore, to codify secure procedures for the implementation and
deployment of PKIX-based authentication, this document specifies
recommended procedures for representing and verifying application
service identity in certificates intended for use in application
protocols employing TLS.
1.2. Audience
The primary audience for this document consists of application This document defines procedures for how clients do this
protocol designers, who can reference this document instead of verification. It therefore implicitly defines requirements on other
defining their own rules for the representation and verification of parties, such as the CA's that issue certificates, the service
application service identity. Secondarily, the audience consists of administrators requesting them, and the protocol designers defining
certification authorities, service providers, and client developers how things are named.
from technology communities that might reuse the recommendations in
this document when defining certificate issuance policies, generating
certificate signing requests, or writing software algorithms for
identity matching.
1.3. Changes since RFC 6125 1.2. Changes since RFC 6125
This document revises and obsoletes [VERIFY] based on the decade of This document revises and obsoletes [VERIFY] based on the decade of
experience and changes since it was first published. The major experience and changes since it was first published. The major
changes, in no particular order, include: changes, in no particular order, include:
* All references have been updated to the current latest version. * All references have been updated to the current latest version.
* The TLS SNI extension is no longer new, it is commonplace. * The TLS SNI extension is no longer new, it is commonplace.
* The only legal place for a certificate wildcard name is as the * The only legal place for a certificate wildcard name is as the
left-most component in a domain name. left-most component in a domain name.
* It is no longer allowed to use the commonName RDN, known as "CN- * It is no longer allowed to use the commonName RDN, known as CN-ID,
ID", to represent the server identity; only the subjectAltNames to represent the server identity; only the subjectAltNames
extension is used. extension is used.
* References to the X.500 directory, the survey of prior art, and * References to the X.500 directory, the survey of prior art, and
the sample text in Appendix A have been removed. the sample text in Appendix A have been removed.
1.4. How to Read This Document * Detailed discussion of pinning (configuring use of a certificate
that doesn't match the criteria in this document) has been
This document is longer than the authors would have liked because it removed.
was necessary to carefully define terminology, explain the underlying
concepts, define the scope, and specify recommended behavior for both
certification authorities and application software implementations.
The following sections are of special interest to various audiences:
* Protocol designers might want to first read the checklist in
Section 3.
* Certification authorities might want to first read the
recommendations for representation of server identity in
Section 4.
* Service providers might want to first read the recommendations for
requesting of server certificates in Section 5.
* Software implementers might want to first read the recommendations
for verification of server identity in Section 6.
The sections on terminology (Section 1.8), naming of application * The sections detailing different target audiences and which
services (Section 2), document scope (Section 1.7), and the like sections to read (first) have been removed.
provide useful background information regarding the recommendations
and guidelines that are contained in the above-referenced sections,
but are not absolutely necessary for a first reading of this
document.
1.5. Applicability 1.3. 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 specified by [PKIX]. That document also governs any
on any point that might also be discussed in this document. certificate-related topic on which this document is silent. This
Furthermore, [PKIX] also governs any certificate-related topic on includes certificate syntax, certificate extensions such as name
which this document is silent, including but not limited to constraints or extended key usage, and handling of certification
certificate syntax, certificate extensions such as name constraints 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"
server certificate, not any name forms in the chain of certificates server certificate. It does not address the name forms in the chain
used to validate the server certificate. Therefore, in order to of certificates used to validate a cetrificate, let alone creating or
ensure proper authentication, application clients need to verify the checking the validity of such a chain. In order to ensure proper
entire certification path per [PKIX]. authentication, applications need to verify the entire certification
path as per [PKIX].
This document also does not supersede the rules for verifying service
identity provided in specifications for existing application
protocols published prior to this document. However, the procedures
described here can be referenced by future specifications, including
updates to specifications for existing application protocols if the
relevant technology communities agree to do so.
1.6. Overview of Recommendations
To orient the reader, this section provides an informational overview 1.4. Overview of Recommendations
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. he rules are brief:
For the primary audience of application protocol designers, this
document provides recommended procedures for the representation and
verification of application service identity within PKIX certificates
used in the context of TLS.
For the secondary audiences, in essence this document encourages * Only check DNS domain names via the subjectAlternativeName
certification authorities, application service providers, and extension designed for that purpose: dNSName.
application client developers to coalesce on the following practices:
* Stop including and checking strings that look like domain names in * Allow use of even more specific subjectAlternativeName extensions
the subject's Common Name. where appropriate such as uniformResourceIdentifier and the
otherName form SRVName.
* Check DNS domain names via the subjectAlternativeName extension * Constrain wildcard certificates so that the wildcard can only be
designed for that purpose: dNSName. the left-most component of a domain name.
* Move toward including and checking even more specific * Do not include or check strings that look like domain names in the
subjectAlternativeName extensions where appropriate for using the subject's Common Name.
protocol (e.g., uniformResourceIdentifier and the otherName form
SRVName).
* Constrain and simplify the validation of wildcard certificates 1.5. Scope
(e.g., a certificate containing an identifier for
"*.example.com").
1.7. Scope 1.5.1. In Scope
1.7.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, and only to FQDNs only to TLS and DTLS, and only to PKIX-based systems.
PKIX-based systems. As a result, the scenarios described in the
following section are out of scope for this specification (although
they might be addressed by future specifications).
1.7.2. Out of Scope
The following topics are out of scope for this specification:
* Client or end-user identities.
Certificates representing client or end-user identities (e.g., the TLS uses the words client and server, where the client is the entity
rfc822Name identifier) can be used for mutual authentication that initiates the connection. In many cases, this models common
between a client and server or between two clients, thus enabling practice, such as a browser connecting to a Web origin. For the sake
stronger client-server security or end-to-end security. However, of clarity, and to follow the usage in [TLS] and related
certification authorities, application developers, and service specifications, we will continue to use to use the terms client and
operators have less experience with client certificates than with server in this document. Note that these are TLS-layer roles, and
server certificates, thus giving us fewer models from which to that the application protocol could support the TLS server making
generalize and a less solid basis for defining best practices. requests to the TLS client after the TLS handshake; these is no
requirement that the roles at the application layer match the TLS-
layer.
* Identifiers other than fully qualified DNS domain names. At the time of this writing, other protocols such as [QUIC] and
Network Time Security ([NTS]) use TLS as a service to do the initial
establishment of cryptographic key material. Such services MUST also
follow the rules specified here.
For example, this specification does not discuss IP addresses or 1.5.2. Out of Scope
other attributes within a certificate beyond the subjectAltName
extension. The focus of this document is 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).
* Security protocols other than [TLS] or [DTLS]. The following topics are out of scope for this specification:
Although other secure, lower-layer protocols exist and even employ * Security protocols other than [TLS] or [DTLS] except as described
PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases above.
can differ from those of TLS-based and DTLS-based application
technologies. Furthermore, application technologies have less
experience with IPsec than with TLS, thus making it more difficult
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.
Some deployed application technologies use a web of trust model * Client or end-user identities. Certificates representing client
based on or similar to OpenPGP [OPENPGP], or use self-signed identities other than that described above, such as rfc822Name,
certificates, or are deployed on networks that are not directly are beyond the scope of this document.
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 method for binding a public key to an identifier in OpenPGP
differs essentially from the method in X.509, the data in self-
signed certificates has not been certified by a third party in any
way, and checking of CA-issued certificates via CRLs or OCSP is
critically important to maintaining the security of PKIX-based
systems. Attempting to define best practices for such
technologies would unduly complicate the rules defined in this
specification.
* Certification authority policies, such as: * Identifiers other than FQDNs. Identifiers such as IP address are
not discussed. In addition, the focus of this document is 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 other
aspects of a service such as a specific resource (via the URI
"path" component) or parameters (via the URI "query" component).
- What types or "classes" of certificates to issue and whether to * Certification authority policies. This includes items such as the
apply different policies for them. following:
- Whether to issue certificates based on IP addresses (or some - How to certify or validate FQDNs and application service types
other form, such as relative domain names) in addition to fully (see [ACME] for some definition of this).
qualified DNS domain names.
- Which identifiers to include (e.g., whether to include SRV-IDs - Issuing certificates with additional identifiers such as IP
or URI-IDs as defined in the body of this specification). address or relative domain name, in addition to FQDNs.
- How to certify or validate fully qualified DNS domain names and - Types or "classes" of certificates to issue and whether to
application service types. apply different policies for them.
- How to certify or validate other kinds of information that - How to certify or validate other kinds of information that
might be included in a certificate (e.g., organization name). might be included in a certificate (e.g., organization name).
* Resolution of DNS domain names. * Resolution of DNS domain names. Although the process whereby a
client resolves the DNS domain name of an application service can
Although the process whereby a client resolves the DNS domain name involve several steps, for our purposes we care only about the
of an application service can involve several steps (e.g., this is fact that the client needs to verify the identity of the entity
true of resolutions that depend on DNS SRV resource records, with which it communicates as a result of the resolution process.
Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and Thus the resolution process itself is out of scope for this
related technologies such as [S-NAPTR]), for our purposes we care specification.
only about the fact that the client needs to verify the identity
of the entity with which it communicates as a result of the
resolution process. Thus the resolution process itself is out of
scope for this specification.
* User interface issues.
In general, such issues are properly the responsibility of client * User interface issues. In general, such issues are properly the
software developers and standards development organizations responsibility of client software developers and standards
dedicated to particular application technologies (see, for development organizations dedicated to particular application
example, [WSC-UI]). technologies (see, for example, [WSC-UI]).
1.8. Terminology 1.6. 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. This often apepars as a URI scheme [URI] or a DNS
of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service SRV Service [DNS-SRV].
[DNS-SRV].
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 the
the human user controlling an interactive client or (b) a trusted human user controlling an interactive client or a trusted
administrator. In case (a), one example of delegation is an administrator. For example, a server at mailhost.example.com for
account setup that specifies the domain name of a particular host
to be used for retrieving information or connecting to a network,
which might be different from the server portion of the user's
account name (e.g., a server at mailhost.example.com for
connecting to an IMAP server hosting an email address of connecting to an IMAP server hosting an email address of
juliet@example.com). In case (b), one example of delegation is an user@example.com.
admin-configured host-to-address/address-to-host lookup table.
derived domain: A domain name or host name that a client has derived derived domain: A domain name or host name that a client has derived
from the source domain in an automated fashion (e.g., by means of from the source domain in an automated fashion (e.g., by means of
a [DNS-SRV] lookup). a [DNS-SRV] lookup).
identifier: A particular instance of an identifier type that is identifier: A particular instance of an identifier type that is
either presented by a server in a certificate or referenced by a either presented by a server in a certificate or referenced by a
client for matching purposes. client for matching purposes.
identifier type: A formally defined category of identifier that can identifier type: A formally defined category of identifier that can
be included in a certificate and therefore that can also be used be included in a certificate and therefore that can also be used
for matching purposes. For conciseness and convenience, we define for matching purposes. For conciseness and convenience, we define
the following identifier types of interest, which are based on the following identifier types of interest, which are based on
those found in the PKIX specification [PKIX] and various PKIX those found in the PKIX specification [PKIX] and various PKIX
extensions. extensions:
* DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] * DNS-ID: a subjectAltName entry of type dNSName
* SRV-ID = a subjectAltName entry of type otherName whose name * SRV-ID: a subjectAltName entry of type otherName whose name
form is SRVName; see [SRVNAME] form is SRVName; see [SRVNAME]
* URI-ID = a subjectAltName entry of type * URI-ID: a subjectAltName entry of type
uniformResourceIdentifier whose value includes both (i) a uniformResourceIdentifier whose value includes both (i) a
"scheme" and (ii) a "host" component (or its equivalent) that "scheme" and (ii) a "host" component (or its equivalent) that
matches the "reg-name" rule (where the quoted terms represent matches the "reg-name" rule (where the quoted terms represent
the associated [ABNF] productions from [URI]); see [PKIX] and the associated [ABNF] productions from [URI]) An entry which
[URI] does not have both the scheme and host is not a valid URI-ID
and MUST be ignored.
interactive client: A software agent or device that is directly interactive client: A software agent or device that is directly
controlled by a human user. (Other specifications related to controlled by a human user, commonly known as a "user agent."
security and application protocols, such as [WSC-UI], often refer
to this entity as a "user agent".)
pinning: The act of establishing a cached name association between
the application service's certificate and one of the client's
reference identifiers, despite the fact that none of the presented
identifiers matches the given reference identifier. Pinning is
accomplished by allowing a human user to positively accept the
mismatch during an attempt to communicate with the application
service. Once a cached name association is established, the
certificate is said to be pinned to the reference identifier and
in future communication attempts the client simply verifies that
the service's presented certificate matches the pinned
certificate, as described under Section 6.6.2. (A similar
definition of "pinning" is provided in [WSC-UI].)
PKIX: PKIX is a short name for the Internet Public Key PKIX: PKIX is a short name for the Internet Public Key
Infrastructure using X.509 defined in RFC 5280 [PKIX], which Infrastructure using X.509 defined in [PKIX]. That document
comprises a profile of the X.509v3 certificate specifications and provides a profile of the X.509v3 certificate specifications and
X.509v2 certificate revocation list (CRL) specifications for use X.509v2 certificate revocation list (CRL) specifications for use
in the Internet. in the Internet.
PKIX-based system: A software implementation or deployed service presented identifier: An identifier presented by a server to a
that makes use of X.509v3 certificates and X.509v2 certificate client within a PKIX certificate when the client attempts to
revocation lists (CRLs). establish secure communication with the server. The certificate
PKIX certificate: An X.509v3 certificate generated and employed in
the context of PKIX.
presented identifier: An identifier that is presented by a server to
a client within a PKIX certificate when the client attempts to
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 used by the client when
domain and optionally an application service type, used by the examining presented identifiers. It is constructed from the
client for matching purposes when examining presented identifiers. source domain, and optionally an application service type.
Relative Distinguished Name (RDN): The ASN.1-based construction Relative Distinguished Name (RDN): The ASN.1-based construction
comprising a Relative Distinguished Name (RDN), which itself is a comprising a Relative Distinguished Name (RDN), which itself is a
building-block component of Distinguished Names. See [LDAP-DN], building-block component of Distinguished Names. See [LDAP-DN],
Section 2. Section 2.
source domain: The fully qualified DNS domain name that a client source domain: The FQDN that a client expects an application service
expects an application service to present in the certificate to present in the certificate. This is typically input by a human
(e.g., "www.example.com"), typically input by a human user, user, configured into a client, or provided by reference such as
configured into a client, or provided by reference such as in a URL. 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. certificate subject.
subject name: In this specification, the term refers to the name of subject name: In this specification, the term refers to the name of
a PKIX certificate's subject, encoded in a certificate's subject a PKIX certificate's subject, encoded in a certificate's subject
field (see [PKIX], Section 4.1.2.6). field (see [PKIX], Section 4.1.2.6).
TLS client: An entity that assumes the role of a client in a Security-related terms used in this document, but not defined here or
Transport Layer Security [TLS] negotiation. In this specification in [PKIX] should be understood in the the sense defined in
we generally assume that the TLS client is an (interactive or [SECTERMS]. Such terms include "attack", "authentication",
automated) application client; however, in application protocols "identity", "trust", "validate", and "verify".
that enable server-to-server communication, the TLS client could
be a peer application service.
TLS server: An entity that assumes the role of a server in a
Transport Layer Security [TLS] negotiation; in this specification
we assume that the TLS server is an application service.
Most security-related terms in this document are to be understood in
the sense defined in [SECTERMS]; such terms include, but are not
limited to, "attack", "authentication", "authorization",
"certification authority", "certification path", "certificate",
"credential", "identity", "self-signed certificate", "trust", "trust
anchor", "trust chain", "validate", and "verify".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Naming of Application Services 2. Naming of Application Services
This section discusses naming of application services on the This document assumes that the name of an application service is
Internet, followed by a brief tutorial about subject naming in PKIX. based on a DNS domain name (e.g., example.com) -- supplemented in
some circumstances by an application service type (e.g., "the IMAP
server at example.com"). The DNS name conforms to one of the
following forms:
2.1. Naming Application Services 1. A "traditional domain name", i.e., a FQDN (see [DNS-CONCEPTS])
all of whose labels are "LDH labels" as described in [IDNA-DEFS].
Informally, such labels are constrained to [US-ASCII] letters,
digits, and the hyphen, with the hyphen prohibited in the first
character position. Additional qualifications apply (refer to
the above-referenced specifications for details), but they are
not relevant here.
This specification assumes that the name of an application service is 2. An "internationalized domain name", a DNS domain name that
based on a DNS domain name (e.g., "example.com") -- supplemented in includes at least one label containing appropriately encoded
some circumstances by an application service type (e.g., "the IMAP Unicode code points outside the traditional US-ASCII range. That
server at example.com"). is, it contains at 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 [IDNA-DEFS] and the associated documents.
From the perspective of the application client or user, some names From the perspective of the application client or user, some names
are direct because they are provided directly by a human user (e.g., are _direct_ because they are provided directly by a human user.
via runtime input, prior configuration, or explicit acceptance of a This includes runtime input, prior configuration, or explicit
client communication attempt), whereas other names are indirect acceptance of a client communication attempt. Other names are
because they are automatically resolved by the client based on user _indirect_ because they are automatically resolved by the application
input (e.g., a target name resolved from a source name using DNS SRV based on user input, such as a target name resolved from a source
or NAPTR records). This dimension matters most for certificate name using DNS SRV or [NAPTR] records). The distinction matters most
consumption, specifically verification as discussed in this document. for certificate consumption, specifically verification as discussed
in this document.
From the perspective of the application service, some names are From the perspective of the application service, some names are
unrestricted because they can be used in any type of service (e.g., a _unrestricted_ because they can be used in any type of service, such
certificate might be reused for both the HTTP service and the IMAP as a single certificate being used for both the HTTP and IMAP
service at example.com), whereas other names are restricted because services at the host example.com. Other names are _restricted_
they can be used in only one type of service (e.g., a special-purpose because they can only be used for one type of service, such as a
certificate that can be used only for an IMAP service). This special-purpose certificate that can only be used for an IMAP
dimension matters most for certificate issuance. service. This distinction matters most for certificate issuance.
Therefore, we can categorize the identifier types of interest as We can categorize the supported identifier types as follows:
follows:
* A DNS-ID is direct and unrestricted. * A DNS-ID is direct and unrestricted.
* An SRV-ID is typically indirect but can be direct, and is * An SRV-ID is typically indirect but can be direct, and is
restricted. restricted.
* A URI-ID is direct and restricted. * A URI-ID is direct and restricted.
When implementing software, deploying services, and issuing It is important to keep these distinctions in mind, as best practices
certificates for secure PKIX-based authentication, it is important to for the deployment and use of the identifiers differ. As a further
keep these distinctions in mind. In particular, best practices example, cross-protocol attacks such as [ALPACA] are possibile when
differ somewhat for application server implementations, application two different protocol services use the same certificate. This can
client implementations, application service providers, and be addressed by using restricted identifiers, or telling services to
certification authorities. Ideally, protocol specifications that not share certificates. Protocol specifications MUST specify which
reference this document will specify which identifiers are mandatory- identifiers are mandatory-to-implement and SHOULD provide operational
to-implement by servers and clients, which identifiers ought to be guidance when necessary.
supported by certificate issuers, and which identifiers ought to be
requested by application service providers. Because these
requirements differ across applications, it is impossible to
categorically stipulate universal rules (e.g., that all software
implementations, service providers, and certification authorities for
all application protocols need to use or support DNS-IDs as a
baseline for the purpose of interoperability).
However, it is preferable that each application protocol will at
least define a baseline that applies to the community of software
developers, application service providers, and CAs actively using or
supporting that technology (one such community, the CA/Browser Forum,
has codified such a baseline for "Extended Validation Certificates"
in [EV-CERTS]).
2.2. DNS Domain Names
For the purposes of this specification, the name of an application
service is (or is based on) a DNS domain name that conforms to one of
the following forms:
1. A "traditional domain name", i.e., a fully qualified DNS domain
name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH
labels" as described in [IDNA-DEFS]. Informally, such labels are
constrained to [US-ASCII] letters, digits, and the hyphen, with
the hyphen prohibited in the first character position.
Additional qualifications apply (please refer to the above-
referenced specifications for details), but they are not relevant
to this specification.
2. An "internationalized domain name", i.e., a DNS domain name that
conforms to the overall form of a domain name (informally, dot-
separated letter-digit-hyphen labels) but includes at least one
label containing appropriately encoded Unicode code points
outside the traditional US-ASCII range. That is, it contains at
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
[IDNA-DEFS] and the associated documents.
2.3. Subject Naming in PKIX Certificates
For our purposes, an application service can be identified by a name
or names carried in one or more of the following identifier types
within subjectAltName entries:
* DNS-ID
* SRV-ID
* URI-ID
The Common Name RDN MUST NOT be used to identify a service. Reasons The Common Name RDN MUST NOT be used to identify a service. 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.
For similar reasons, other RDN's within the Subject Name MUST NOT be For similar reasons, other RDN's within the Subject Name MUST NOT be
used to 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 defines how protocol designers should reference this
protocols, in the form of a checklist to follow when reusing the document, which MUST be a normative reference in their specification.
recommendations provided in this document. The technology MUST only use the identifiers defined in this
document. Its specification MAY choose to allow only one of them.
* If your technology does not use DNS SRV records to resolve the DNS If the technology does not use DNS SRV records to resolve the DNS
domain names of application services then consider stating that domain names of application services then its specification MUST
SRV-ID as defined in this document is not supported. Note that state that SRV-ID as defined in this document is not supported. 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
rely on representations of those records in PKIX certificates by on representations of those records in PKIX certificates by means of
means of SRV-IDs as defined in [SRVNAME]. SRV-IDs as defined in [SRVNAME].
* If your technology does not use use URIs to identify application If the technology does not use URI's to identify application
services, then consider stating that URI-ID as defined in this services, then its specification MUST state that URI-ID as defined in
document is not supported. Note that many existing application this 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
of URI-IDs. URI-IDs.
* If your technology disallows the wildcard character in DNS domain A technology MAY disallow the use of the wildcard character in DNS
names, then state the wildcard certificates as defined in this names. If it does so, then the specification MUST state that
document are not supported. 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 instructions 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 FQDN
fully qualified DNS domain name at which the application service at which the application service provider will provide the relevant
provider will provide the relevant application, the following rules application, the following rules apply to the representation of
apply to the representation of application service identities. The application service identities. Note that some of these rules are
reader needs to be aware that some of these rules are cumulative and cumulative and can interact in important ways that are illustrated
can interact in important ways that are illustrated later in this later in this document.
document.
1. The certificate SHOULD include a "DNS-ID" if possible as a 1. The certificate MUST include a "DNS-ID" as a baseline for
baseline for interoperability. interoperability.
2. If the service using the certificate deploys a technology for 2. If the service using the certificate deploys a technology for
which the relevant specification stipulates that certificates which the relevant specification stipulates that certificates
ought to include identifiers of type SRV-ID (e.g., this is true ought to include identifiers of type SRV-ID (e.g., this is true
of [XMPP]), then the certificate SHOULD include an SRV-ID. of [XMPP]), then the certificate SHOULD include an SRV-ID.
3. If the service using the certificate deploys a technology for 3. If the service using the certificate deploys a technology for
which the relevant specification stipulates that certificates which the relevant specification stipulates that certificates
ought to include identifiers of type URI-ID (e.g., this is true ought to include identifiers of type URI-ID (e.g., this is true
of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] of [SIP] as specified by [SIP-CERTS]), then the certificate
since [HTTP-TLS] does not describe usage of a URI-ID for HTTP SHOULD include a URI-ID. The scheme MUST be that of the protocol
services), then the certificate SHOULD include a URI-ID. The associated with the application service type and the "host"
scheme SHALL be that of the protocol associated with the component (or its equivalent) MUST be the FQDN of the service.
application service type and the "host" component (or its The application protocol specification MUST specify which URI
equivalent) SHALL be the fully qualified DNS domain name of the schemes are acceptable in URI-IDs contained in PKIX certificates
service. A specification that reuses this one MUST specify which used for the application protocol (e.g., sip but not sips or tel
URI schemes are to be considered acceptable in URI-IDs contained for SIP as described in [SIP-SIPS]).
in PKIX certificates used for the application protocol (e.g.,
"sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS],
or perhaps http and https for HTTP as might be described in a
future specification).
4. The certificate MAY include other application-specific 4. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-
identifiers for types that were defined before publication of ID as further explained under Section 7.3.
[SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names
or URI schemes do not exist; however, such application-specific
identifiers are not applicable to all application technologies
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 include other application-specific
ID as further explained under Section 7.4. identifiers for compatibility with a deployed base. Such
identifiers are out of scope for this specification.
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
"mail.example.net" servicing email addresses of the form servicing email addresses of the form user@example.net and
"user@example.net" and discoverable via DNS SRV lookups on the discoverable via DNS SRV lookups on the application service name of
application service name of "example.net". A certificate for this example.net. A certificate for this service might include SRV-IDs of
service might include SRV-IDs of "_imap.example.net" and _imap.example.net and _imaps.example.net (see [EMAIL-SRV]) along with
"_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of DNS-IDs of example.net and mail.example.net.
"example.net" and "mail.example.net".
Consider a SIP-accessible voice-over-IP (VoIP) server at the host Consider a SIP-accessible voice-over-IP (VoIP) server at the host
"voice.example.edu" servicing SIP addresses of the form voice.example.edu servicing SIP addresses of the form
"user@voice.example.edu" and identified by a URI of user@voice.example.edu and identified by a URI of
<sip:voice.example.edu>. A certificate for this service would <sip:voice.example.edu>. A certificate for this service would
include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along include a URI-ID of sip:voice.example.edu (see [SIP-CERTS]) along
with a DNS-ID of "voice.example.edu". with a DNS-ID of voice.example.edu.
Consider an XMPP-compatible instant messaging (IM) server at the host Consider an XMPP-compatible instant messaging (IM) server at the host
"im.example.org" servicing IM addresses of the form im.example.org servicing IM addresses of the form user@im.example.org
"user@im.example.org" and discoverable via DNS SRV lookups on the and discoverable via DNS SRV lookups on the im.example.org domain. A
"im.example.org" domain. A certificate for this service might certificate for this service might include SRV-IDs of _xmpp-
include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- client.im.example.org and _xmpp-server.im.example.org (see [XMPP]), a
server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", DNS-ID of im.example.org. For backward compatibility, it may also
and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). have an XMPP-specific XmppAddr of im.example.org (see [XMPP]).
5. Requesting Server Certificates 5. Requesting Server Certificates
This section provides rules and guidelines for service providers This section provides instructions for service providers regarding
regarding the information to include in certificate signing requests the information to include in certificate signing requests (CSRs).
(CSRs). In general, service providers SHOULD request certificates that
include all of the identifier types that are required or recommended
for the application service type that will be secured using the
certificate to be issued.
In general, service providers are encouraged to request certificates If the certificate will be used for only a single type of application
that include all of the identifier types that are required or service, the service provider SHOULD request a certificate that
recommended for the application service type that will be secured includes a DNS-ID and, if appropriate for the application service
using the certificate to be issued. type, an SRV-ID or URI-ID that limits the deployment scope of the
certificate to only the defined application service type.
If the certificate might be used for any type of application service, If the certificate might be used for any type of application service,
then the service provider is encouraged to request a certificate that then the service provider SHOULD to request a certificate that
includes only a DNS-ID. includes only a DNS-ID. Again, because of multi-protocol attacks
this practice is discouraged; this can be mitigated by providing only
If the certificate will be used for only a single type of application one service on a host.
service, then the service provider is encouraged to request a
certificate that includes a DNS-ID and, if appropriate for the
application service type, an SRV-ID or URI-ID that limits the
deployment scope of the certificate to only the defined application
service type.
If a service provider offering multiple application service types If a service provider offersmultiple application service types and
(e.g., a World Wide Web service, an email service, and an instant wishes to limit the applicability of certificates using SRV-IDs or
messaging service) wishes to limit the applicability of certificates URI-IDs, they SHOULD request multiple certificates, rather than a
using SRV-IDs or URI-IDs, then the service provider is encouraged to single certificate containing multiple SRV-IDs or URI-IDs each
request multiple certificates, i.e., one certificate per application identifying ia different application service type. This rule does
service type. Conversely, the service provider is discouraged from not apply to application service type "bundles" that identify
requesting a single certificate containing multiple SRV-IDs or URI- distinct access methods to the same underlying application such as an
IDs identifying each different application service type. This email application with access methods denoted by the application
guideline does not apply to application service type "bundles" that service types of imap, imaps, pop3, pop3s, and submission as
are used to identify manifold distinct access methods to the same described in [EMAIL-SRV].
underlying application (e.g., an email application with access
methods denoted by the application service types of "imap", "imaps",
"pop3", "pop3s", and "submission" as described in [EMAIL-SRV]).
6. Verifying Service Identity 6. Verifying Service Identity
This section provides rules and guidelines for implementers of
application client software regarding algorithms for verification of
application service identity.
6.1. Overview
At a high level, the client verifies the application service's At a high level, the client verifies the application service's
identity by performing the actions listed below (which are defined in identity by performing the following actions:
the following subsections of this document):
1. The client constructs a list of acceptable reference identifiers 1. The client constructs a list of acceptable reference identifiers
based on the source domain and, optionally, the type of service based on the source domain and, optionally, the type of service
to which the client is connecting. to which the client is connecting.
2. The server provides its identifiers in the form of a PKIX 2. The server provides its identifiers in the form of a PKIX
certificate. certificate.
3. The client checks each of its reference identifiers against the 3. The client checks each of its reference identifiers against the
presented identifiers for the purpose of finding a match. presented identifiers for the purpose of finding a match. When
checking a reference identifier against a presented identifier,
4. When checking a reference identifier against a presented the client matches the source domain of the identifiers and,
identifier, the client matches the source domain of the optionally, their application service type.
identifiers and, optionally, their application service type.
Naturally, in addition to checking identifiers, a client might Naturally, in addition to checking identifiers, a client should
complete further checks to ensure that the server is authorized to perform further checks, such as expiration and revocation, to ensure
provide the requested service. However, such checking is not a that the server is authorized to provide the requested service. Such
matter of verifying the application service identity presented in a checking is not a matter of verifying the application service
certificate, and therefore methods for doing so (e.g., consulting identity presented in a certificate, however, and methods for doing
local policy information) are out of scope for this document. so are therefore out of scope for this document.
6.2. Constructing a List of Reference Identifiers 6.1. Constructing a List of Reference Identifiers
6.2.1. Rules 6.1.1. Rules
The client MUST construct a list of acceptable reference identifiers, The client MUST construct a list of acceptable reference identifiers,
and MUST do so independently of the identifiers presented by the and MUST do so independently of the identifiers presented by the
service. service.
The inputs used by the client to construct its list of reference The inputs used by the client to construct its list of reference
identifiers might be a URI that a user has typed into an interface identifiers might be a URI that a user has typed into an interface
(e.g., an HTTPS URL for a website), configured account information (e.g., an HTTPS URL for a website), configured account information
(e.g., the domain name of a particular host or URI used for (e.g., the domain name of a host for retrieving email, which might be
retrieving information or connecting to a network, which might be
different from the DNS domain name portion of a username), a different from the DNS domain name portion of a username), a
hyperlink in a web page that triggers a browser to retrieve a media hyperlink in a web page that triggers a browser to retrieve a media
object or script, or some other combination of information that can object or script, or some other combination of information that can
yield a source domain and an application service type. yield a source domain and an application service type.
The client might need to extract the source domain and application The client might need to extract the source domain and application
service type from the input(s) it has received. The extracted data service type from the input(s) it has received. The extracted data
MUST include only information that can be securely parsed out of the MUST include only information that can be securely parsed out of the
inputs (e.g., parsing the fully qualified DNS domain name out of the inputs, such as parsing the FQDN out of the "host" component or
"host" component (or its equivalent) of a URI or deriving the deriving the application service type from the scheme of a URI.
application service type from the scheme of a URI) or information Other possibilities include pulling the data from a delegated domain
that is derived in a manner not subject to subversion by network that is explicitly established via client or system configuration,
attackers (e.g., pulling the data from a delegated domain that is resolving the data via [DNSSEC], or obtaining the data from a third-
explicitly established via client or system configuration, resolving party domain mapping service in which a human user has explicitly
the data via [DNSSEC], or obtaining the data from a third-party placed trust and with which the client communicates over a connection
domain mapping service in which a human user has explicitly placed or association that provides both mutual authentication and integrity
trust and with which the client communicates over a connection or checking. These considerations apply only to extraction of the
association that provides both mutual authentication and integrity source domain from the inputs. Naturally, if the inputs themselves
checking). These considerations apply only to extraction of the
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.
For 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 and would derive the application service type sip from the scheme and
parse the domain name "example.net" from the host component. parse the domain name example.net from the host component.
Each reference identifier in the list SHOULD be based on the source Each reference identifier in the list MUST be based on the source
domain and SHOULD NOT be based on a derived domain (e.g., a host name domain and MUST NOT be based on a derived domain such as a domain
or domain name discovered through DNS resolution of the source name discovered through DNS resolution of the source domain. This
domain). This rule is important because only a match between the rule is important because only a match between the user inputs and a
user inputs and a presented identifier enables the client to be sure presented identifier enables the client to be sure that the
that the certificate can legitimately be used to secure the client's 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.
it is acceptable for an interactive client to override the
recommendation in this rule and therefore communicate with a domain
name other than the source domain: because a human user has "pinned"
the application service's certificate to the alternative domain name
as further discussed under Section 6.6.4 and Section 7.1. In this
case, the inputs used by the client to construct its list of
reference identifiers might include more than one fully qualified DNS
domain name, i.e., both (a) the source domain and (b) the alternative
domain contained in the pinned certificate.
Using the combination of fully qualified DNS domain name(s) and Using the combination of FQDN(s) and application service type, the
application service type, the client constructs a list of reference client MUST construct its list of reference identifiers in accordance
identifiers in accordance with the following rules: with the following rules:
* The list SHOULD include a DNS-ID. A reference identifier of type * The list SHOULD include a DNS-ID. A reference identifier of type
DNS-ID can be directly constructed from a fully qualified DNS DNS-ID can be directly constructed from a FQDN that is (a)
domain name that is (a) contained in or securely derived from the contained in or securely derived from the inputs, or (b)
inputs (i.e., the source domain), or (b) explicitly associated explicitly associated with the source domain by means of user
with the source domain by means of user configuration (i.e., a configuration.
derived domain).
* If a server for the application service type is typically * If a server for the application service type is typically
discovered by means of DNS SRV records, then the list SHOULD discovered by means of DNS SRV records, then the list SHOULD
include an SRV-ID. include an SRV-ID.
* If a server for the application service type is typically * If a server for the application service type is typically
associated with a URI for security purposes (i.e., a formal associated with a URI for security purposes (i.e., a formal
protocol document specifies the use of URIs in server protocol document specifies the use of URIs in server
certificates), then the list SHOULD include a URI-ID. certificates), then the list SHOULD include a URI-ID.
Which identifier types a client includes in its list of reference Which identifier types a client includes in its list of reference
identifiers is a matter of local policy. For example, in certain identifiers, and their priority, is a matter of local policy. For
deployment environments, a client that is built to connect only to a example, a client that is built to connect only to a particular kind
particular kind of service (e.g., only IM services) might be of service might be configured to accept as valid only certificates
configured to accept as valid only certificates that include an SRV- that include an SRV-ID for that application service type. By
ID for that application service type; in this case, the client would contrast, a more lenient client, even if built to connect only to a
include only SRV-IDs matching the application service type in its particular kind of service, might include both SRV-IDs and DNS-IDs in
list of reference identifiers (not, for example, DNS-IDs). By
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
its list of reference identifiers. its list of reference identifiers.
6.2.2. Examples 6.1.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
of "www.example.com". 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. An
(A legacy email user agent would not support [EMAIL-SRV] and email user agentthat does not support [EMAIL-SRV] would probably be
therefore would probably be explicitly configured to connect to explicitly configured to connect to mail.example.net, whereas an SRV-
"mail.example.net", whereas an SRV-aware user agent would derive aware user agent would derive example.net from an email address of
"example.net" from an email address of the form "user@example.net" the form user@example.net but might also accept mail.example.net as
but might also accept "mail.example.net" as the DNS domain name the DNS domain name portion of reference identifiers for the service.
portion of reference identifiers for the service.)
A voice-over-IP (VoIP) user agent that is connecting via SIP to the A voice-over-IP (VoIP) user agent that is connecting via SIP to the
voice service at "voice.example.edu" might have only one reference voice service at voice.example.edu might have only one reference
identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). identifier: a URI-ID of sip:voice.example.edu (see [SIP-CERTS]).
An instant messaging (IM) client that is connecting via XMPP to the An instant messaging (IM) client that is connecting via XMPP to the
IM service at "im.example.org" might have three reference IM service at im.example.org might have three reference identifiers:
identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), an SRV-ID of _xmpp-client.im.example.org (see [XMPP]), a DNS-ID of
a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of im.example.org, and an XMPP-specific XmppAddr of im.example.org (see
"im.example.org" (see [XMPP]). [XMPP]).
6.3. Preparing to Seek a Match 6.2. Preparing to Seek a Match
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.
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 DNS-ID reference identifier MUST be used directly as the DNS
application service type portion and thus can be used directly as domain name and there is no application service type.
the DNS domain name for comparison purposes. As an example, a
DNS-ID of "www.example.com" would result in a DNS domain name
portion of "www.example.com".
* For a reference identifier of type SRV-ID, the DNS domain name * For an SRV-ID reference identifier, the DNS domain name portion is
portion is the Name and the application service type portion is the Name and the application service type portion is the Service.
the Service. As an example, an SRV-ID of "_imaps.example.net" For example, an SRV-ID of _imaps.example.net has a DNS domain name
would be split into a DNS domain name portion of "example.net" and portion of example.net and an application service type portion of
an application service type portion of "imaps" (mapping to an imaps, which maps to the IMAP application protocol as explained in
application protocol of IMAP as explained in [EMAIL-SRV]). [EMAIL-SRV].
* For a reference identifier of type URI-ID, the DNS domain name * For a reference identifier of type URI-ID, the DNS domain name
portion is the "reg-name" part of the "host" component (or its portion is the "reg-name" part of the "host" component and the
equivalent) and the application service type portion is the application service type portion is the scheme, as defind above.
application service type associated with the scheme name matching Matching only the "reg-name" rule from [URI] limits verification
the [ABNF] "scheme" rule from [URI] (not including the ':' to DNS domain names, thereby differentiating a URI-ID from a
separator). As previously mentioned, this document specifies that uniformResourceIdentifier entry that contains an IP address or a
a URI-ID always contains a "host" component (or its equivalent) mere host name, or that does not contain a "host" component at
containing a "reg-name". (Matching only the "reg-name" rule from all. Furthermore, note that extraction of the "reg-name" might
[URI] limits verification to DNS domain names, thereby necessitate normalization of the URI (as explained in [URI]). For
differentiating a URI-ID from a uniformResourceIdentifier entry example, a URI-ID of sip:voice.example.edu would be split into a
that contains an IP address or a mere host name, or that does not DNS domain name portion of voice.example.edu and an application
contain a "host" component at all.) Furthermore, note that service type of sip (associated with an application protocol of
extraction of the "reg-name" might necessitate normalization of SIP as explained in [SIP-CERTS]).
the URI (as explained in [URI]). As an example, a URI-ID of
"sip:voice.example.edu" would be split into a DNS domain name
portion of "voice.example.edu" and an application service type of
"sip" (associated with an application protocol of SIP as explained
in [SIP-CERTS]).
Detailed comparison rules for matching the DNS domain name portion
and application service type portion of the reference identifier are
provided in the following sections.
6.4. Matching the DNS Domain Name Portion A client MUST match the DNS name, and if an application service type
is present it MUST also match the service type as well. These are
described below.
The client MUST match the DNS domain name portion of a reference 6.3. Matching the DNS Domain Name Portion
identifier according to the following rules (and SHOULD also check
the application service type as described under Section 6.5). The
rules differ depending on whether the domain to be checked is a
"traditional domain name" or an "internationalized domain name" (as
defined under Section 2.2). Furthermore, to meet the needs of
clients that support presented identifiers containing the wildcard
character "*", we define a supplemental rule for such "wildcard
certificates".
6.4.1. Checking of Traditional Domain Names This section describes how the client must determine if the the
presented DNS name matches the reference DNS name. The rules differ
depending on whether the domain to be checked is a "traditional
domain name" or an "internationalized domain name" (as defined under
Section 2). For clients that support names containing the wildcard
character "*", this section also specifies a supplemental rule for
such "wildcard certificates". This section uses the description of
labels and domain names in [DNS-CONCEPTS].
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 MUST be performed by comparing the
domain name labels using a case-insensitive ASCII comparison, as set of domain name labels using a case-insensitive ASCII comparison,
clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased as clarified by [DNS-CASE]. For example, WWW.Example.Com would be
to "www.example.com" for comparison purposes). Each label MUST match lower-cased to www.example.com for comparison purposes. Each label
in order for the names to be considered to match, except as MUST match in order for the names to be considered to match, except
supplemented by the rule about checking of wildcard labels as supplemented by the rule about checking of wildcard labels given
(Section 6.4.3). below.
6.4.2. Checking of Internationalized Domain Names
If the DNS domain name portion of a reference identifier is an If the DNS domain name portion of a reference identifier is an
internationalized domain name, then an implementation MUST convert internationalized domain name, then the client MUST convert any
any U-labels [IDNA-DEFS] in the domain name to A-labels before U-labels [IDNA-DEFS] in the domain name to A-labels before checking
checking the domain name. In accordance with [IDNA-PROTO], A-labels the domain name. In accordance with [IDNA-PROTO], A-labels MUST be
MUST be compared as case-insensitive ASCII. Each label MUST match in compared as case-insensitive ASCII. Each label MUST match in order
order for the domain names to be considered to match, except as 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 given
(Section 6.4.3; but see also Section 7.2 regarding wildcards in below.
internationalized domain names).
6.4.3. Checking of Wildcard Certificates
A client MAY match the reference identifier against a presented If the technology specification supports wildcards, then the client
identifier whose DNS domain name portion contains the wildcard MUST match the reference identifier against a presented identifier
character "*" in a label (following the description of labels and whose DNS domain name portion contains the wildcard character "*" in
domain names in [DNS-CONCEPTS]), provided these requirements are met: a label provided these requirements are met:
1. There is only one wildcard character. 1. There is only one wildcard character.
2. The wildcard character appears only as the content of the left- 2. The wildcard character appears only as the content of the left-
most label. most label.
3. The wildcard character is not embedded in an A-label or U-label If the requirements are not met, the presented identifier is invalid
[IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. and MUST be ignored.
A wildcard in a presented identifier can only match exactly one label A wildcard in a presented identifier can only match exactly one label
in a reference identifier. Note that this is not the same as DNS in a reference identifier. Note that this is not the same as DNS
wildcard matching, where the "*" label always matches at least one wildcard matching, where the "*" label always matches at least one
whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3 whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3
and [DNS-WILDCARDS]. and [DNS-WILDCARDS].
For information regarding the security characteristics of wildcard For information regarding the security characteristics of wildcard
certificates, see Section 7.2. certificates, see Section 7.1.
6.5. Matching the Application Service Type Portion
When a client checks identifiers of type SRV-ID and URI-ID, it MUST 6.4. Matching the Application Service Type Portion
check not only the DNS domain name portion of the identifier but also
the application service type portion. The client does this by
splitting the identifier into the DNS domain name portion and the
application service type portion (as described under Section 6.3),
then checking both the DNS domain name portion (as described under
Section 6.4) and the application service type portion as described in
the following subsections.
Implementation Note: An identifier of type SRV-ID or URI-ID provides The rules for matching the application service type deopend on
an application service type portion to be checked, but that portion whether the identifier is an SRV-ID or a URI-ID.
is combined only with the DNS domain name portion of the SRV-ID or
URI-ID itself. For example, if a client's list of reference
identifiers includes an SRV-ID of "_xmpp-client.im.example.org" and a
DNS-ID of "apps.example.net", the client would check (a) the
combination of an application service type of "xmpp-client" and a DNS
domain name of "im.example.org" and (b) a DNS domain name of
"apps.example.net". However, the client would not check (c) the
combination of an application service type of "xmpp-client" and a DNS
domain name of "apps.example.net" because it does not have an SRV-ID
of "_xmpp-client.apps.example.net" in its list of reference
identifiers.
6.5.1. SRV-ID These identifiers provide an application service type portion to be
checked, but that portion is combined only with the DNS domain name
portion of the SRV-ID or URI-ID itself. For example, if a client's
list of reference identifiers includes an SRV-ID of _xmpp-
client.im.example.org and a DNS-ID of apps.example.net, the client
would check both the combination of an application service type of
xmpp-client and a DNS domain name of im.example.org and a DNS domain
name of apps.example.net. However, the client would not check the
combination of an application service type of xmpp-client and a DNS
domain name of apps.example.net because it does not have an SRV-ID of
_xmpp-client.apps.example.net in its list of reference identifiers.
The application service name portion of an SRV-ID (e.g., "imaps") If the identifier is an SRV-ID, then the application service name
MUST be matched in a case-insensitive manner, in accordance with MUST be matched in a case-insensitive manner, in accordance with
[DNS-SRV]. Note that the "_" character is prepended to the service [DNS-SRV]. Note that the _ character is prepended to the service
identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and
thus does not need to be included in any comparison. thus does not need to be included in any comparison.
6.5.2. URI-ID If the identifier is a URI-ID, then the scheme name portion MUST be
matched in a case-insensitive manner, in accordance with [URI]. Note
The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in that the : character is a separator between the scheme name and the
a case-insensitive manner, in accordance with [URI]. Note that the rest of the URI, and thus does not need to be included in any
":" character is a separator between the scheme name and the rest of comparison.
the URI, and thus does not need to be included in any comparison.
6.6. Outcome
The outcome of the matching procedure is one of the following cases.
6.6.1. Case #1: Match Found 6.5. Outcome
If the client has found a presented identifier that matches a If the client has found a presented identifier that matches a
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
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 then the client MUST proceed as described
application service's certificate to one of the reference identifiers as follows.
in the list it constructed for this communication attempt (as
"pinning" is explained under Section 1.8), and the presented
certificate matches the pinned certificate (including the context as
described under Section 7.1), then the service identity check has
succeeded.
6.6.3. Case #3: No Match Found, No Pinned Certificate
If the client does not find a presented identifier matching any of
the reference identifiers and the client has not previously pinned
the certificate to one of the reference identifiers in the list it
constructed for this communication attempt, then the client MUST
proceed as described under Section 6.6.4.
6.6.4. Fallback If the client is an automated application not directly controlled by
a human user, then it SHOULD terminate the communication attempt with
a bad certificate error and log the error appropriately. The
application MAY provide a configuration setting to disable this
behavior, but it MUST enable it by default.
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 in order to prevent users from inadvertently
users from inadvertently bypassing security protections in hostile bypassing security protections in hostile situations.
situations.
Some interactive clients give advanced users the option of proceeding Some interactive clients MAY give advanced users the option of
with acceptance despite the identity mismatch. Although this proceeding with acceptance despite the identity mismatch. Although
behavior can be appropriate in certain specialized circumstances, it this behavior can be appropriate in certain specialized
needs to be handled with extreme caution, for example by first circumstances, it needs to be handled with extreme caution, for
encouraging even an advanced user to terminate the communication example by first encouraging even an advanced user to terminate the
attempt and, if the advanced user chooses to proceed anyway, by communication attempt and, if they choose to proceed anyway, by
forcing the user to view the entire certification path before forcing the user to view the entire certification path before
proceeding. proceeding.
Otherwise, if the client is an automated application not directly The application MAY also present the user with the ability to accept
controlled by a human user, then it SHOULD terminate the the presented certificate as valid for subsequent connections. Such
communication attempt with a bad certificate error and log the error ad-hoc "pinning" SHOULD NOT restrict future connections to just the
appropriately. An automated application MAY provide a configuration pinned certificate. Local policy that statically enforces a given
setting that disables this behavior, but MUST enable the behavior by certificate for a given peer is best made available only as prior
default. configuration, rather than a just-in-time override for a failed
connection.
7. Security Considerations 7. Security Considerations
7.1. Pinned Certificates 7.1. Wildcard Certificates
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
service's certificate with that DNS domain name despite the fact that
the certificate contains some other DNS domain name (e.g., the user
has explicitly approved "apps.example.net" as a domain associated
with a source domain of "example.com"). The cached name association
MUST take account of both the certificate presented and the context
in which it was accepted or configured (where the "context" includes
the chain of certificates from the presented certificate to the trust
anchor, the source domain, the application service type, the
service's derived domain and port number, and any other relevant
information provided by the user or associated by the client).
7.2. Wildcard Certificates
Wildcard certificates, those that have an identifier with "*" as the Wildcard certificates, those that have an identifier with "*" as the
left-most DNS label, automatically vouch for any single-label host left-most DNS label, automatically vouch for any single-label host
names within their domain, but not multiple levels of domains. This names within their domain, but not multiple levels of domains. This
can be convenient for administrators but also poses the risk of can be convenient for administrators but also poses the risk of
vouching for rogue or buggy hosts. See for example [Defeating-SSL] vouching for rogue or buggy hosts. See for example [Defeating-SSL]
(beginning at slide 91) and [HTTPSbytes] (slides 38-40). (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 public suffix
suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of
document. this document.
7.3. Internationalized Domain Names 7.2. Internationalized Domain Names
Allowing internationalized domain names can lead to the inclusion of Allowing internationalized domain names can lead to visually similar
visually similar (so-called "confusable") characters in certificates; characters, also referred to as "confusables", being included within
for discussion, see for example [IDNA-DEFS]. certificates. For discussion, see for example [IDNA-DEFS],
Section 4.4 and [UTS-39].
7.4. Multiple Identifiers 7.3. Multiple Presented 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 or protocols. The client SHOULD use the TLS Server multiple domains or protocols. TLS Extensions such as TLS Server
Name Identification (SNI) extension as discussed in [TLS], Name Identification (SNI), discussed in [TLS], Section 4.4.2.2, and
Section 4.4.2.2. Application Layer Protocol Negotiation (ALPN), discussed in [ALPN],
provide a way for the application to indicate the desired identifier
and protocol to the server, which can be used to select the most
appropriate certificate.
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. IANA Considerations
8.1. Normative References This document has no actions for IANA.
9. References
9.1. Normative References
[DNS-CONCEPTS] [DNS-CONCEPTS]
Mockapetris, P.V., "Domain names - concepts and Mockapetris, P., "Domain names - concepts and facilities",
facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
November 1987, <https://doi.org/10.17487/RFC1034>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC2782>. <https://www.rfc-editor.org/rfc/rfc2782>.
[DNS-WILDCARDS] [DNS-WILDCARDS]
Lewis, E., "The Role of Wildcards in the Domain Name Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, DOI 10.17487/RFC4592, July 2006, System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
<https://doi.org/10.17487/RFC4592>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC5890>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC5891>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC4514>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC5280>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC2119>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC8174>. May 2017, <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC4985>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC3986>. <https://www.rfc-editor.org/rfc/rfc3986>.
8.2. Informative References 9.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://doi.org/10.17487/RFC5234>. <https://www.rfc-editor.org/rfc/rfc5234>.
[ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>.
[ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D.,
Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel,
"ALPACA: Application Layer Protocol Confusion - Analyzing
and Mitigating Cracks in TLS Authentication", September
2021, <https://alpaca-attack.com/ALPACA.pdf>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>.
[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://doi.org/10.17487/RFC4343>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC4033>. <https://www.rfc-editor.org/rfc/rfc4033>.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://doi.org/10.17487/RFC6347>. January 2012, <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC6186>. <https://www.rfc-editor.org/rfc/rfc6186>.
[EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And
Management Of Extended Validation Certificates", October
2009, <http://www.cabforum.org/Guidelines_v1_2.pdf>.
[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://doi.org/10.17487/RFC7230>.
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<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
Internet Protocol", RFC 4301, DOI 10.17487/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://doi.org/10.17487/RFC3403>. <https://www.rfc-editor.org/rfc/rfc3403>.
[OCSP] Santesson, S., Myers, M., Ankney, R., Malpani, A., [NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Galperin, S., and C. Adams, "X.509 Internet Public Key Sundblad, "Network Time Security for the Network Time
Infrastructure Online Certificate Status Protocol - OCSP", Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/rfc/rfc8915>.
<https://doi.org/10.17487/RFC6960>.
[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [Public-Suffix]
Thayer, "OpenPGP Message Format", RFC 4880, "Public Suffix List", 2020, <https://publicsuffix.org>.
DOI 10.17487/RFC4880, November 2007,
<https://doi.org/10.17487/RFC4880>.
[S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application [QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
Service Location Using SRV RRs and the Dynamic Delegation QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, <https://www.rfc-editor.org/rfc/rfc9001>.
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://doi.org/10.17487/RFC4949>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC3261>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC5922>. <https://www.rfc-editor.org/rfc/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://doi.org/10.17487/RFC5630>. <https://www.rfc-editor.org/rfc/rfc5630>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://doi.org/10.17487/RFC8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[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.
[UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms",
n.d., <https://unicode.org/reports/tr39>.
[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://doi.org/10.17487/RFC6125>. 2011, <https://www.rfc-editor.org/rfc/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", August 2010,
WD-wsc-ui-20100309, March 2010, <https://www.w3.org/TR/2010/REC-wsc-ui-20100812/>.
<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
[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://doi.org/10.17487/RFC6120>. March 2011, <https://www.rfc-editor.org/rfc/rfc6120>.
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]. Thanks also to Carsten Bormann
for converting the previous document to Markdown so that we could
more easily use Martin Thomson's i-d-template software.
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
 End of changes. 162 change blocks. 
810 lines changed or deleted 538 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/