--- 1/draft-ietf-uta-rfc6125bis-00.txt 2021-07-08 08:13:16.351331033 -0700 +++ 2/draft-ietf-uta-rfc6125bis-01.txt 2021-07-08 08:13:16.423332838 -0700 @@ -1,30 +1,30 @@ Network Working Group P. Saint-Andre Internet-Draft Mozilla Obsoletes: 6125 (if approved) J. Hodges Intended status: Standards Track Google -Expires: 31 December 2021 R. Salz +Expires: 9 January 2022 R. Salz Akamai Technologies - 29 June 2021 + 8 July 2021 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) - draft-ietf-uta-rfc6125bis-00 + draft-ietf-uta-rfc6125bis-01 Abstract Many application technologies enable secure communication between two - entities by means of Internet Public Key Infrastructure Using X.509 - (PKIX) certificates in the context of Transport Layer Security (TLS). - This document specifies procedures for representing and verifying the + entities by means of Transport Layer Security (TLS) with Internet + Public Key Infrastructure Using X.509 (PKIX) certificates. This + document specifies procedures for representing and verifying the identity of application services in such interactions. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Using TLS in Applications Working Group mailing list (uta@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/uta/. @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 31 December 2021. + This Internet-Draft will expire on 9 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -65,61 +65,59 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. How to Read This Document . . . . . . . . . . . . . . . . 4 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 6 1.6.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 6 - 1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 + 1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2. Naming of Application Services . . . . . . . . . . . . . . . 12 2.1. Naming Application Services . . . . . . . . . . . . . . . 12 - 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 14 - 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 15 - 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . 16 - 3. Designing Application Protocols . . . . . . . . . . . . . . . 17 - 4. Representing Server Identity . . . . . . . . . . . . . . . . 18 - 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5. Requesting Server Certificates . . . . . . . . . . . . . . . 20 - 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 21 - 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 - 6.2. Constructing a List of Reference Identifiers . . . . . . 22 - 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 - 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 24 - 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 - 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 26 - 6.4.1. Checking of Traditional Domain Names . . . . . . . . 27 - 6.4.2. Checking of Internationalized Domain Names . . . . . 27 - 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 - 6.4.4. Checking of Common Names . . . . . . . . . . . . . . 28 - 6.5. Matching the Application Service Type Portion . . . . . . 28 - 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 29 - 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 - 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 30 - 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 30 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 31 - 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31 - 7.3. Internationalized Domain Names . . . . . . . . . . . . . 32 - 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 32 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 - 8.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . 38 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13 + 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14 + 3. Designing Application Protocols . . . . . . . . . . . . . . . 15 + 4. Representing Server Identity . . . . . . . . . . . . . . . . 16 + 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Requesting Server Certificates . . . . . . . . . . . . . . . 18 + 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 19 + 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.2. Constructing a List of Reference Identifiers . . . . . . 19 + 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 22 + 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 22 + 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 24 + 6.4.1. Checking of Traditional Domain Names . . . . . . . . 24 + 6.4.2. Checking of Internationalized Domain Names . . . . . 24 + 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 24 + 6.5. Matching the Application Service Type Portion . . . . . . 25 + 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 25 + 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 26 + 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 26 + 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 26 + 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 27 + 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 27 + 7.3. Internationalized Domain Names . . . . . . . . . . . . . 28 + 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 28 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 8.2. Informative References . . . . . . . . . . . . . . . . . 29 + Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . 33 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction 1.1. Motivation The visible face of the Internet largely consists of services that employ a client-server architecture in which an interactive or automated client communicates with an application service in order to retrieve or upload information, communicate with other entities, or access a broader network of services. When a client communicates @@ -238,22 +235,22 @@ the subject's Common Name. * Check DNS domain names via the subjectAlternativeName extension designed for that purpose: dNSName. * Move toward including and checking even more specific subjectAlternativeName extensions where appropriate for using the protocol (e.g., uniformResourceIdentifier and the otherName form SRVName). - * Constrain and simplify the validation of so-called wildcard - certificates (e.g., a certificate containing an identifier for + * Constrain and simplify the validation of wildcard certificates + (e.g., a certificate containing an identifier for "*.example.com"). 1.6. Scope 1.6.1. In Scope This document applies only to service identities associated with fully qualified DNS domain names, only to TLS and DTLS (or the older Secure Sockets Layer (SSL) technology), and only to PKIX-based systems. As a result, the scenarios described in the following @@ -330,24 +327,21 @@ signed certificates has not been certified by a third party in any way, and checking of CA-issued certificates via CRLs or OCSP is critically important to maintaining the security of PKIX-based systems. Attempting to define best practices for such technologies would unduly complicate the rules defined in this specification. * Certification authority policies, such as: - What types or "classes" of certificates to issue and whether to - apply different policies for them (e.g., allow the wildcard - character in certificates issued to individuals who have - provided proof of identity but do not allow the wildcard - character in "Extended Validation" certificates [EV-CERTS]). + apply different policies for them. - Whether to issue certificates based on IP addresses (or some other form, such as relative domain names) in addition to fully qualified DNS domain names. - Which identifiers to include (e.g., whether to include SRV-IDs or URI-IDs as defined in the body of this specification). - How to certify or validate fully qualified DNS domain names and application service types. @@ -422,27 +416,20 @@ either presented by a server in a certificate or referenced by a client for matching purposes. identifier type: A formally defined category of identifier that can be included in a certificate and therefore that can also be used for matching purposes. For conciseness and convenience, we define the following identifier types of interest, which are based on those found in the PKIX specification [PKIX] and various PKIX extensions. - * CN-ID = a Relative Distinguished Name (RDN) in the certificate - subject field that contains one and only one attribute-type- - and-value pair of type Common Name (CN), where the value - matches the overall form of a domain name (informally, dot- - separated letter-digit-hyphen labels); see [PKIX] and also - [LDAP-SCHEMA] - * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] * SRV-ID = a subjectAltName entry of type otherName whose name form is SRVName; see [SRVNAME] * URI-ID = a subjectAltName entry of type uniformResourceIdentifier whose value includes both (i) a "scheme" and (ii) a "host" component (or its equivalent) that matches the "reg-name" rule (where the quoted terms represent the associated [ABNF] productions from [URI]); see [PKIX] and @@ -524,24 +511,24 @@ automated) application client; however, in application protocols that enable server-to-server communication, the TLS client could be a peer application service. TLS server: An entity that assumes the role of a server in a Transport Layer Security [TLS] negotiation; in this specification we assume that the TLS server is an application service. Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not - limited to, "attack," "authentication," "authorization," - "certification authority," "certification path," "certificate," - "credential," "identity," "self-signed certificate," "trust," "trust - anchor," "trust chain," "validate," and "verify". + limited to, "attack", "authentication", "authorization", + "certification authority", "certification path", "certificate", + "credential", "identity", "self-signed certificate", "trust", "trust + anchor", "trust chain", "validate", and "verify". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Naming of Application Services This section discusses naming of application services on the @@ -567,36 +554,32 @@ unrestricted because they can be used in any type of service (e.g., a certificate might be reused for both the HTTP service and the IMAP 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 certificate that can be used only for an IMAP service). This dimension matters most for certificate issuance. Therefore, we can categorize the identifier types of interest as follows: - * A CN-ID is direct and unrestricted. - * A DNS-ID is direct and unrestricted. * An SRV-ID can be either direct or (more typically) indirect, and is restricted. * A URI-ID is direct and restricted. We summarize this taxonomy in the following table. +-----------+-----------+---------------+ | | Direct | Restricted | +-----------+-----------+---------------+ - | CN-ID | Yes | No | - +-----------+-----------+---------------+ | DNS-ID | Yes | No | +-----------+-----------+---------------+ | SRV-ID | Either | Yes | +-----------+-----------+---------------+ | URI-ID | Yes | Yes | +-----------+-----------+---------------+ When implementing software, deploying services, and issuing certificates for secure PKIX-based authentication, it is important to keep these distinctions in mind. In particular, best practices @@ -619,30 +602,30 @@ supporting that technology (one such community, the CA/Browser Forum, has codified such a baseline for "Extended Validation Certificates" in [EV-CERTS]). 2.2. DNS Domain Names For the purposes of this specification, the name of an application service is (or is based on) a DNS domain name that conforms to one of the following forms: - 1. A "traditional domain name," i.e., a fully qualified DNS domain + 1. A "traditional domain name", i.e., a fully qualified DNS domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as described in [IDNA-DEFS]. Informally, such labels are constrained to [US-ASCII] letters, digits, and the hyphen, with the hyphen prohibited in the first character position. Additional qualifications apply (please refer to the above- referenced specifications for details), but they are not relevant to this specification. - 2. An "internationalized domain name," i.e., a DNS domain name that + 2. An "internationalized domain name", i.e., a DNS domain name that conforms to the overall form of a domain name (informally, dot- separated letter-digit-hyphen labels) but includes at least one label containing appropriately encoded Unicode code points outside the traditional US-ASCII range. That is, it contains at least one U-label or A-label, but otherwise may contain any mixture of NR-LDH labels, A-labels, or U-labels, as described in [IDNA-DEFS] and the associated documents. 2.3. Subject Naming in PKIX Certificates @@ -675,108 +658,39 @@ 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 - or names carried in the subject field (i.e., a CN-ID) and/or in one - of the following identifier types within subjectAltName entries: + or names carried in one or more of the following identifier types + within subjectAltName entries: * DNS-ID * SRV-ID * URI-ID - Existing certificates often use a CN-ID in the subject field to - represent a fully qualified DNS domain name; for example, consider - the following three subject names, where the attribute of type Common - Name contains a string whose form matches that of a fully qualified - DNS domain name ("im.example.org", "mail.example.net", and - "www.example.com", respectively): - CN=im.example.org,O=Example Org,C=GB - - C=CA,O=Example Internetworking,CN=mail.example.net - - O=Examples-R-Us,CN=www.example.com,C=US - - However, the Common Name is not strongly typed because a Common Name - might contain a human-friendly string for the service, rather than a - string whose form matches that of a fully qualified DNS domain name - (a certificate with such a single Common Name will typically have at - least one subjectAltName entry containing the fully qualified DNS - domain name): - - CN=A Free Chat Service,O=Example Org,C=GB - - Or, a certificate's subject might contain both a CN-ID as well as - another common name attribute containing a human-friendly string: - - CN=A Free Chat Service,CN=im.example.org,O=Example Org,C=GB - - In general, this specification recommends and prefers use of - subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the - subject field (CN-ID) where possible, as more completely described in - the following sections. However, specifications that reuse this one - can legitimately encourage continued support for the CN-ID identifier - type if they have good reasons to do so, such as backward - compatibility with deployed infrastructure (see, for example, - [EV-CERTS]). - -2.3.1. Implementation Notes - - Confusion sometimes arises from different renderings or encodings of - the hierarchical information contained in a certificate. - - Certificates are binary objects and are encoded using the - Distinguished Encoding Rules (DER) specified in [X.690]. However, - some implementations generate displayable (a.k.a. printable) - renderings of the certificate issuer, subject field, and - subjectAltName extension, and these renderings convert the DER- - encoded sequences into a "string representation" before being - displayed. Because a certificate subject field (of type Name + The Common Name RDN should not be used to identify a service. + Reasons for this include: - [X.509], the same as for a Distinguished Name (DN) [X.501]) is an - ordered sequence, order is typically preserved in subject string - representations, although the two most prevalent subject (and DN) - string representations differ in employing left-to-right vs. right- - to-left ordering. However, because a Relative Distinguished Name - (RDN) is an unordered group of attribute-type-and-value pairs, the - string representation of an RDN can differ from the canonical DER - encoding (and the order of attribute-type-and-value pairs can differ - in the RDN string representations or display orders provided by - various implementations). Furthermore, various specifications refer - to the order of RDNs in DNs or certificate subject fields using - terminology that is implicitly related to an information hierarchy - (which may or may not actually exist), such as "most specific" vs. - "least specific," "left-most" vs. "right-most," "first" vs. "last," - or "most significant" vs. "least significant" (see, for example, - [LDAP-DN]). + * It is not strongly typed and therefore suffers from ambiguities in + interpretation. - To reduce confusion, in this specification we avoid such terms and - instead use the terms provided under Section 1.7; in particular, we - do not use the term "(most specific) Common Name field in the subject - field" from [HTTP-TLS] and instead state that a CN-ID is a Relative - Distinguished Name (RDN) in the certificate subject containing one - and only one attribute-type-and-value pair of type Common Name (thus - removing the possibility that an RDN might contain multiple AVAs - (Attribute Value Assertions) of type CN, one of which could be - considered "most specific"). + * It can appear more than once in the Subject Name. - Finally, although theoretically some consider the order of RDNs - within a subject field to have meaning, in practice that rule is - often not observed. An AVA of type CN is considered to be valid at - any position within the subject field. + Likewise, other RDN's within the Subject Name SHOULD NOT be used to + identify a service. 3. Designing Application Protocols This section provides guidelines for designers of application protocols, in the form of a checklist to follow when reusing the recommendations provided in this document. * Does your technology use DNS SRV records to resolve the DNS domain names of application services? If so, consider recommending or requiring support for the SRV-ID identifier type in PKIX @@ -786,25 +700,20 @@ rely on representations of those records in PKIX certificates by means of SRV-IDs as defined in [SRVNAME].) * Does your technology use URIs to identify application services? If so, consider recommending or requiring support for the URI-ID identifier type. (Note that many existing application technologies use URIs to identify application services, but do not rely on representation of those URIs in PKIX certificates by means of URI-IDs.) - * Does your technology need to use DNS domain names in the Common - Name of certificates for the sake of backward compatibility? If - so, consider recommending support for the CN-ID identifier type as - a fallback. - * 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. 4. Representing Server Identity @@ -845,81 +754,62 @@ or perhaps http and https for HTTP as might be described in a future specification). 4. The certificate MAY include other application-specific identifiers for types that were defined before publication of [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names or URI schemes do not exist; however, such application-specific identifiers are not applicable to all application technologies and therefore are out of scope for this specification. - 5. Even though many deployed clients still check for the CN-ID - within the certificate subject field, certification authorities - are encouraged to migrate away from issuing certificates that - represent the server's fully qualified DNS domain name in a CN- - ID. Therefore, the certificate SHOULD NOT include a CN-ID unless - the certification authority issues the certificate in accordance - with a specification that reuses this one and that explicitly - encourages continued support for the CN-ID identifier type in the - context of a given application technology. - - 6. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- - ID but SHOULD NOT contain more than one CN-ID, as further - explained under Section 7.4. + 5. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- + ID as further explained under Section 7.4. - 7. Unless a specification that reuses this one allows continued + 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 Consider a simple website at "www.example.com", which is not discoverable via DNS SRV lookups. Because HTTP does not specify the use of URIs in server certificates, a certificate for this service - might include only a DNS-ID of "www.example.com". It might also - include a CN-ID of "www.example.com" for backward compatibility with - deployed infrastructure. + might include only a DNS-ID of "www.example.com". Consider an IMAP-accessible email server at the host "mail.example.net" servicing email addresses of the form "user@example.net" and discoverable via DNS SRV lookups on the application service name of "example.net". A certificate for this service might include SRV-IDs of "_imap.example.net" and "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of - "example.net" and "mail.example.net". It might also include CN-IDs - of "example.net" and "mail.example.net" for backward compatibility - with deployed infrastructure. + "example.net" and "mail.example.net". Consider a SIP-accessible voice-over-IP (VoIP) server at the host "voice.example.edu" servicing SIP addresses of the form "user@voice.example.edu" and identified by a URI of . A certificate for this service would include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along - with a DNS-ID of "voice.example.edu". It might also include a CN-ID - of "voice.example.edu" for backward compatibility with deployed - infrastructure. + with a DNS-ID of "voice.example.edu". Consider an XMPP-compatible instant messaging (IM) server at the host "im.example.org" servicing IM addresses of the form "user@im.example.org" and discoverable via DNS SRV lookups on the "im.example.org" domain. A certificate for this service might include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", - and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). It - might also include a CN-ID of "im.example.org" for backward - compatibility with deployed infrastructure. + and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). 5. Requesting Server Certificates This section provides rules and guidelines for service providers regarding the information to include in certificate signing requests (CSRs). In general, service providers are encouraged to request certificates that include all of the identifier types that are required or recommended for the application service type that will be secured @@ -1055,65 +945,49 @@ * If a server for the application service type is typically discovered by means of DNS SRV records, then the list SHOULD include an SRV-ID. * If a server for the application service type is typically associated with a URI for security purposes (i.e., a formal protocol document specifies the use of URIs in server certificates), then the list SHOULD include a URI-ID. - * The list MAY include a CN-ID, mainly for the sake of backward - compatibility with deployed infrastructure. - Which identifier types a client includes in its list of reference identifiers is a matter of local policy. For example, in certain - deployment environments, a client that is built to connect only to - a particular kind of service (e.g., only IM services) might be - configured to accept as valid only certificates that include an - SRV-ID for that application service type; in this case, the client - would include only SRV-IDs matching the application service type - in its list of reference identifiers (not, for example, DNS-IDs). - By contrast, a more lenient client (even one built to connect only - to a particular kind of service) might include both SRV-IDs and - DNS-IDs in its list of reference identifiers. - - Implementation Note: It is highly likely that implementers of - client software will need to support CN-IDs for the foreseeable - future, because certificates containing CN-IDs are so widely - deployed. Implementers are advised to monitor the state of the - art with regard to certificate issuance policies and migrate away - from support CN-IDs in the future if possible. + deployment environments, a client that is built to connect only to a + particular kind of service (e.g., only IM services) might be + configured to accept as valid only certificates that include an SRV- + ID for that application service type; in this case, the client would + include only SRV-IDs matching the application service type in its + list of reference identifiers (not, for example, DNS-IDs). By + contrast, a more lenient client (even one built to connect only to a + particular kind of service) might include both SRV-IDs and DNS-IDs in + its list of reference identifiers. 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. - Security Warning: A client MUST NOT construct a reference - identifier corresponding to Relative Distinguished Names (RDNs) - other than those of type Common Name and MUST NOT check for RDNs - other than those of type Common Name in the presented identifiers. - 6.2.2. Examples A web browser that is connecting via HTTPS to the website at - "www.example.com" might have two reference identifiers: a DNS-ID of - "www.example.com" and, as a fallback, a CN-ID of "www.example.com". + "www.example.com" would have a single reference identifier: a DNS-ID + of "www.example.com". A mail user agent that is connecting via IMAPS to the email service - at "example.net" (resolved as "mail.example.net") might have five + at "example.net" (resolved as "mail.example.net") might have three reference identifiers: an SRV-ID of "_imaps.example.net" (see - [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, - as a fallback, CN-IDs of "example.net" and "mail.example.net". (A - legacy email user agent would not support [EMAIL-SRV] and therefore - would probably be explicitly configured to connect to + [EMAIL-SRV]), and DNS-IDs of "example.net" and "mail.example.net". + (A legacy email user agent would not support [EMAIL-SRV] and + therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user@example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.) A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice service at "voice.example.edu" might have only one reference identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). An instant messaging (IM) client that is connecting via XMPP to the @@ -1132,44 +1006,31 @@ without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point 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. - Security Warning: A client MUST NOT seek a match for a reference - identifier of CN-ID if the presented identifiers include a DNS-ID, - SRV-ID, URI-ID, or any application-specific identifier types - supported by the client. - Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application service type portion, as follows: * A reference identifier of type DNS-ID does not include an application service type portion and thus can be used directly as the DNS domain name for comparison purposes. As an example, a DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com". - * A reference identifier of type CN-ID also does not include an - application service type portion and thus can be used directly as - the DNS domain name for comparison purposes. As previously - mentioned, this document specifies that a CN-ID always contains a - string whose form matches that of a DNS domain name (thus - differentiating a CN-ID from a Common Name containing a human- - friendly name). - * For a reference identifier of type SRV-ID, the DNS domain name portion is the Name and the application service type portion is the Service. As an example, an SRV-ID of "_imaps.example.net" would be split into a DNS domain name portion of "example.net" and an application service type portion of "imaps" (mapping to an application protocol of IMAP as explained in [EMAIL-SRV]). * For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "host" component (or its equivalent) and the application service type portion is the @@ -1196,27 +1057,26 @@ 6.4. Matching the DNS Domain Name Portion The client MUST match the DNS domain name portion of a reference identifier according to the following rules (and SHOULD also check the application service type as described under Section 6.5). The rules differ depending on whether the domain to be checked is a "traditional domain name" or an "internationalized domain name" (as defined under Section 2.2). Furthermore, to meet the needs of clients that support presented identifiers containing the wildcard character "*", we define a supplemental rule for so-called "wildcard - certificates". Finally, we also specify the circumstances under - which it is acceptable to check the CN-ID identifier type. + certificates". 6.4.1. Checking of Traditional Domain Names 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 domain name labels using a case-insensitive ASCII comparison, as clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to "www.example.com" for comparison purposes). Each label MUST match in order for the names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3). 6.4.2. Checking of Internationalized Domain Names @@ -1229,61 +1089,38 @@ supplemented by the rule about checking of wildcard labels (Section 6.4.3; but see also Section 7.2 regarding wildcards in internationalized domain names). 6.4.3. Checking of Wildcard Certificates A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character "*" as part or all of a label (following the description of labels and domain names in - [DNS-CONCEPTS]). + [DNS-CONCEPTS]), provided the requirements listed below are met. For information regarding the security characteristics of wildcard certificates, see Section 7.2. - If a client matches the reference identifier against a presented - identifier whose DNS domain name portion contains the wildcard - character "*", the following rules apply: - - 1. The client MUST NOT attempt to match a presented identifier in - which the wildcard character appears in other than the left-most - label (e.g., do not match "bar.*.example.net"). - - 2. The client MUST NOT attempt to match a presented identifier if - there are other characters before the wildcard character. - - 3. The client MUST NOT attempt to match a wildcard character against - more than one label (e.g., "*.example.net" does not match - 1api.foo.example.net`) + A client MUST NOT use the wildcard identifier if the reference + identifier does not follow the following rules: - 4. The client MUST NOT treat the label as having a wildcard if it is - embedded with an A-label or U-label [IDNA-DEFS] of an - internationalized domain name [IDNA-PROTO]. + 1. There is more than one wildcard character. -6.4.4. Checking of Common Names + 2. The wildcard appears other than in the left-most label (e.g., do + not match "bar.*.example.net"). - As noted, a client MUST NOT seek a match for a reference identifier - of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI- - ID, or any application-specific identifier types supported by the - client. + 3. The wildcard is not the first character (e.g., do not match + "w*.example.com") - Therefore, if and only if the presented identifiers do not include a - DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types - supported by the client, then the client MAY as a last resort check - for a string whose form matches that of a fully qualified DNS domain - name in a Common Name field of the subject field (i.e., a CN-ID). If - the client chooses to compare a reference identifier of type CN-ID - against that string, it MUST follow the comparison rules for the DNS - domain name portion of an identifier of type DNS-ID, SRV-ID, or URI- - ID, as described under Section 6.4.1, Section 6.4.2, and - Section 6.4.3. + 4. The wildcard character is embedded in an A-label or U-label + [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. 6.5. Matching the Application Service Type Portion 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 the application service type portion. The client does this by splitting the identifier into the DNS domain name portion and the application service type portion (as described under Section 6.3), then checking both the DNS domain name portion (as described under Section 6.4) and the application service type portion as described in @@ -1390,76 +1228,33 @@ MUST take account of both the certificate presented and the context in which it was accepted or configured (where the "context" includes the chain of certificates from the presented certificate to the trust anchor, the source domain, the application service type, the service's derived domain and port number, and any other relevant information provided by the user or associated by the client). 7.2. Wildcard Certificates This document states that the wildcard character "*" SHOULD NOT be - included in presented identifiers but MAY be checked by application - clients (mainly for the sake of backward compatibility with deployed - infrastructure). As a result, the rules provided in this document - are more restrictive than the rules for many existing application - technologies. Several security considerations justify tightening the - rules: - - * Wildcard certificates automatically vouch for any and all host - names 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). - - * Specifications for existing application technologies are not clear - or consistent about the allowable location of the wildcard - character, such as whether it can be: - - - only the complete left-most label (e.g., "*.example.com") - - - some fragment of the left-most label (e.g., "fo*.example.com", - "f*o.example.com", or "*oo.example.com") - - - all or part of a label other than the left-most label (e.g., - "www.*.example.com" or "www.foo*.example.com") - - - all or part of a label that identifies a so-called "public - suffix" (e.g., "*.co.uk" or "*.com") - - - included more than once in a given label (e.g., - "f*b*r.example.com" - - - included as all or part of more than one label (e.g., - "*.*.example.com") - - These ambiguities might introduce exploitable differences in - identity checking behavior among client implementations and - necessitate overly complex and inefficient identity checking - algorithms. + included in presented identifiers but SHOULD be checked by + application clients if the requirements specified in Section 6.4.3 + are met. - * There is no specification that defines how the wildcard character - may be embedded within the A-labels or U-labels [IDNA-DEFS] of an - internationalized domain name [IDNA-PROTO]; as a result, - implementations are strongly discouraged from including or - attempting to check for the wildcard character embedded within the - A-labels or U-labels of an internationalized domain name (e.g., - "xn--kcry6tjko*.example.org"). Note, however, that a presented - domain name identifier MAY contain the wildcard character as long - as that character occupies the entire left-most label position, - where all of the remaining labels are valid NR-LDH labels, - A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). + Wildcard certificates automatically vouch for any and all host names + 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). - Notwithstanding the foregoing security considerations, specifications - that reuse this one can legitimately encourage continued support for - the wildcard character if they have good reasons to do so, such as - backward compatibility with deployed infrastructure (see, for - example, [EV-CERTS]). + Protection against a wildcard that identifies a so-called "public + suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this + document. 7.3. Internationalized Domain Names Allowing internationalized domain names can lead to the inclusion of visually similar (so-called "confusable") characters in certificates; for discussion, see for example [IDNA-DEFS]. 7.4. Multiple Identifiers A given application service might be addressed by multiple DNS domain @@ -1474,263 +1269,234 @@ 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 of the SNI extension, this specification allows multiple DNS-IDs, - SRV-IDs, or URI-IDs in a certificate; however, it explicitly - discourages multiple CN-IDs. Although it would be preferable to - forbid multiple CN-IDs entirely, there are several reasons at this - time why this specification states that they SHOULD NOT (instead of - MUST NOT) be included: - - * At least one significant technology community of interest - explicitly allows multiple CN-IDs [EV-CERTS]. - - * At least one significant certification authority is known to issue - certificates containing multiple CN-IDs. - - * Many service providers often deem inclusion of multiple CN-IDs - necessary in virtual hosting environments because at least one - widely deployed operating system does not yet support the SNI - extension. - - It is hoped that the recommendation regarding multiple CN-IDs can be - further tightened in the future. + SRV-IDs, or URI-IDs in a certificate. 8. References 8.1. Normative References [DNS-CONCEPTS] - Mockapetris, P.V., "Domain names - concepts and - facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, - November 1987, . + Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, - . + . [IDNA-DEFS] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, - . + . [IDNA-PROTO] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, - . + . [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, DOI 10.17487/RFC4514, June 2006, - . + . [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, - . + . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . + May 2017, . [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, - . + . [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, - . + . 8.2. Informative References [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, - . + . [Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in Practice", BlackHat DC, February 2009, . [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, - . + . [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, - . + . [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, - . + . [EMAIL-SRV] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, - . + . [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And Management Of Extended Validation Certificates", October 2009, . [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, - . + . [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, - . + . [HTTPSbytes] Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu Dhabi, November 2010, . [IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, - December 2005, . - - [LDAP-SCHEMA] - Sciberras, A., Ed., "Lightweight Directory Access Protocol - (LDAP): Schema for User Applications", RFC 4519, - DOI 10.17487/RFC4519, June 2006, - . + December 2005, . [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, - . + . [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, DOI 10.17487/RFC2560, June 1999, - . + . [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, - . + . [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, . + February 1996, . [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, - January 2005, . + January 2005, . [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, - . + . [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, - . + . [SIP-CERTS] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, DOI 10.17487/RFC5922, June 2010, - . + . [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, - . + . [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, - . + . [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, - . + . [US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March - 2011, . + 2011, . [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User Interface Guidelines", World Wide Web Consortium LastCall WD-wsc-ui-20100309, March 2010, . [X.500] International Telecommunications Union, "Information Technology - Open Systems Interconnection - The Directory: - Overview of concepts, models and services", ISO Standard - 9594-1, ITU-T Recommendation X.500, August 2005. + 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", ISO Standard 9594-2, ITU-T Recommendation X.501, + 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", - ISO Standard 9594-8, ITU-T Recommendation X.509, August + 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", ISO Standard 9594-6, - ITU-T Recommendation X.509, August 2005. - - [X.690] International Telecommunications Union, "Information - Technology - ASN.1 encoding rules: Specification of Basic - Encoding Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER)", ISO Standard 8825-1, - ITU-T Recommendation X.690, August 2008. + Selected attribute types", ITU-T Recommendation X.509, + ISO Standard 9594-6, August 2005. [XMPP] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, - March 2011, . + March 2011, . 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.