rfc9525.original   rfc9525.txt 
Network Working Group P. Saint-Andre Internet Engineering Task Force (IETF) P. Saint-Andre
Internet-Draft independent Request for Comments: 9525 Independent
Obsoletes: 6125 (if approved) R. Salz Obsoletes: 6125 R. Salz
Intended status: Standards Track Akamai Technologies Category: Standards Track Akamai Technologies
Expires: 11 February 2024 10 August 2023 ISSN: 2070-1721 November 2023
Service Identity in TLS Service Identity in TLS
draft-ietf-uta-rfc6125bis-15
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. This document obsoletes RFC 6125.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Using TLS in
Applications Working Group mailing list (uta@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/uta/.
Source for this draft and an issue tracker can be found at
https://github.com/richsalz/draft-ietf-uta-rfc6125bis.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 11 February 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9525.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Applicability
1.3. Overview of Recommendations . . . . . . . . . . . . . . . 4 1.3. Overview of Recommendations
1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Scope
1.4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 4 1.4.1. In Scope
1.4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5 1.4.2. Out of Scope
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Terminology
2. Identifying Application Services . . . . . . . . . . . . . . 8 2. Identifying Application Services
3. Designing Application Protocols . . . . . . . . . . . . . . . 10 3. Designing Application Protocols
4. Representing Server Identity . . . . . . . . . . . . . . . . 11 4. Representing Server Identity
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Rules
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Examples
5. Requesting Server Certificates . . . . . . . . . . . . . . . 12 5. Requesting Server Certificates
6. Verifying Service Identity . . . . . . . . . . . . . . . . . 13 6. Verifying Service Identity
6.1. Constructing a List of Reference Identifiers . . . . . . 14 6.1. Constructing a List of Reference Identifiers
6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Rules
6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Examples
6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 17 6.2. Preparing to Seek a Match
6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 18 6.3. Matching the DNS Domain Name Portion
6.4. Matching an IP Address Portion . . . . . . . . . . . . . 19 6.4. Matching an IP Address Portion
6.5. Matching the Application Service Type Portion . . . . . . 19 6.5. Matching the Application Service Type Portion
6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6. Outcome
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations
7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 21 7.1. Wildcard Certificates
7.2. Uniform Resource Identifiers . . . . . . . . . . . . . . 21 7.2. Uniform Resource Identifiers
7.3. Internationalized Domain Names . . . . . . . . . . . . . 22 7.3. Internationalized Domain Names
7.4. IP Addresses . . . . . . . . . . . . . . . . . . . . . . 22 7.4. IP Addresses
7.5. Multiple Presented Identifiers . . . . . . . . . . . . . 23 7.5. Multiple Presented Identifiers
7.6. Multiple Reference Identifiers . . . . . . . . . . . . . 23 7.6. Multiple Reference Identifiers
7.7. Certificate Trust . . . . . . . . . . . . . . . . . . . . 24 7.7. Certificate Trust
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 26 9.2. Informative References
Appendix A. Changes from RFC 6125 . . . . . . . . . . . . . . . 30 Appendix A. Changes from RFC 6125
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 31 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses
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 a client communicates employ a client-server architecture in which a client communicates
with an application service. When a client communicates with an with an application service. When a client communicates with an
application service using [TLS], [DTLS], or a protocol built on those application service using [TLS], [DTLS], or a protocol built on those
([QUIC] being a notable example), it has some notion of the server's ([QUIC] being a notable example), it has some notion of the server's
identity (e.g., "the website at bigcompany.example") while attempting identity (e.g., "the website at bigcompany.example") while attempting
to establish secure communication. Likewise, during TLS negotiation, to establish secure communication. Likewise, during TLS negotiation,
the server presents its notion of the service's identity in the form the server presents its notion of the service's identity in the form
of a public-key certificate that was issued by a certificate of a public key certificate that was issued by a certification
authority (CA) in the context of the Internet Public Key authority (CA) in the context of the Internet Public Key
Infrastructure using X.509 [PKIX]. Informally, we can think of these Infrastructure using X.509 [PKIX]. Informally, we can think of these
identities as the client's "reference identity" and the server's identities as the client's "reference identity" and the server's
"presented identity"; more formal definitions are given later. A "presented identity"; more formal definitions are given later. A
client needs to verify that the server's presented identity matches client needs to verify that the server's presented identity matches
its reference identity so it can deterministically and automatically its reference identity so it can deterministically and automatically
authenticate the communication. authenticate the communication.
This document defines procedures for how clients do this This document defines procedures for how clients perform this
verification. It therefore also defines requirements on other verification. It therefore defines requirements on other parties,
parties, such as the certificate authorities that issue certificates, such as the certification authorities that issue certificates, the
the service administrators requesting them, and the protocol service administrators requesting them, and the protocol designers
designers defining how things are named. defining interactions between clients and servers.
This document obsoletes RFC 6125. Changes from RFC 6125 are This document obsoletes RFC 6125 [VERIFY]. Changes from RFC 6125
described under Appendix A. [VERIFY] are described under Appendix A.
1.2. Applicability 1.2. Applicability
This document does not supersede the rules for certificate issuance This document does not supersede the rules for certificate issuance
or validation specified by [PKIX]. That document also governs any or validation specified by [PKIX]. That document also governs any
certificate-related topic on which this document is silent. This certificate-related topic on which this document is silent. This
includes certificate syntax, extensions such as name constraints or includes certificate syntax, extensions such as name constraints or
extended key usage, and handling of certification paths. 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. It does not address the name forms in the chain server certificate. It does not address the name forms in the chain
of certificates used to validate a certificate, let alone creating or of certificates used to validate a certificate, nor does it create or
checking the validity of such a chain. In order to ensure proper check the validity of such a chain. In order to ensure proper
authentication, applications need to verify the entire certification authentication, applications need to verify the entire certification
path. path.
1.3. Overview of Recommendations 1.3. Overview of Recommendations
The previous version of this specification, [VERIFY], surveyed the The previous version of this specification, [VERIFY], surveyed the
then-current practice from many IETF standards and tried to then-current practice from many IETF standards and tried to
generalize best practices (see Appendix A of [VERIFY] for details). generalize best practices (see Appendix A of [VERIFY] for details).
This document takes the lessons learned since then and codifies them. This document takes the lessons learned since then and codifies them.
skipping to change at page 4, line 49 skipping to change at line 173
This document applies only to service identities that are used in TLS This document applies only to service identities that are used in TLS
or DTLS and that are included in PKIX certificates. or DTLS and that are included in PKIX certificates.
With regard to TLS and DTLS, these security protocols are used to With regard to TLS and DTLS, these security protocols are used to
protect data exchanged over a wide variety of application protocols, protect data exchanged over a wide variety of application protocols,
which use both the TLS or DTLS handshake protocol and the TLS or DTLS which use both the TLS or DTLS handshake protocol and the TLS or DTLS
record layer, either directly or through a profile as in Network Time record layer, either directly or through a profile as in Network Time
Security [NTS]. The TLS handshake protocol can also be used with Security [NTS]. The TLS handshake protocol can also be used with
different record layers to define secure transport protocols; at different record layers to define secure transport protocols; at
present the most prominent example is QUIC [RFC9000]. The rules present, the most prominent example is QUIC [RFC9000]. The rules
specified here are intended to apply to all protocols in this specified here are intended to apply to all protocols in this
extended TLS "family". extended TLS "family".
With regard to PKIX certificates, the primary usage is in the context With regard to PKIX certificates, the primary usage is in the context
of the public key infrastructure described in [PKIX]. In addition, of the public key infrastructure described in [PKIX]. In addition,
technologies such as DNS-Based Authentication of Named Entities technologies such as DNS-Based Authentication of Named Entities
(DANE) [DANE] sometimes use certificates based on PKIX (more (DANE) [DANE] sometimes use certificates based on PKIX (more
precisely, certificates structured via [X.509] or specific encodings precisely, certificates structured via [X.509] or specific encodings
thereof such as [X.690]), at least in certain modes. Alternatively, thereof such as [X.690]), at least in certain modes. Alternatively,
a TLS peer could issue delegated credentials that are based on a CA- a TLS peer could issue delegated credentials that are based on a CA-
skipping to change at page 5, line 31 skipping to change at line 203
* Security protocols other than those described above. * Security protocols other than those described above.
* Keys or certificates employed outside the context of PKIX-based * Keys or certificates employed outside the context of PKIX-based
systems. systems.
* Client or end-user identities. Other than as described above, * Client or end-user identities. Other than as described above,
certificates representing client identities (e.g., rfc822Name) are certificates representing client identities (e.g., rfc822Name) are
beyond the scope of this document. beyond the scope of this document.
* Identification of servers using other than a domain name, IP * Identification of servers using other than a domain name, an IP
address, or SRV service name. This document discusses Uniform address, or an SRV service name. This document discusses Uniform
Resource Identifiers [URI] only to the extent that they are Resource Identifiers [URI] only to the extent that they are
expressed in certificates. Other aspects of a service such as a expressed in certificates. Other aspects of a service such as a
specific resource (the URI "path" component) or parameters (the specific resource (the URI "path" component) or parameters (the
URI "query" component) are the responsibility of specific URI "query" component) are the responsibility of specific
protocols or URI schemes. protocols or URI schemes.
* Certification authority policies. This includes items such as the * Certification authority policies. This includes items such as the
following: following:
- How to certify or validate fully-qualified domain names (FQDNs) - How to certify or validate fully qualified domain names (FQDNs)
and application service types (see [ACME] for some definition and application service types (see [ACME]).
of this).
- Types or "classes" of certificates to issue and whether to - What types or "classes" of certificates to issue and whether to
apply different policies for them. 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. Although the process whereby a * Resolution of DNS domain names. Although the process whereby a
client resolves the DNS domain name of an application service can client resolves the DNS domain name of an application service can
involve several steps, for the purposes of this specification the involve several steps, for the purposes of this specification, the
only relevant consideration is that the client needs to verify the only relevant consideration is that the client needs to verify the
identity of the entity with which it will communicate once the identity of the entity with which it will communicate once the
resolution process is complete. Thus, the resolution process resolution process is complete. Thus, the resolution process
itself is out of scope for this specification. itself is out of scope for this specification.
* User interface issues. In general, such issues are properly the * User interface issues. In general, such issues are properly the
responsibility of client software developers and standards responsibility of client software developers and standards
development organizations dedicated to particular application development organizations dedicated to particular application
technologies (see, for example, [WSC-UI]). technologies (for example, see [WSC-UI]).
1.5. Terminology 1.5. 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 clients application service: A service on the Internet that enables clients
to connect for the purpose of retrieving or uploading information, to connect for the purpose of retrieving or uploading information,
communicating with other entities, or connecting to a broader communicating with other entities, or connecting to a broader
network of services. network of services.
application service provider: An entity that hosts or deploys an application service provider: An entity that hosts or deploys an
application service. 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. This often appears as a URI scheme [URI], DNS SRV at a domain. This often appears as a URI scheme [URI], a DNS SRV
Service [DNS-SRV], or an ALPN [ALPN] identifier. Service [DNS-SRV], or an Application-Layer Protocol Negotiation
(ALPN) [ALPN] identifier.
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 be used for matching
for matching purposes. For conciseness and convenience, we define purposes. For conciseness and convenience, we define the
the following identifier types of interest: following identifier types of interest:
* DNS-ID: a subjectAltName entry of type dNSName as defined in DNS-ID: A subjectAltName entry of type dNSName as defined in
[PKIX]. [PKIX].
* IP-ID: a subjectAltName entry of type iPAddress as defined in IP-ID: A subjectAltName entry of type iPAddress as defined in
[PKIX]. [PKIX].
* SRV-ID: a subjectAltName entry of type otherName whose name SRV-ID: A subjectAltName entry of type otherName whose name form
form is SRVName, as defined in [SRVNAME]. is SRVName as defined in [SRVNAME].
* URI-ID: a subjectAltName entry of type URI-ID: A subjectAltName entry of type uniformResourceIdentifier
uniformResourceIdentifier as defined in [PKIX]. See further as defined in [PKIX]. See further discussion in Section 7.2.
discussion in Section 7.2.
PKIX: The short name for the Internet Public Key Infrastructure PKIX: The short name for the Internet Public Key Infrastructure
using X.509 defined in [PKIX]. That document provides a profile using X.509 defined in [PKIX]. That document provides a profile
of the X.509v3 certificate specifications and X.509v2 certificate of the X.509v3 certificate specifications and X.509v2 certificate
revocation list (CRL) specifications for use on the Internet. revocation list (CRL) specifications for use on the Internet.
presented identifier: An identifier presented by a server to a presented identifier: An identifier presented by a server to a
client within a PKIX certificate when the client attempts to client within a PKIX certificate when the client attempts to
establish secure communication with the server. The certificate establish secure communication with the server. The certificate
can include one or more presented identifiers of different types, can include one or more presented identifiers of different types,
and if the server hosts more than one domain then the certificate and if the server hosts more than one domain, then the certificate
might present distinct identifiers for each domain. might present distinct identifiers for each domain.
reference identifier: An identifier used by the client when reference identifier: An identifier expected by the client when
examining presented identifiers. It is constructed from the examining presented identifiers. It is constructed from the
source domain, and optionally an application service type. source domain and, optionally, an application service type.
Relative Distinguished Name (RDN): An ASN.1-based construction which Relative Distinguished Name (RDN): An ASN.1-based construction that
itself is a building-block component of Distinguished Names. See is itself a building-block component of Distinguished Names. See
[LDAP-DN], Section 2. [LDAP-DN], Section 2.
source domain: The fully qualified domain name (FQDN) 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
This is typically input by a human user, configured into a client, user, configured into a client, or provided by reference such as a
or provided by reference such as a URL. The combination of a URL. The combination of a source domain and, optionally, an
source domain and, optionally, an application service type enables application service type enables a client to construct one or more
a client to construct one or more reference identifiers. This reference identifiers. This specification covers FQDNs. Use of
specification covers FQDNs. Use of any names that are not fully any names that are not fully qualified is out of scope and may
qualified is out of scope and may result in unexpected or result in unexpected or undefined behavior.
undefined behavior.
subjectAltName entry: An identifier placed in a subjectAltName subjectAltName entry: An identifier placed in a subjectAltName
extension. extension.
subjectAltName extension: A standard PKIX extension enabling subjectAltName extension: A standard PKIX extension enabling
identifiers of various types to be bound to the certificate identifiers of various types to be bound to the certificate
subject. subject.
subjectName: The name of a PKIX certificate's subject, encoded in a subjectName: The name of a PKIX certificate's subject, encoded in a
certificate's subject field (see [PKIX], Section 4.1.2.6). certificate's subject field (see [PKIX], Section 4.1.2.6).
TLS uses the words "client" and "server," where the client is the TLS uses the words "client" and "server", where the client is the
entity that initiates the connection. In many cases, this is entity that initiates the connection. In many cases, this is
consistent with common practice, such as a browser connecting to a consistent with common practice, such as a browser connecting to a
Web origin. For the sake of clarity, and to follow the usage in web origin. For the sake of clarity, and to follow the usage in
[TLS] and related specifications, we will continue to use the terms [TLS] and related specifications, we will continue to use the terms
client and server in this document. However, these are TLS-layer client and server in this document. However, these are TLS-layer
roles, and the application protocol could support the TLS server roles, and the application protocol could support the TLS server
making requests to the TLS client after the TLS handshake; there is making requests to the TLS client after the TLS handshake; there is
no requirement that the roles at the application layer match the TLS no requirement that the roles at the application layer match the TLS
layer. layer.
Security-related terms used in this document, but not defined here or Security-related terms used in this document, but not defined here or
in [PKIX] should be understood in the sense defined in [SECTERMS]. in [PKIX], should be understood in the sense defined in [SECTERMS].
Such terms include "attack", "authentication", "identity", "trust", Such terms include "attack", "authentication", "identity", "trust",
"validate", and "verify". "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
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Identifying Application Services 2. Identifying Application Services
This document assumes that an application service is identified by a This document assumes that an application service is identified by a
DNS domain name (e.g., bigcompany.example), an IP address (IPv4 or DNS domain name (e.g., bigcompany.example), an IP address (IPv4 or
IPv6), or by an identifier that contains additional supplementary IPv6), or an identifier that contains additional supplementary
information. Supplementary information is limited to the application information. Supplementary information is limited to the application
service type as expressed in a DNS SRV record (e.g., "the IMAP server service type as expressed in a DNS SRV record (e.g., "the IMAP server
at isp.example" for "_imap.isp.example") or a URI. at isp.example" for "_imap.isp.example") or a URI.
In a DNS-ID - and in the DNS domain name portion of an SRV-ID or URI- In a DNS-ID -- and in the DNS domain name portion of an SRV-ID or
ID - any characters outside the [US-ASCII] range are prohibited and URI-ID -- any characters outside the range described in [US-ASCII]
internationalized domain labels are represented as A-labels are prohibited, and internationalized domain labels are represented
[IDNA-DEFS]. as A-labels [IDNA-DEFS].
An IP address is either a 4-octet IPv4 address [IPv4] or a 16-octet An IP address is either a 4-octet IPv4 address [IPv4] or a 16-octet
IPv6 address [IPv6]. The identifier might need to be converted from IPv6 address [IPv6]. The identifier might need to be converted from
a textual representation to obtain this value. a textual representation to obtain this value.
From the perspective of the application client or user, some From the perspective of the application client or user, some
identifiers are _direct_ because they are provided directly by a identifiers are _direct_ because they are provided directly by a
human user. This includes runtime input, prior configuration, or human user. This includes runtime input, prior configuration, or
explicit acceptance of a client communication attempt. Other names explicit acceptance of a client communication attempt. Other names
are _indirect_ because they are automatically resolved by the are _indirect_ because they are automatically resolved by the
application based on user input, such as a target name resolved from application based on user input, such as a target name resolved from
a source name using DNS SRV or [NAPTR] records. The distinction a source name using DNS SRV or the records described in [NAPTR]. The
matters most for certificate consumption, specifically verification distinction matters most for certificate consumption, specifically
as discussed in this document. verification as discussed in this document.
From the perspective of the application service, some identifiers are From the perspective of the application service, some identifiers are
_unrestricted_ because they can be used in any type of service, such _unrestricted_ because they can be used in any type of service, such
as a single certificate being used for both the HTTP and IMAP as a single certificate being used for both the HTTP and IMAP
services at the host "bigcompany.example". Other identifiers are services at the host "bigcompany.example". Other identifiers are
_restricted_ because they can only be used for one type of service, _restricted_ because they can only be used for one type of service,
such as a special-purpose certificate that can only be used for an such as a special-purpose certificate that can only be used for an
IMAP service. This distinction matters most for certificate IMAP service. This distinction matters most for certificate
issuance. issuance.
We can categorize the four identifier types as follows: The four identifier types can be categorized as follows:
* A DNS-ID is direct and unrestricted. * A DNS-ID is direct and unrestricted.
* An IP-ID is direct and unrestricted. * An IP-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 it is
restricted. restricted.
* A URI-ID is direct and restricted. * A URI-ID is direct and restricted.
It is important to keep these distinctions in mind, because best It is important to keep these distinctions in mind because best
practices for the deployment and use of the identifiers differ. Note practices for the deployment and use of the identifiers differ. Note
that cross-protocol attacks such as [ALPACA] are possible when two that cross-protocol attacks such as those described in [ALPACA] are
different protocol services use the same certificate. This can be possible when two different protocol services use the same
addressed by using restricted identifiers or deploying services so certificate. This can be addressed by using restricted identifiers
that they do not share certificates. Protocol specifications MUST or deploying services so that they do not share certificates.
specify which identifiers are mandatory-to-implement and SHOULD Protocol specifications MUST specify which identifiers are mandatory
provide operational guidance when necessary. to implement and SHOULD provide operational guidance when necessary.
The Common Name RDN MUST NOT be used to identify a service because it The Common Name RDN MUST NOT be used to identify a service because it
is not strongly typed (essentially free-form text) and therefore is not strongly typed (it is essentially free-form text) and
suffers from ambiguities in interpretation. therefore suffers from ambiguities in interpretation.
For similar reasons, other RDNs within the subjectName MUST NOT be For similar reasons, other RDNs within the subjectName MUST NOT be
used to identify a service. used to identify a service.
An IP address that is the result of a DNS query is not direct. Use An IP address that is the result of a DNS query is indirect. Use of
of IP-IDs that are not direct is out of scope for this document. IP-IDs that are indirect is out of scope for this document.
The IETF continues to define methods for looking up information The IETF continues to define methods for looking up information
needed to make connections to network services. One recent example needed to make connections to network services. One recent example
is service binding via the "SVCB" and "HTTPS" DNS resource record is service binding via the "SVCB" and "HTTPS" DNS resource record
(RR) types. This document does not define any identity (RR) types. This document does not define any identity
representation or verification procedures that are specific to SVCB- representation or verification procedures that are specific to SVCB-
compatible records, because the use of such records during connection compatible records, because the use of such records during connection
establishment does not currently alter any of the PKIX validation establishment does not currently alter any of the PKIX validation
requirements specified herein or in any other relevant specification. requirements specified herein or in any other relevant specification.
For example, the PKIX validation rules for [HTTP-OVER-TLS] and For example, the PKIX validation rules for [HTTP] and [DNS-OVER-TLS]
[DNS-OVER-TLS] do not change when the client uses [SVCB-FOR-HTTPS] or do not change when the client uses the DNS resource records defined
[SVCB-FOR-DNS]. However, it is possible that future SVCB mapping in [SVCB-FOR-HTTPS] or [SVCB-FOR-DNS] to look up connection
information. However, it is possible that future SVCB mapping
documents could specify altered PKIX rules for new use cases. documents could specify altered PKIX rules for new use cases.
3. Designing Application Protocols 3. Designing Application Protocols
This section defines how protocol designers should reference this This section defines how protocol designers should reference this
document, which would typically be a normative reference in their document, which would typically be a normative reference in their
specification. Its specification MAY choose to allow only one of the specification.
identifier types defined here.
A specification MAY choose to allow only one of the identifier types
defined here.
If the 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 its specification MUST domain names of application services, then the specification MUST
state that SRV-ID as defined in this document is not supported. Note state that SRV-ID as defined in this document is not supported. Note
that 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 rely resolve the DNS domain names of application services, but they do not
on representations of those records in PKIX certificates by means of rely on representations of those records in PKIX certificates by
SRV-IDs as defined in [SRVNAME]. means of SRV-IDs as defined in [SRVNAME].
If the technology does not use URIs to identify application services, If the technology does not use URIs to identify application services,
then its specification MUST state that URI-ID as defined in this then the specification MUST state that URI-ID as defined in this
document is not supported. Note that many existing application document is not supported. Note that many existing application
technologies use URIs to identify application services, but do not technologies use URIs to identify application services, but they do
rely on representation of those URIs in PKIX certificates by means of not rely on representation of those URIs in PKIX certificates by
URI-IDs. means of URI-IDs.
A technology MAY disallow the use of the wildcard character in A technology MAY disallow the use of the wildcard character in
presented identifiers. If it does so, then the specification MUST presented identifiers. If it does so, then the specification MUST
state that wildcard certificates as defined in this document are not state that wildcard certificates as defined in this document are not
supported. supported.
A protocol can allow the use of an IP address in place of a DNS name. A protocol can allow the use of an IP address in place of a DNS name.
This might use the same field without distinguishing the type of This might use the same field without distinguishing the type of
identifier, as for example in the "host" components of a URI. In identifier as, for example, in the "host" components of a URI. In
this case, applications need to be aware that the textual this case, applications need to be aware that the textual
representation of an IPv4 address is a valid DNS name. The two types representation of an IPv4 address is a valid DNS name. The two types
can be distinguished by first testing if the identifier is a valid can be distinguished by first testing if the identifier is a valid
IPv4 address, as is done by the "first-match-wins" algorithm in IPv4 address, as is done by the "first-match-wins" algorithm in
Section 3.2.2 of [URI]. Section 3.2.2 of [URI].
4. Representing Server Identity 4. Representing Server Identity
This section provides instructions for issuers of certificates. This section provides instructions for issuers of certificates.
4.1. Rules 4.1. Rules
When a certificate authority issues a certificate based on the FQDN When a certification authority issues a certificate based on the FQDN
at which the application service provider will provide the relevant at which the application service provider will provide the relevant
application, the following rules apply to the representation of application, the following rules apply to the representation of
application service identities. Note that some of these rules are application service identities. Note that some of these rules are
cumulative and can interact in important ways that are illustrated cumulative and can interact in important ways that are illustrated
later in this document. later in this document.
1. The certificate MUST include at least one identifier. 1. The certificate MUST include at least one identifier.
2. The certificate SHOULD include a DNS-ID as a baseline for 2. The certificate SHOULD include a DNS-ID as a baseline for
interoperability. This is not mandatory because it is legitimate interoperability. This is not mandatory because it is legitimate
for a certificate to include only an SRV-ID or URI-ID so as to for a certificate to include only an SRV-ID or URI-ID so as to
scope its use to a particular application type. scope its use to a particular application type.
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
should include identifiers of type "SRV-ID" (e.g., this is true should include identifiers of type SRV-ID (e.g., this is true of
of [XMPP]), then the certificate SHOULD include an SRV-ID. This the Extensible Messaging and Presence Protocol (XMPP) as
identifier type could supplement the DNS-ID, unless the described in [XMPP]), then the certificate SHOULD include an SRV-
ID. This identifier type could supplement the DNS-ID, unless the
certificate is meant to be scoped to only the protocol in certificate is meant to be scoped to only the protocol in
question. question.
4. If the service using the certificate deploys a technology for 4. If the service using the certificate deploys a technology for
which the relevant specification stipulates that certificates which the relevant specification stipulates that certificates
should include identifiers of type URI-ID (e.g., this is true of should include identifiers of type URI-ID (e.g., this is true of
[SIP] as specified by [SIP-CERTS]), then the certificate SHOULD the Session Initiation Protocol [SIP] as specified by
include a URI-ID. The scheme MUST be that of the protocol [SIP-CERTS]), then the certificate SHOULD include a URI-ID. The
associated with the application service type and the "host" scheme MUST be that of the protocol associated with the
component MUST be the FQDN of the service. The application application service type, and the "host" component MUST be the
protocol specification MUST specify which URI schemes are FQDN of the service. The application protocol specification MUST
acceptable in URI-IDs contained in PKIX certificates used for the specify which URI schemes are acceptable in URI-IDs contained in
application protocol (e.g., sip but not sips or tel for SIP as PKIX certificates used for the application protocol (e.g., sip
described in [SIP-SIPS]). Typically, this identifier type would but not sips or tel for SIP as described in [SIP-SIPS]).
supplement the DNS-ID, unless the certificate is meant to be Typically, this identifier type would supplement the DNS-ID,
scoped to only the protocol in question. unless the certificate is meant to be scoped to only the protocol
in question.
5. The certificate MAY contain more than one DNS-ID, SRV-ID, URI-ID, 5. The certificate MAY contain more than one DNS-ID, SRV-ID, URI-ID,
or IP-ID as further explained under Section 7.5. or IP-ID as further explained in Section 7.5.
6. The certificate MAY include other application-specific 6. The certificate MAY include other application-specific
identifiers for compatibility with a deployed base, especially identifiers for compatibility with a deployed base, especially
identifiers for types that were defined before publication of identifiers for types that were defined before publication of
[SRVNAME] or for which SRV service names or URI schemes do not [SRVNAME] or for which SRV service names or URI schemes do not
exist. Such identifiers are out of scope for this specification. exist. Such identifiers are out of scope for this specification.
4.2. Examples 4.2. Examples
Consider a simple website at www.bigcompany.example, which is not Consider a simple website at <www.bigcompany.example>, 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.bigcompany.example. might include only a DNS-ID of <www.bigcompany.example>.
Consider another website, which is reachable by a fixed IP address of Consider another website, which is reachable by a fixed IP address of
2001:db8::5c. If the two sites refer to the same web service, then 2001:db8::5c. If the two sites refer to the same web service, then
the certificate might also include this value in an IP-ID to allow the certificate might also include this value in an IP-ID to allow
clients to use the fixed IP address as a reference identity. clients to use the fixed IP address as a reference identity.
Consider an IMAP-accessible email server at the host mail.isp.example Consider an IMAP-accessible email server at the host mail.isp.example
servicing email addresses of the form user@isp.example and servicing email addresses of the form user@isp.example and
discoverable via DNS SRV lookups on the application service name of discoverable via DNS SRV lookups on the application service name of
isp.example. A certificate for this service might include SRV-IDs of isp.example. A certificate for this service might include SRV-IDs of
_imap.isp.example and _imaps.isp.example (see [EMAIL-SRV]) along with _imap.isp.example and _imaps.isp.example (see [EMAIL-SRV]) along with
DNS-IDs of isp.example and mail.isp.example. DNS-IDs of isp.example and mail.isp.example.
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.college.example servicing SIP addresses of the form voice.college.example servicing SIP addresses of the form
user@voice.college.example and identified by a URI of user@voice.college.example and identified by a URI of
<sip:voice.college.example>. A certificate for this service would <sip:voice.college.example>. A certificate for this service would
include a URI-ID of sip:voice.college.example (see [SIP-CERTS]) along include a URI-ID of <sip:voice.college.example> (see [SIP-CERTS])
with a DNS-ID of voice.college.example. along with a DNS-ID of voice.college.example.
Consider an XMPP-compatible instant messaging (IM) server at the host Consider an XMPP-compatible instant messaging (IM) server at the host
messenger.example servicing IM addresses of the form messenger.example that services IM addresses of the form
user@messenger.example and discoverable via DNS SRV lookups on the user@messenger.example and that is discoverable via DNS SRV lookups
messenger.example domain. A certificate for this service might on the messenger.example domain. A certificate for this service
include SRV-IDs of _xmpp-client.messenger.example and _xmpp- might include SRV-IDs of _xmpp-client.messenger.example and _xmpp-
server.messenger.example (see [XMPP]), as well as a DNS-ID of server.messenger.example (see [XMPP]), as well as a DNS-ID of
messenger.example. messenger.example.
5. Requesting Server Certificates 5. Requesting Server Certificates
This section provides instructions for service providers regarding This section provides instructions for service providers regarding
the information to include in certificate signing requests (CSRs). the information to include in certificate signing requests (CSRs).
In general, service providers SHOULD request certificates that In general, service providers SHOULD request certificates that
include all the identifier types that are required or recommended for include all the identifier types that are required or recommended for
the application service type that will be secured using the the application service type that will be secured using the
skipping to change at page 13, line 17 skipping to change at line 565
Section 7.5. Section 7.5.
If the certificate will be used for only a single type of application If the certificate will be used for only a single type of application
service, the service provider SHOULD request a certificate that service, the service provider SHOULD request a certificate that
includes DNS-ID or IP-ID values that identify that service or, if includes DNS-ID or IP-ID values that identify that service or, if
appropriate for the application service type, SRV-ID or URI-ID values appropriate for the application service type, SRV-ID or URI-ID values
that limit the deployment scope of the certificate to only the that limit the deployment scope of the certificate to only the
defined application service type. 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 SHOULD request a certificate that includes the service provider SHOULD request a certificate that includes only
only DNS-IDs or IP-IDs. Again, because of multiprotocol attacks this DNS-IDs or IP-IDs. Again, because of multiprotocol attacks, this
practice is discouraged; this can be mitigated by deploying only one practice is discouraged; it can be mitigated by deploying only one
service on a host. service on a host.
If a service provider offers multiple application service types and If a service provider offers multiple application service types and
wishes to limit the applicability of certificates using SRV-IDs or wishes to limit the applicability of certificates using SRV-IDs or
URI-IDs, they SHOULD request multiple certificates, rather than a URI-IDs, it SHOULD request that multiple certificates rather than a
single certificate containing multiple SRV-IDs or URI-IDs each single certificate containing multiple SRV-IDs or URI-IDs each
identifying a different application service type. This rule does not identify a different application service type. This rule does not
apply to application service type "bundles" that identify distinct apply to application service type "bundles" that identify distinct
access methods to the same underlying application such as an email access methods to the same underlying application such as an email
application with access methods denoted by the application service application with access methods denoted by the application service
types of imap, imaps, pop3, pop3s, and submission as described in types of imap, imaps, pop3, pop3s, and submission as described in
[EMAIL-SRV]. [EMAIL-SRV].
6. Verifying Service Identity 6. Verifying Service Identity
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 following actions: identity by performing the following actions:
1. The client constructs a list of reference identifiers it would 1. The client constructs a list of reference identifiers it would
find acceptable based on the source domain and, if applicable, find acceptable based on the source domain and, if applicable,
the type of service to which the client is connecting. the type of service to which the client is connecting.
2. The server provides its identifiers in the form of a PKIX 2. The server provides its presented identifiers in the form of a
certificate. PKIX 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. When server's presented identifiers for the purpose of finding a
checking a reference identifier against a presented identifier, match. 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 should Naturally, in addition to checking identifiers, a client should
perform further checks, such as expiration and revocation, to ensure perform further checks, such as expiration and revocation, to ensure
that the server is authorized to provide the requested service. that the server is authorized to provide the requested service.
Because such checking is not a matter of verifying the application Because such checking is not a matter of verifying the application
service identity presented in a certificate, methods for doing so are service identity presented in a certificate, methods for doing so are
out of scope for this document. out of scope for this document.
6.1. Constructing a List of Reference Identifiers 6.1. Constructing a List of Reference Identifiers
6.1.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. server.
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 host for retrieving email, which might be (e.g., the domain name of a host for retrieving email, 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.
This document does not precisely define how reference identifiers are This document does not precisely define how reference identifiers are
generated. Defining reference identifiers is the responsibility of generated. Defining reference identifiers is the responsibility of
applications or protocols that use this document. Because the applications or protocols that use this document. Because the
security of a system that uses this document will depend on how security of a system that uses this document will depend on how
reference identifiers are generated, great care should be taken in reference identifiers are generated, great care should be taken in
this process. For example, a protocol or application could specify this process. For example, a protocol or application could specify
that the application service type is obtained through a one-to-one that the application service type is obtained through a one-to-one
mapping of URI schemes to service types or support only a restricted mapping of URI schemes to service types or that the protocol or
set of URI schemes. Similarly, it could insist that a domain name or application supports only a restricted set of URI schemes.
IP address taken as input to the reference identifier must be Similarly, it could specify that a domain name or an IP address taken
obtained in a secure context such as a hyperlink embedded in a web as input to the reference identifier must be obtained in a secure
page that was delivered over an authenticated and encrypted channel context such as a hyperlink embedded in a web page that was delivered
(see for instance [SECURE-CONTEXTS] with regard to the web platform). over an authenticated and encrypted channel (for instance, see
[SECURE-CONTEXTS] with regard to the web platform).
Naturally, if the inputs themselves are invalid or corrupt (e.g., a Naturally, if the inputs themselves are invalid or corrupt (e.g., a
user has clicked a hyperlink provided by a malicious entity in a user has clicked a hyperlink provided by a malicious entity in a
phishing attack), then the client might end up communicating with an phishing attack), then the client might end up communicating with an
unexpected application service. unexpected application service.
During the course of processing, a client might be exposed to During the course of processing, a client might be exposed to
identifiers that look like, but are not, reference identifiers. For identifiers that look like, but are not, reference identifiers. For
example, DNS resolution that starts at a DNS-ID reference identifier example, DNS resolution that starts at a DNS-ID reference identifier
might produce intermediate domain names that need to be further might produce intermediate domain names that need to be further
resolved. Unless an application defines a process for authenticating resolved. Unless an application defines a process for authenticating
intermediate identifiers in a way that then allows them to be used as intermediate identifiers in a way that then allows them to be used as
a reference identifier (see for example [SMTP-TLS]), any intermediate a reference identifier (for example, see [SMTP-TLS]), any
values are not reference identifiers and MUST NOT be treated as such. intermediate values are not reference identifiers and MUST NOT be
In the DNS case, not treating intermediate domain names as reference treated as such. In the DNS case, not treating intermediate domain
identifiers removes DNS and DNS resolution from the attack surface. names as reference identifiers removes DNS and DNS resolution from
the attack surface.
As one example of the process of generating a reference identifier, As one example of the process of generating a reference identifier,
from user input of the URI <sip:alice@college.example> a client could from the user input of the URI <sip:alice@voice.college.example>, a
derive the application service type sip from the URI scheme and parse client could derive the application service type sip from the URI
the domain name college.example from the host component. scheme and parse the domain name college.example from the "host"
component.
Using the combination of FQDN(s) or IP address(es), plus optionally Using the combination of one or more FQDNs or IP addresses, plus
an application service type, the client MUST construct its list of optionally an application service type, the client MUST construct its
reference identifiers in accordance with the following rules: list of reference identifiers in accordance with the following rules:
* 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 reference identifier SHOULD be a URI-ID. certificates), the reference identifier SHOULD be a URI-ID.
* 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 reference discovered by means of DNS SRV records, the reference identifier
identifier SHOULD be an SRV-ID. SHOULD be an SRV-ID.
* If the reference identifier is an IP address, the reference * If the reference identifier is an IP address, the reference
identifier is an IP-ID. identifier is an IP-ID.
* In the absence of more specific identifiers, the reference * In the absence of more specific identifiers, the reference
identifier is a DNS-ID. A reference identifier of type DNS-ID can identifier is a DNS-ID. A reference identifier of type DNS-ID can
be directly constructed from a FQDN that is (a) contained in or be directly constructed from an FQDN that is (a) contained in or
securely derived from the inputs, or (b) explicitly associated securely derived from the inputs or (b) explicitly associated with
with the source domain by means of user configuration. the source domain by means of user configuration.
Which identifier types a client includes in its list of reference Which identifier types a client includes in its list of reference
identifiers, and their priority, is a matter of local policy. For identifiers, and their priority, is a matter of local policy. For
example, a client that is built to connect only to a particular kind example, a client that is built to connect only to a particular kind
of service might be configured to accept as valid only certificates of service might be configured to accept as valid only certificates
that include an SRV-ID for that application service type. By that include an SRV-ID for that application service type. By
contrast, a more lenient client, even if built to connect only to a contrast, a more lenient client, even if built to connect only to a
particular kind of service, might include SRV-IDs, DNS-IDs, and IP- particular kind of service, might include SRV-IDs, DNS-IDs, and IP-
IDs in its list of reference identifiers. IDs in its list of reference identifiers.
6.1.2. Examples 6.1.2. Examples
The following examples are for illustrative purposes only and are not The following examples are for illustrative purposes only and are not
intended to be comprehensive. intended to be comprehensive.
1. A web browser that is connecting via HTTPS to the website at 1. A web browser that is connecting via HTTPS to the website at
https://www.bigcompany.example/ would have a single reference <https://www.bigcompany.example/> would have a single reference
identifier: a DNS-ID of www.bigcompany.example. identifier: a DNS-ID of www.bigcompany.example.
2. A web browser connecting to https://192.0.2.107/ would have a 2. A web browser connecting to <https://192.0.2.107/> would have a
single IP-ID reference identifier of 192.0.2.107. Likewise, if single IP-ID reference identifier of 192.0.2.107. Likewise, if
connecting to https://[2001:db8::abcd] , it would have a single connecting to <https://[2001:db8::abcd]>, it would have a single
IP-ID reference identifier of 2001:db8::abcd. IP-ID reference identifier of 2001:db8::abcd.
3. A mail user agent that is connecting via IMAPS to the email 3. A mail user agent that is connecting via IMAPS to the email
service at isp.example (resolved as mail.isp.example) might have service at isp.example (resolved as mail.isp.example) might have
three reference identifiers: an SRV-ID of _imaps.isp.example (see three reference identifiers: an SRV-ID of _imaps.isp.example (see
[EMAIL-SRV]), and DNS-IDs of isp.example and mail.isp.example. [EMAIL-SRV]) and DNS-IDs of isp.example and mail.isp.example. An
An email user agent that does not support [EMAIL-SRV] would email user agent that does not support [EMAIL-SRV] would probably
probably be explicitly configured to connect to mail.isp.example, be explicitly configured to connect to mail.isp.example, whereas
whereas an SRV-aware user agent would derive isp.example from an an SRV-aware user agent would derive isp.example from an email
email address of the form user@isp.example but might also accept address of the form user@isp.example but might also accept
mail.isp.example as the DNS domain name portion of reference mail.isp.example as the DNS domain name portion of reference
identifiers for the service. identifiers for the service.
4. A voice-over-IP (VoIP) user agent that is connecting via SIP to 4. A VoIP user agent that is connecting via SIP to the voice service
the voice service at voice.college.example might have only one at voice.college.example might have only one reference
reference identifier: a URI-ID of sip:voice.college.example (see identifier: a URI-ID of sip:voice.college.example (see
[SIP-CERTS]). [SIP-CERTS]).
5. An instant messaging (IM) client that is connecting via XMPP to 5. An IM client that is connecting via XMPP to the IM service at
the IM service at messenger.example might have three reference messenger.example might have three reference identifiers: an SRV-
identifiers: an SRV-ID of _xmpp-client.messenger.example (see ID of _xmpp-client.messenger.example (see [XMPP]), a DNS-ID of
[XMPP]), a DNS-ID of messenger.example, and an XMPP-specific messenger.example, and an XMPP-specific XmppAddr of
XmppAddr of messenger.example (see [XMPP]). messenger.example (see [XMPP]).
In all these cases, presented identifiers that do not match the In all these cases, presented identifiers that do not match the
reference identifier(s) would be rejected; for instance: reference identifier(s) would be rejected; for instance:
* With regard to the first example a DNS-ID of * With regard to the first example, a DNS-ID of
"web.bigcompany.example" would be rejected because the DNS domain web.bigcompany.example would be rejected because the DNS domain
name portion does not match "www.bigcompany.example". name portion does not match www.bigcompany.example.
* With regard to the third example, a URI-ID of * With regard to the third example, a URI-ID of
"sip:www.college.example" would be rejected because the DNS domain <sip:www.college.example> would be rejected because the DNS domain
name portion does not match "voice.college.example" and a DNS-ID name portion does not match "voice.college.example", and a DNS-ID
of "voice.college.example" would be rejected because it lacks the of "voice.college.example" would be rejected because it lacks the
appropriate application service type portion (i.e., it does not appropriate application service type portion (i.e., it does not
specify a "sip:" URI). specify a "sip:" URI).
6.2. 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, the client checks has received the server's presented identifiers, the client checks
its reference identifiers against the presented identifiers for the its reference identifiers against the presented identifiers for the
purpose of finding a match. The search fails if the client exhausts purpose of finding a match. The search fails if the client exhausts
skipping to change at page 17, line 23 skipping to change at line 760
reference identifiers, at which point the client SHOULD stop the reference identifiers, at which point the client SHOULD stop the
search. 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 components. Each reference identifier produces either a domain into components. Each reference identifier produces either a domain
name or an IP address and optionally an application service type as name or an IP address and optionally an application service type as
follows: follows:
* A DNS-ID reference identifier MUST be used directly as the DNS * A DNS-ID reference identifier MUST be used directly as the DNS
domain name and there is no application service type. domain name, and there is no application service type.
* An IP-ID reference identifier MUST be exactly equal to the value * An IP-ID reference identifier MUST exactly match the value of an
of a iPAddress entry in subjectAltName, with no partial (e.g., iPAddress entry in subjectAltName, with no partial (e.g., network-
network-level) matching. There is no application service type. level) matching. There is no application service type.
* For an SRV-ID reference identifier, the DNS domain name portion is * For an SRV-ID reference identifier, the DNS domain name portion is
the Name and the application service type portion is the Service. the Name and the application service type portion is the Service.
For example, an SRV-ID of _imaps.isp.example has a DNS domain name For example, an SRV-ID of _imaps.isp.example has a DNS domain name
portion of isp.example and an application service type portion of portion of isp.example and an application service type portion of
imaps, which maps to the IMAP application protocol as explained in imaps, which maps to the IMAP application protocol 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 and the portion is the "reg-name" part of the "host" component and the
application service type portion is the scheme, as defined above. application service type portion is the scheme, as defined above.
Matching only the "reg-name" rule from [URI] limits the additional Matching only the "reg-name" rule from [URI] limits the additional
domain name validation (Section 6.3) to DNS domain names or non-IP domain name validation (Section 6.3) to DNS domain names or non-IP
hostnames. A URI that contains an IP address might be matched hostnames. A URI that contains an IP address might be matched
against an IP-ID in place of a URI-ID by some lenient clients. against an IP-ID in place of a URI-ID by some lenient clients.
This document does not describe how a URI that contains no "host" This document does not describe how a URI that contains no "host"
component can be matched. Note that extraction of the "reg-name" component can be matched. Note that extraction of the "reg-name"
might necessitate normalization of the URI (as explained in might necessitate normalization of the URI (as explained in
Section 6 of [URI]). For example, a URI-ID of Section 6 of [URI]). For example, a URI-ID of
sip:voice.college.example would be split into a DNS domain name <sip:voice.college.example> would be split into a DNS domain name
portion of voice.college.example and an application service type portion of voice.college.example and an application service type
of sip (associated with an application protocol of SIP as of sip (associated with an application protocol of SIP as
explained in [SIP-CERTS]). explained in [SIP-CERTS]).
If the reference identifier produces a domain name, the client MUST If the reference identifier produces a domain name, the client MUST
match the DNS name; see Section 6.3. If the reference identifier match the DNS name; see Section 6.3. If the reference identifier
produces an IP address, the client MUST match the IP address; see produces an IP address, the client MUST match the IP address; see
Section 6.4. If an application service type is present it MUST also Section 6.4. If an application service type is present, it MUST also
match the service type as well; see Section 6.5. match the service type; see Section 6.5.
6.3. Matching the DNS Domain Name Portion 6.3. Matching the DNS Domain Name Portion
This section describes how the client must determine if the presented This section describes how the client must determine if the presented
DNS name matches the reference DNS name. The rules differ depending DNS name matches the reference DNS name. The rules differ depending
on whether the domain to be checked is an internationalized domain on whether the domain to be checked is an internationalized domain
name, as defined in Section 2, or not. For clients that support name, as defined in Section 2, or not. For clients that support
presented identifiers containing the wildcard character "*", this presented identifiers containing the wildcard character "*", this
section also specifies a supplemental rule for such "wildcard section also specifies a supplemental rule for such "wildcard
certificates". This section uses the description of labels and certificates". This section uses the description of labels and
domain names in [DNS-CONCEPTS]. 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 not an
"traditional domain name" (i.e., a FQDN that conforms to "preferred internationalized domain name (i.e., an FQDN that conforms to
name syntax" as described in Section 3.5 of [DNS-CONCEPTS]), then "preferred name syntax" as described in Section 3.5 of
matching of the reference identifier against the presented identifier [DNS-CONCEPTS]), then the matching of the reference identifier
MUST be performed by comparing the set of domain name labels using a against the presented identifier MUST be performed by comparing the
case-insensitive ASCII comparison, as clarified by [DNS-CASE]. For set of domain name labels using a case-insensitive ASCII comparison,
example, WWW.BigCompany.Example would be lower-cased to as clarified by [DNS-CASE]. For example, WWW.BigCompany.Example
www.bigcompany.example for comparison purposes. Each label MUST would be lower-cased to www.bigcompany.example for comparison
match in order for the names to be considered to match, except as purposes. Each label MUST match in order for the names to be
supplemented by the rule about checking of wildcard labels in considered a match, except as supplemented by the rule about checking
presented identifiers given below. wildcard labels in presented identifiers given below.
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 the client MUST convert any internationalized domain name, then the client MUST convert any
U-labels [IDNA-DEFS] in the domain name to A-labels before checking U-labels [IDNA-DEFS] in the domain name to A-labels before checking
the domain name or comparing it with others. In accordance with the domain name or comparing it with others. In accordance with
[IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII. [IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII.
Each label MUST match in order for the domain names to be considered Each label MUST match in order for the domain names to be considered
to match, except as supplemented by the rule about checking of to match, except as supplemented by the rule about checking wildcard
wildcard labels in presented identifiers given below. labels in presented identifiers given below.
If the technology specification supports wildcards in presented If the technology specification supports wildcards in presented
identifiers, then the client MUST match the reference identifier identifiers, then the client MUST match the reference identifier
against a presented identifier whose DNS domain name portion contains against a presented identifier whose DNS domain name portion contains
the wildcard character "*" in a label provided these requirements are the wildcard character "*" in a label, provided these requirements
met: are met:
1. There is only one wildcard character. 1. There is only one wildcard character.
2. The wildcard character appears only as the complete content of 2. The wildcard character appears only as the complete content of
the left-most label. the left-most label.
If the requirements are not met, the presented identifier is invalid If the requirements are not met, the presented identifier is invalid
and MUST be ignored. 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 one label in a
in a reference identifier. This specification covers only wildcard reference identifier. This specification covers only wildcard
characters in presented identifiers, not wildcard characters in characters in presented identifiers, not wildcard characters in
reference identifiers or in DNS domain names more generally. reference identifiers or in DNS domain names more generally.
Therefore, the use of wildcard characters as described herein is not Therefore, the use of wildcard characters as described herein is not
to be confused with DNS wildcard matching, where the "*" label always to be confused with DNS wildcard matching, where the "*" label always
matches at least one whole label and sometimes more; see matches at least one whole label and sometimes more; see
[DNS-CONCEPTS], Section 4.3.3 and [DNS-WILDCARDS]. In particular, it [DNS-CONCEPTS], Section 4.3.3 and [DNS-WILDCARDS]. In particular, it
also deviates from [DNS-WILDCARDS], Section 2.1.3. also deviates from [DNS-WILDCARDS], Section 2.1.3.
For information regarding the security characteristics of wildcard For information regarding the security characteristics of wildcard
certificates, see Section 7.1. certificates, see Section 7.1.
6.4. Matching an IP Address Portion 6.4. Matching an IP Address Portion
An IP-ID matches based on an octet-for-octet comparison of the bytes Matching of an IP-ID is based on an octet-for-octet comparison of the
of the reference identity with the bytes contained in the iPAddress bytes of the reference identity with the bytes contained in the
subjectAltName. iPAddress subjectAltName.
For an IP address that appears in a URI-ID, the "host" component of For an IP address that appears in a URI-ID, the "host" component of
both the reference identity and the presented identifier must match. both the reference identity and the presented identifier must match.
These are parsed as either an "IPv6address" (following [RFC3986], These are parsed as either an "IPv6address" (following [URI],
Section 3.2.2) or an "IPv4address" (following [IPv4]). If the Section 3.2.2) or an "IPv4address" (following [IPv4]). If the
resulting octets are equal, the IP address matches. resulting octets are equal, the IP address matches.
This document does not specify how an SRV-ID reference identity can This document does not specify how an SRV-ID reference identity can
include an IP address, as [SRVNAME] only defines string names, not include an IP address, as [SRVNAME] only defines string names, not
octet identifiers such as an IP address. octet identifiers such as an IP address.
6.5. Matching the Application Service Type Portion 6.5. Matching the Application Service Type Portion
The rules for matching the application service type depend on whether The rules for matching the application service type depend on whether
the identifier is an SRV-ID or a URI-ID. the identifier is an SRV-ID or a URI-ID.
These identifiers provide an application service type portion to be These identifiers provide an application service type portion to be
checked, but that portion is combined only with the DNS domain name 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 portion of the SRV-ID or URI-ID itself. Consider the example of a
list of reference identifiers includes an SRV-ID of _xmpp- messaging client that has two reference identifiers: (1) an SRV-ID of
client.messenger.example and a DNS-ID of app.example, the client MUST _xmpp-client.messenger.example and (2) a DNS-ID of app.example. The
check both the combination of an application service type of xmpp- client MUST check (1) the combination of (a) an application service
client and a DNS domain name of messenger.example and, separately, a type of xmpp-client and (b) a DNS domain name of messenger.example as
DNS domain name of app.example. However, the client MUST NOT check well as (2) a DNS domain name of app.example. However, the client
the combination of an application service type of xmpp-client and a MUST NOT check the combination of an application service type of
DNS domain name of app.example because it does not have an SRV-ID of xmpp-client and a DNS domain name of app.example because it does not
_xmpp-client.app.example in its list of reference identifiers. have an SRV-ID of _xmpp-client.app.example in its list of reference
identifiers.
If the identifier is an SRV-ID, then the application service name 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, per [SRVNAME], the _ character is part of the [DNS-SRV]. Note that per [SRVNAME], the underscore "_" is part of
service name in DNS SRV records and in SRV-IDs. the service name in DNS SRV records and in SRV-IDs.
If the identifier is a URI-ID, then the scheme name portion MUST be 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 matched in a case-insensitive manner, in accordance with [URI]. Note
that the : character is a separator between the scheme name and the that the colon ":" is a separator between the scheme name and the
rest of the URI, and thus does not need to be included in any rest of the URI and thus does not need to be included in any
comparison. comparison.
6.6. Outcome 6.6. 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.
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, then the client MUST proceed as described the reference identifiers, then the client MUST proceed as follows.
as follows.
If the client is an automated application, then it SHOULD terminate If the client is an automated application, then it SHOULD terminate
the communication attempt with a bad certificate error and log the the communication attempt with a bad certificate error and log the
error appropriately. The application MAY provide a configuration error appropriately. The application MAY provide a configuration
setting to disable this behavior, but it MUST NOT disable this setting to disable this behavior, but it MUST NOT disable this
security control by default. security control by default.
If the client is one that is directly controlled by a human user, If the client is one that is directly controlled by a human user,
then it SHOULD inform the user of the identity mismatch and then it SHOULD inform the user of the identity mismatch and
automatically terminate the communication attempt with a bad automatically terminate the communication attempt with a bad
skipping to change at page 20, line 48 skipping to change at line 930
MAY give advanced users the option of proceeding with acceptance MAY give advanced users the option of proceeding with acceptance
despite the identity mismatch. Although this behavior can be despite the identity mismatch. Although this behavior can be
appropriate in certain specialized circumstances, it needs to be appropriate in certain specialized circumstances, it needs to be
handled with extreme caution, for example by first encouraging even handled with extreme caution, for example by first encouraging even
an advanced user to terminate the communication attempt and, if they an advanced user to terminate the communication attempt and, if they
choose to proceed anyway, by forcing the user to view the entire choose to proceed anyway, by forcing the user to view the entire
certification path before proceeding. certification path before proceeding.
The application MAY also present the user with the ability to accept The application MAY also present the user with the ability to accept
the presented certificate as valid for subsequent connections. Such the presented certificate as valid for subsequent connections. Such
ad-hoc "pinning" SHOULD NOT restrict future connections to just the ad hoc "pinning" SHOULD NOT restrict future connections to just the
pinned certificate. Local policy that statically enforces a given pinned certificate. Local policy that statically enforces a given
certificate for a given peer SHOULD be made available only as prior certificate for a given peer SHOULD be made available only as prior
configuration, rather than a just-in-time override for a failed configuration rather than a just-in-time override for a failed
connection. connection.
7. Security Considerations 7. Security Considerations
7.1. Wildcard Certificates 7.1. Wildcard Certificates
Wildcard certificates automatically vouch for any single-label host Wildcard certificates automatically vouch for any single-label
names within their domain, but not multiple levels of domains. This hostnames within their domain, but not multiple levels of domains.
can be convenient for administrators but also poses the risk of This 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. For example, see [Defeating-SSL]
(beginning at slide 91) and [HTTPSbytes] (slides 38-40). (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
As specified in Section 6.3, restricting the presented identifiers in As specified in Section 6.3, restricting the presented identifiers in
certificates to only one wildcard character (e.g., certificates to only one wildcard character (e.g.,
"*.bigcompany.example" but not "*.*.bigcompany.example") and "*.bigcompany.example" but not "*.*.bigcompany.example") and
restricting the use of wildcards to only the left-most domain label restricting the use of wildcards to only the left-most domain label
can help to mitigate certain aspects of the attack described in can help to mitigate certain aspects of the attack described in
[Defeating-SSL]. [Defeating-SSL].
That same attack also relies on the initial use of a cleartext HTTP That same attack also relies on the initial use of a cleartext HTTP
connection, which is hijacked by an active on-path attacker and connection, which is hijacked by an active on-path attacker and
subsequently upgraded to HTTPS. In order to mitigate such an attack, subsequently upgraded to HTTPS. In order to mitigate such an attack,
administrators and software developers are advised to follow the administrators and software developers are advised to follow the
strict TLS guidelines provided in [TLS-REC], Section 3.2. strict TLS guidelines provided in [TLS-REC], Section 3.2.
Because the attack described in [HTTPSbytes] relies on an underlying Because the attack described in [HTTPSbytes] relies on an underlying
cross-site scripting (XSS) attack, web browsers and applications are cross-site scripting (XSS) attack, web browsers and applications are
advised to follow best practices to prevent XSS attacks; see for advised to follow best practices to prevent XSS attacks; for example,
example [XSS] published by the Open Web Application Security Project see [XSS], which was published by the Open Web Application Security
(OWASP). Project (OWASP).
Protection against a wildcard that identifies a public suffix Protection against a wildcard that identifies a public suffix
[Public-Suffix], such as *.co.uk or *.com, is beyond the scope of [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of
this document. this document.
As noted in Section 3, application protocols can disallow the use of As noted in Section 3, application protocols can disallow the use of
wildcard certificates entirely as a more foolproof mitigation. wildcard certificates entirely as a more foolproof mitigation.
7.2. Uniform Resource Identifiers 7.2. Uniform Resource Identifiers
The URI-ID type is a subjectAltName entry of type The URI-ID type is a subjectAltName entry of type
uniformResourceIdentifier as defined in [PKIX]. For the purposes of uniformResourceIdentifier as defined in [PKIX]. For the purposes of
this specification, the URI-ID MUST include both a "scheme" and a this specification, the URI-ID MUST include both a "scheme" and a
"host" component that matches the "reg-name" rule; if the entry does "host" component that matches the "reg-name" rule; if the entry does
not include both, it is not a valid URI-ID and MUST be ignored. Any not include both, it is not a valid URI-ID and MUST be ignored. Any
other components are ignored, because only the "scheme" and "host" other components are ignored because only the "scheme" and "host"
components are used for certificate matching as specified under components are used for certificate matching as specified under
Section 6. Section 6.
The quoted component names in the previous paragraph represent the The quoted component names in the previous paragraph represent the
associated [ABNF] productions from the IETF standard for Uniform associated [ABNF] productions from the IETF Proposed Standard for
Resource Identifiers [URI]. Although the reader should be aware that Uniform Resource Identifiers [URI]. Although the reader should be
some applications (e.g., web browsers) might instead conform to the aware that some applications (e.g., web browsers) might instead
Uniform Resource Locator (URL) specification maintained by the WHATWG conform to the Uniform Resource Locator (URL) specification
[URL], it is not expected that differences between the URI and URL maintained by the WHATWG [URL], it is not expected that differences
specifications would manifest themselves in certificate matching. between the URI and URL specifications would manifest themselves in
certificate matching.
7.3. Internationalized Domain Names 7.3. Internationalized Domain Names
This document specifies only matching between reference identifiers This document specifies only matching between reference identifiers
and presented identifiers, not the visual presentation of domain and presented identifiers, not the visual presentation of domain
names. More specifically, matching of internationalized domain names names. Specifically, the matching of internationalized domain names
is performed on A-labels only Section 6. The limited scope of this is performed on A-labels only (Section 6.3). The limited scope of
specification likely mitigates potential confusion caused by the use this specification likely mitigates potential confusion caused by the
of visually similar characters in domain names (as described for use of visually similar characters in domain names (for example, as
example in [IDNA-DEFS], Section 4.4, [UTS-36], and [UTS-39]); in any described in Section 4.4 of [IDNA-DEFS], [UTS-36], and [UTS-39]); in
case, such concerns are a matter for application-level protocols and any case, such concerns are a matter for application-level protocols
user interfaces, not the matching of certificates. and user interfaces, not the matching of certificates.
7.4. IP Addresses 7.4. IP Addresses
The TLS Server Name Indication (SNI) extension only conveys domain The TLS Server Name Indication (SNI) extension only conveys domain
names. Therefore, a client with an IP-ID reference identity cannot names. Therefore, a client with an IP-ID reference identity cannot
present any information about its reference identity when connecting present any information about its reference identity when connecting
to a server. Servers that wish to present an IP-ID therefore need to to a server. Servers that wish to present an IP-ID therefore need to
present this identity when a connection is made without SNI. present this identity when a connection is made without SNI.
The textual representation of an IPv4 address might be misinterpreted The textual representation of an IPv4 address might be misinterpreted
as a valid FQDN in some contexts. This can result in different as a valid FQDN in some contexts. This can result in different
security treatment that might cause different components of a system security treatment that might cause different components of a system
to classify the value differently, which might lead to to classify the value differently, which might lead to
vulnerabilities. For example, one system component enforces a vulnerabilities. Consider a system in which one component enforces a
security rule that is conditional on the type of identifier. This security rule that is conditional on the type of identifier but
component misclassifies an IP address as an FQDN. A different misclassifies an IP address as an FQDN, whereas a second component
component correctly classifies the identifier but might incorrectly correctly classifies the identifier but incorrectly assumes that
assume that rules regarding IP addresses have been enforced. rules regarding IP addresses have been enforced by the first
Consistent classification of identifiers avoids this problem. component. As a result, the system as a whole might behave in an
insecure manner. Consistent classification of identifiers avoids
this problem.
See also Section 3, particularly the last paragraph. See also Section 3, particularly the last paragraph.
7.5. Multiple Presented Identifiers 7.5. 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. TLS Extensions such as TLS Server multiple domains or protocols. TLS extensions such as the Server
Name Indication (SNI), discussed in [TLS], Section 4.4.2.2, and Name Indication (SNI), as discussed in [TLS-EXT], Section 3, and
Application Layer Protocol Negotiation (ALPN), discussed in [ALPN], ALPN, as discussed in [ALPN], provide a way for the application to
provide a way for the application to indicate the desired identifier indicate the desired identifier and protocol to the server, which it
and protocol to the server, which it can then use to select the most can then use to select the most appropriate certificate.
appropriate certificate.
This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI- This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-
IDs in a certificate. As a result, an application service can use IDs in a certificate. As a result, an application service can use
the same certificate for multiple hostnames, such as when a client the same certificate for multiple hostnames, such as when a client
does not support the TLS SNI extension, or for multiple protocols, does not support the TLS SNI extension, or for multiple protocols,
such as SMTP and HTTP, on a single hostname. Note that the set of such as SMTP and HTTP, on a single hostname. Note that the set of
names in a certificate is the set of names that could be affected by names in a certificate is the set of names that could be affected by
a compromise of any other server named in the set: the strength of a compromise of any other server named in the set: the strength of
any server in the set of names is determined by the weakest of those any server in the set of names is determined by the weakest of those
servers that offer the names. servers that offer the names.
The way to mitigate this risk is to limit the number of names that The way to mitigate this risk is to limit the number of names that
any server can speak for, and to ensure that all servers in the set any server can speak for and to ensure that all servers in the set
have a strong minimum configuration as described in Section 3.9 of have a strong minimum configuration as described in [TLS-REC],
[TLS-REC]. Section 3.9.
7.6. Multiple Reference Identifiers 7.6. Multiple Reference Identifiers
This specification describes how a client may construct multiple This specification describes how a client may construct multiple
acceptable reference identifiers and may match any of those reference acceptable reference identifiers and may match any of those reference
identifiers with the set of presented identifiers. [PKIX], identifiers with the set of presented identifiers. [PKIX],
Section 4.2.1.10 describes a mechanism to allow CA certificates to be Section 4.2.1.10 describes a mechanism to allow CA certificates to be
constrained in the set of presented identifiers that they may include constrained in the set of presented identifiers that they may include
within server certificates. However, these constraints only apply to within server certificates. However, these constraints only apply to
the explicitly enumerated name forms. For example, a CA that is only the explicitly enumerated name forms. For example, a CA that is only
name constrained for DNS-IDs is not constrained for SRV-IDs and URI- name-constrained for DNS-IDs is not constrained for SRV-IDs and URI-
IDs, unless those name forms are also explicitly included within the IDs, unless those name forms are also explicitly included within the
name constraints extension. name constraints extension.
A client that constructs multiple reference identifiers of different A client that constructs multiple reference identifiers of different
types, such as both DNS-ID and SRV-IDs, as described in types, such as both DNS-IDs and SRV-IDs as described in
Section 6.1.1, SHOULD take care to ensure that CAs issuing such Section 6.1.1, SHOULD take care to ensure that CAs issuing such
certificates are appropriately constrained. This MAY take the form certificates are appropriately constrained. This MAY take the form
of local policy through agreement with the issuing CA, or MAY be of local policy through agreement with the issuing CA or MAY be
enforced by the client requiring that if one form of presented enforced by the client requiring that if one form of presented
identifier is constrained, such as a dNSName name constraint for DNS- identifier is constrained, such as a dNSName name constraint for DNS-
IDs, then all other forms of acceptable reference identities are also IDs, then all other forms of acceptable reference identities are also
constrained, such as requiring a uniformResourceIndicator name constrained, such as requiring a uniformResourceIndicator name
constraint for URI-IDs. constraint for URI-IDs.
7.7. Certificate Trust 7.7. Certificate Trust
This document assumes that, if a client trusts a given CA, it trusts This document assumes that if a client trusts a given CA, it trusts
all certificates issued by that CA. The certificate checking process all certificates issued by that CA. The certificate checking process
does not include additional checks for bad behavior by the hosts does not include additional checks for bad behavior by the hosts
identified with such certificates, for instance rogue servers or identified with such certificates, for instance, rogue servers or
buggy applications. Any additional checks (e.g., checking the server buggy applications. Any additional checks (e.g., checking the server
name against trusted block lists) are the responsibility of the name against trusted block lists) are the responsibility of the
application protocol or the client itself. application protocol or the client itself.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[DNS-CONCEPTS] [DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities", Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/rfc/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/rfc/rfc2782>. <https://www.rfc-editor.org/info/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://www.rfc-editor.org/rfc/rfc4592>. <https://www.rfc-editor.org/info/rfc4592>.
[IDNA-DEFS] [IDNA-DEFS]
Klensin, J., "Internationalized Domain Names for Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[IDNA-PROTO] [IDNA-PROTO]
Klensin, J., "Internationalized Domain Names in Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/rfc/rfc5891>. <https://www.rfc-editor.org/info/rfc5891>.
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, [IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/rfc/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing [IPv6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/rfc/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006, RFC 4514, DOI 10.17487/RFC4514, June 2006,
<https://www.rfc-editor.org/rfc/rfc4514>. <https://www.rfc-editor.org/info/rfc4514>.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, DOI 10.17487/RFC4985, August 2007, RFC 4985, DOI 10.17487/RFC4985, August 2007,
<https://www.rfc-editor.org/rfc/rfc4985>. <https://www.rfc-editor.org/info/rfc4985>.
[TLS-REC] Sheffer, Y., Saint-Andre, P., and T. Fossati, [TLS-REC] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/rfc/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
9.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://www.rfc-editor.org/rfc/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/rfc/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D.,
Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel,
"ALPACA: Application Layer Protocol Confusion - Analyzing "ALPACA: Application Layer Protocol Confusion - Analyzing
and Mitigating Cracks in TLS Authentication", September and Mitigating Cracks in TLS Authentication", 30th USENIX
2021, <https://alpaca-attack.com/ALPACA.pdf>. Security Symposium (USENIX Security 21), September 2021,
<https://alpaca-attack.com/ALPACA.pdf>.
[ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/rfc/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[DANE] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [DANE] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/rfc/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[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", Black Hat DC, February 2009,
<https://www.blackhat.com/presentations/bh-dc- <https://www.blackhat.com/presentations/bh-dc-
09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating- 09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-
SSL.pdf>. SSL.pdf>.
[DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343, Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006, DOI 10.17487/RFC4343, January 2006,
<https://www.rfc-editor.org/rfc/rfc4343>. <https://www.rfc-editor.org/info/rfc4343>.
[DNS-OVER-TLS] [DNS-OVER-TLS]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/rfc/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The [DTLS] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>. <https://www.rfc-editor.org/info/rfc9147>.
[EMAIL-SRV] [EMAIL-SRV]
Daboo, C., "Use of SRV Records for Locating Email Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/rfc/rfc6186>. <https://www.rfc-editor.org/info/rfc6186>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[HTTP-OVER-TLS]
Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/rfc/rfc2818>.
[HTTPSbytes] [HTTPSbytes]
Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Sokol, J. and R. Hansen, "HTTPS Can Byte Me", Black Hat
Dhabi, November 2010, <https://media.blackhat.com/bh-ad- Briefings, November 2010, <https://media.blackhat.com/bh-
10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-Me- ad-10/Hansen/Blackhat-AD-2010-Hansen-Sokol-HTTPS-Can-Byte-
slides.pdf>. Me-slides.pdf>.
[NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002, RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/rfc/rfc3403>. <https://www.rfc-editor.org/info/rfc3403>.
[NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. [NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/rfc/rfc8915>. <https://www.rfc-editor.org/info/rfc8915>.
[Public-Suffix] [Public-Suffix]
"Public Suffix List", 2020, <https://publicsuffix.org>. Mozilla Foundation, "Public Suffix List",
<https://publicsuffix.org>.
[QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[SECURE-CONTEXTS] [SECURE-CONTEXTS]
West, M., "Secure Contexts", 2021, West, M., "Secure Contexts", W3C Candidate Recommendation
Draft, September 2021,
<https://www.w3.org/TR/secure-contexts/>. <https://www.w3.org/TR/secure-contexts/>.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[SIP-CERTS] [SIP-CERTS]
Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, DOI 10.17487/RFC5922, June 2010, RFC 5922, DOI 10.17487/RFC5922, June 2010,
<https://www.rfc-editor.org/rfc/rfc5922>. <https://www.rfc-editor.org/info/rfc5922>.
[SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, Initiation Protocol (SIP)", RFC 5630,
DOI 10.17487/RFC5630, October 2009, DOI 10.17487/RFC5630, October 2009,
<https://www.rfc-editor.org/rfc/rfc5630>. <https://www.rfc-editor.org/info/rfc5630>.
[SMTP-TLS] Fenton, J., "SMTP Require TLS Option", RFC 8689, [SMTP-TLS] Fenton, J., "SMTP Require TLS Option", RFC 8689,
DOI 10.17487/RFC8689, November 2019, DOI 10.17487/RFC8689, November 2019,
<https://www.rfc-editor.org/rfc/rfc8689>. <https://www.rfc-editor.org/info/rfc8689>.
[SVCB-FOR-DNS] [SVCB-FOR-DNS]
Schwartz, B. M., "Service Binding Mapping for DNS Schwartz, B., "Service Binding Mapping for DNS Servers",
Servers", Work in Progress, Internet-Draft, draft-ietf- RFC 9461, DOI 10.17487/RFC9461, November 2023,
add-svcb-dns-09, 26 June 2023, <https://www.rfc-editor.org/info/rfc9461>.
<https://datatracker.ietf.org/doc/html/draft-ietf-add-
svcb-dns-09>.
[SVCB-FOR-HTTPS] [SVCB-FOR-HTTPS]
Schwartz, B. M., Bishop, M., and E. Nygren, "Service Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
binding and parameter specification via the DNS (DNS SVCB and Parameter Specification via the DNS (SVCB and HTTPS
and HTTPS RRs)", Work in Progress, Internet-Draft, draft- Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
ietf-dnsop-svcb-https-12, 11 March 2023, November 2023, <https://www.rfc-editor.org/info/rfc9460>.
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
svcb-https-12>.
[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://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[TLS-SUBCERTS] [TLS-SUBCERTS]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS and DTLS", RFC 9345, "Delegated Credentials for TLS and DTLS", RFC 9345,
DOI 10.17487/RFC9345, July 2023, DOI 10.17487/RFC9345, July 2023,
<https://www.rfc-editor.org/rfc/rfc9345>. <https://www.rfc-editor.org/info/rfc9345>.
[URL] van Kesteren, A., "URL", 2023, [URL] van Kesteren, A., "URL", WHATWG Living Standard, September
<https://url.spec.whatwg.org/>. 2023, <https://url.spec.whatwg.org/>.
[US-ASCII] American National Standards Institute, "Coded Character [US-ASCII] American National Standards Institute, "Coded Character
Set - 7-bit American Standard Code for Information Sets - 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange (7-Bit ASCII)", ANSI INCITS 4-1986 (R2007),
June 2007.
[UTS-36] Davis, M. and M. Suignard, "Unicode Security [UTS-36] Davis, M. and M. Suignard, "Unicode Security
Considerations", 2014, Considerations", Revision 15, Unicode Technical
Report #36, September 2014,
<https://unicode.org/reports/tr36/>. <https://unicode.org/reports/tr36/>.
[UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms", [UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms",
2022, <https://unicode.org/reports/tr39/>. Version 15.1.0, Revision 28, Unicode Technical
Standard #39, September 2023,
<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://www.rfc-editor.org/rfc/rfc6125>. 2011, <https://www.rfc-editor.org/info/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", August 2010, Interface Guidelines", W3C Recommendation REC-wsc-ui-
20100812, August 2010,
<https://www.w3.org/TR/2010/REC-wsc-ui-20100812/>. <https://www.w3.org/TR/2010/REC-wsc-ui-20100812/>.
[X.509] International Telecommunications Union, "Information [X.509] ITU-T, "Information Technology - Open Systems
Technology - Open Systems Interconnection - The Directory: Interconnection - The Directory: Public-key and attribute
Public-key and attribute certificate frameworks", certificate frameworks", ISO/IEC 9594-8, ITU-T
ITU-T X.520, 2005. Recommendation X.509, October 2019.
[X.690] International Telecommunications Union, "Information [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Technology - ASN.1 encoding rules: Specification of Basic Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (CER) and Distinguished Encoding Rules
Distinguished Encoding Rules (DER)", ITU-T X.690, 2008. (DER)", ISO/IEC 8825-1:2021 (E), ITU-T
Recommendation X.690, February 2021.
[XMPP] Saint-Andre, P., "Extensible Messaging and Presence [XMPP] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/rfc/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[XSS] OWASP, "Cross Site Scripting (XSS)", 2022, [XSS] Kirsten, S., et al., "Cross Site Scripting (XSS)", OWASP
Foundation, 2020,
<https://owasp.org/www-community/attacks/xss/>. <https://owasp.org/www-community/attacks/xss/>.
Appendix A. Changes from RFC 6125 Appendix A. Changes from 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 published. The major changes, in experience and changes since it was published. The major changes, in
no particular order, include: no particular order, include:
* The only legal place for a certificate wildcard is as the complete * The only legal place for a certificate wildcard is as the complete
left-most label in a domain name. left-most label in a domain name.
skipping to change at page 31, line 8 skipping to change at line 1385
* Detailed discussion of pinning (configuring use of a certificate * Detailed discussion of pinning (configuring use of a certificate
that doesn't match the criteria in this document) has been removed that doesn't match the criteria in this document) has been removed
and replaced with two paragraphs in Section 6.6. and replaced with two paragraphs in Section 6.6.
* The sections detailing different target audiences and which * The sections detailing different target audiences and which
sections to read (first) have been removed. sections to read (first) have been removed.
* 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.
* All references have been updated to the current latest version. * All references have been updated to the latest versions.
* The TLS SNI extension is no longer new, it is commonplace. * The TLS SNI extension is no longer new; it is commonplace.
* Additional text on multiple identifiers, and their security * Additional text on multiple identifiers, and their security
considerations, has been added. considerations, has been added.
* IP-ID reference identifiers are added. This builds on the * IP-ID reference identifiers have been added. This builds on the
definition in Section 4.3.5 of [HTTP]. definition in [HTTP], Section 4.3.5.
* Shortened the document title because the previous title was
difficult to cite.
Appendix B. Contributors
Jeff Hodges co-authored the previous version of these
recommendations, [VERIFY]. The authors gratefully acknowledge his
essential contributions to this work.
Martin Thomson contributed the text on handling of IP-IDs. * The document title has been shortened because the previous title
was difficult to cite.
Acknowledgements Acknowledgements
We gratefully acknowledge everyone who contributed to the previous We gratefully acknowledge everyone who contributed to the previous
version of these recommendations, [VERIFY]. Thanks also to Carsten version of this specification [VERIFY]. Thanks also to Carsten
Bormann for converting the previous document to Markdown so that we Bormann for converting the previous version of this specification to
could more easily use Martin Thomson's i-d-template software. Markdown so that we could more easily use Martin Thomson's
i-d-template software.
In addition to discussion on the mailing list, the following people In addition to discussions within the UTA Working Group, the
provided official reviews or especially significant feedback: Corey following people provided official reviews or especially significant
Bonnell, Roman Danyliw, Viktor Dukhovni, Lars Eggert, Patrik feedback: Corey Bonnell, Roman Danyliw, Viktor Dukhovni, Lars Eggert,
Fältström, Jim Fenton, Olle Johansson, John Klensin, Murray Patrik Fältström, Jim Fenton, Olle Johansson, John Klensin, Murray
Kucherawy, Warren Kumari, John Mattson, Alexey Melnikov, Derrell Kucherawy, Warren Kumari, John Mattson, Alexey Melnikov, Derrell
Piper, Ines Robles, Rob Sayre, Yaron Sheffer, Ryan Sleevi, Brian Piper, Maria Ines Robles, Rob Sayre, Yaron Sheffer, Ryan Sleevi,
Smith, Petr Špaček, Orie Steele, Martin Thomson, Joe Touch, Éric Brian Smith, Petr Špaček, Orie Steele, Martin Thomson, Joe Touch,
Vyncke, Paul Wouters, and Qin Wu. Éric Vyncke, Paul Wouters, and Qin Wu.
A few descriptive sentences were borrowed from [TLS-REC]. A few descriptive sentences were borrowed from [TLS-REC].
Contributors
Jeff Hodges coauthored the previous version of this specification
[VERIFY]. The authors gratefully acknowledge his essential
contributions to this work.
Martin Thomson contributed the text on the handling of IP-IDs.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
independent Independent
United States of America United States of America
Email: stpeter@stpeter.im Email: stpeter@stpeter.im
Rich Salz Rich Salz
Akamai Technologies Akamai Technologies
United States of America United States of America
Email: rsalz@akamai.com Email: rsalz@akamai.com
 End of changes. 171 change blocks. 
434 lines changed or deleted 431 lines changed or added

This html diff was produced by rfcdiff 1.48.