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