2. Naming of Application Services

This section discusses naming of application services on the Internet, followed by a brief tutorial about subject naming in PKIX.

2.1. Naming Application Services

This specification assumes that the name of an application service is based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application service type (e.g., "the IMAP server at example.com").

From the perspective of the application client or user, some names are direct because they are provided directly by a human user (e.g., via runtime input, prior configuration, or explicit acceptance of a client communication attempt), whereas other names are indirect because they are automatically resolved by the client based on user input (e.g., a target name resolved from a source name using DNS SRV or NAPTR records). This dimension matters most for certificate consumption, specifically verification as discussed in this document.

From the perspective of the application service, some names are 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 differ somewhat for application server implementations, application client implementations, application service providers, and certification authorities. Ideally, protocol specifications that reference this document will specify which identifiers are mandatory-to-implement by servers and clients, which identifiers ought to be supported by certificate issuers, and which identifiers ought to be requested by application service providers. Because these requirements differ across applications, it is impossible to categorically stipulate universal rules (e.g., that all software implementations, service providers, and certification authorities for all application protocols need to use or support DNS-IDs as a baseline for the purpose of interoperability).

However, it is preferable that each application protocol will at least define a baseline that applies to the community of software developers, application service providers, and CAs actively using or 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:

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.
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

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 or names carried in the subject field (i.e., a CN-ID) and/or in one 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 [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]).

To reduce confusion, in this specification we avoid such terms and instead use the terms provided under Section 1.8; 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").

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.