Use the SAN field
Akamai Technologies
rsalz@akamai.com
Security
TBD Working Group
Internet-Draft
In the decade since was published, the subjectAltName
extension, as defined in has become ubiquitous. This document
updates to specify that the fall-back techniques of
using commonName attribute to identify the service MUST NOT be used.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
Introduction
In the decade since was published, the subjectAltName
extension, as defined in has become ubiquitous. This document
updates to specify that the fall-back techniques of
using commonName attribute to identify the service MUST NOT be used.
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 from a Distingiushed Name.
- DNS-ID, SRV-ID, URI-ID: different types of entries in a subjectAltName
extension.
The New Rules
The CN-ID MUST NOT be used. The appropriate value in the subjectAltName
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 subjectAltName extension. Unless there are reasons
to do otherwise, applications SHOULD use the DNS-ID form.
Representing Server Identity
Severs either MUST NOT issue a CN-ID, or MUST use a form for the Common Name
RDN that cannot be mistaken for an identifier. Not using Common Name is
preferred.
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.
Normative References
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.
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]
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.
Acknowledgments
TODO acknowledge.