Update to Verifying TLS Server Identities with X.509 Certificates
Akamai Technologies
United States of America
rsalz@akamai.com
Security
UTA
certificate
TLS
PKIX
X.509
In the decade since was published, the subjectAlternativeName
extension (SAN), as defined in has become ubiquitous. This
document updates to specify that the fall-back techniques of
using the commonName attribute to identify the service must not be used.
This document also places some limitations on the use of wildcards in SAN
fields.
The original context of , using X.509 certificates for server
identity with Transport Layer Security (TLS), is not changed.
Discussion Venues
This draft is discussed in the UTA working group,
.
Source for this draft and an issue tracker can be found at
.
Introduction
In the decade since was published, the subjectAlternativeName
extension (SAN), as defined in has become ubiquitous. This
document updates to specify that the fall-back techniques of
using the commonName attribute to identify the service must not be used.
This document also places some limitations on the use of wildcards in SAN
fields.
The original context of , using X.509 certificates for server
identity with Transport Layer Security (TLS), is not changed.
In addition to the examples in that document,
the Baseline Requirements of the CA/Browser Forum, ,
might also be useful.
Conventions and Definitions
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
when, and only when, they appear in all capitals, as shown here.
The terminology from is used here.
Specifically, the following terms and brief definition (as a reminder):
- CN-ID: the Common Name element of a Distingiushed Name.
- DNS-ID: a domain name entry in a SAN extension.
The New Rules
The CN-ID MUST NOT be used. The appropriate value in the SAN
extension MUST be used to get the presented identity of the server.
While not discussed in this section also implicitly prohibits
the use of the Domain Component or emailAddress RDN's.
The following sections repeat the above rule in other forms, for the purpose
of updating .
Designing Application Protocols
Applications should determine which form of name they want to use, and
specify the appropriate SAN extension. Unless there are reasons
to do otherwise, applications SHOULD use the DNS-ID form.
Representing Server Identity
Servers MUST NOT request certificates that contain CN-ID in the subject. If
the Common Name RDN must be present in the certificate, it MUST be in a
form that cannot be mistaken for a CN-ID.
Verifying Service Identity
When constructing a list of reference identifiers, the client MUST NOT
include any CN-ID present in the certificate. This means that section
6.4.4 of MUST be ignored.
Constraints on Wildcards
Wildcard certificates are discussed in section 7.2 of , which
says that the specifications "are not clear or consistent" about where a
wildcard can appear.
This documents specifies that a wildcard can appear
- only as the left-most label; or
- as the last character in a left-most label
Security Considerations
The CN-ID, domainComponent, and emailAddress RDN fields are unstructured
free text, and using them is dependant on ordering and encoding concerns.
In addition, their evaluation when PKIX nameConstraints are present is
ambiguous. This document removes those fields from use, so a source
of possible errors is removed.
Because of the ambiguity around wildcards, mentions that it
is possible to have exploitable differences in behavior. By simplifying
those practices to one rule, this source of errors should be avoided.
All other security considerations of and its dependant
documents are still relevant.
IANA Considerations
This document has no IANA actions.
References
Normative References
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)
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 identity of application services in such interactions. [STANDARDS-TRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
CA/Browser Forum