Service Identity in TLS
obsoletes
- rfc-6125 — 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)
Extracted elements (28)
Intermediate domain names produced during DNS resolution (e.g., CNAME chains) are excluded from being treated as reference identifiers. This design choice removes DNS and DNS resolution from the attack surface by ensuring only the original user-supplied or explicitly configured domain name is used for certificate matching.
The Common Name RDN (CN-ID) was eliminated as a valid identifier for service identity because it is not strongly typed — it is essentially free-form text and suffers from ambiguities in interpretation. Only the subjectAltName extension, which provides formally defined identifier types, is now valid for expressing service identity.
Wildcards are constrained to appear only as the complete left-most label (e.g., '*.bigcompany.example' but not '*.*.bigcompany.example') to limit their scope and mitigate attacks where a wildcard on a high-level domain could be used to impersonate many distinct services. This deviates from DNS wildcard matching semantics intentionally.
A protocol technology that does not use DNS SRV records MUST state that SRV-ID is not supported. Similarly, a technology that does not use URIs to identify application services MUST state that URI-ID is not supported. A technology MAY disallow wildcard certificates entirely, in which case it MUST state so.
SVCB and HTTPS DNS resource record types do not currently alter any PKIX validation requirements specified herein. For example, PKIX validation rules for HTTP and DNS-over-TLS do not change when clients use SVCB-compatible records for connection lookup. Future SVCB mapping documents could specify altered rules for new use cases.
The TLS Server Name Indication (SNI) extension only conveys domain names. Therefore, a client with an IP-ID reference identity cannot present any information about its reference identity when connecting to a server; servers wishing to present an IP-ID must do so when a connection is made without SNI.
A certificate MUST include at least one identifier. It SHOULD include a DNS-ID as a baseline for interoperability, though a certificate may include only an SRV-ID or URI-ID to scope its use to a particular application type.
A URI-ID MUST include both a 'scheme' and a 'host' component matching the 'reg-name' rule; if the entry does not include both, it is not a valid URI-ID and MUST be ignored. Only the 'scheme' and 'host' components are used for certificate matching.
An IP-ID reference identifier MUST exactly match the value of an iPAddress entry in subjectAltName with no partial (e.g., network-level) matching. Matching is based on an octet-for-octet comparison of the bytes of the reference identity with those in the iPAddress subjectAltName.
For SRV-ID identifiers, the application service name MUST be matched in a case-insensitive manner. For URI-ID identifiers, the scheme name portion MUST be matched in a case-insensitive manner. The application service type portion is only combined with the DNS domain name portion from the same identifier.
For URI-IDs, the URI scheme MUST be that of the protocol associated with the application service type, and the 'host' component MUST be the FQDN of the service. The application protocol specification MUST specify which URI schemes are acceptable in URI-IDs.
If a technology specification supports wildcard certificates, a wildcard in a presented identifier is valid only if: (1) there is only one wildcard character, and (2) the wildcard character appears only as the complete content of the left-most label. A presented identifier that does not meet these requirements is invalid and MUST be ignored.
If the client controlled by a human finds no matching presented identifier, it SHOULD inform the user of the identity mismatch and automatically terminate the communication attempt. Such clients MAY give advanced users the option of proceeding despite the mismatch, but only with extreme caution.
If the client finds no matching presented identifier, an automated application SHOULD terminate the communication attempt with a bad certificate error. The application MAY provide a configuration setting to disable this, but MUST NOT disable this security control by default.
Protocol specifications MUST specify which identifiers are mandatory to implement and SHOULD provide operational guidance when necessary. This is required to address cross-protocol attacks such as ALPACA, which are possible when two different protocol services use the same certificate.
The client MUST construct a list of acceptable reference identifiers and MUST do so independently of the identifiers presented by the server. Intermediate domain names produced during DNS resolution MUST NOT be treated as reference identifiers.
The Common Name RDN MUST NOT be used to identify a service because it is not strongly typed (essentially free-form text) and suffers from ambiguities in interpretation. Other RDNs within the subjectName MUST NOT be used to identify a service either.
When matching DNS domain names, comparison MUST be performed using case-insensitive ASCII comparison of each label. For internationalized domain names, the client MUST convert U-labels to A-labels before comparison, and A-labels MUST be compared as case-insensitive ASCII.
A reference identifier is constructed from the source domain and optionally an application service type; it is what the client expects the server to present. A presented identifier is what the server includes in its PKIX certificate. The client verifies identity by checking each reference identifier against presented identifiers for a match.
DNS-ID is a subjectAltName entry of type dNSName as defined in PKIX. It is a direct and unrestricted identifier type: direct because provided directly by a user, unrestricted because it can be used for any type of service. It is the baseline identifier for interoperability.
IP-ID is a subjectAltName entry of type iPAddress as defined in PKIX. It is direct and unrestricted. An IP address is either a 4-octet IPv4 address or a 16-octet IPv6 address, and identifiers may need to be converted from textual representation to obtain the raw value for matching.
SRV-ID is a subjectAltName entry of type otherName whose name form is SRVName as defined in RFC 4985. It is typically indirect and restricted to a single application service type. The DNS domain name portion is the Name and the application service type is the Service (e.g., _imaps.isp.example gives domain isp.example and service imaps).
URI-ID is a subjectAltName entry of type uniformResourceIdentifier as defined in PKIX. It is direct and restricted to a specific application service type. The DNS domain name portion is the 'reg-name' part of the 'host' component and the application service type portion is the URI scheme.
A CA name-constrained only for DNS-IDs is not thereby constrained for SRV-IDs or URI-IDs. A client that constructs multiple reference identifiers of different types SHOULD ensure CAs issuing such certificates are appropriately constrained for all identifier types, not just one.
Cross-protocol attacks (such as ALPACA) are possible when two different protocol services share the same certificate. This can be addressed by using restricted identifiers (SRV-ID or URI-ID) that scope the certificate to a specific application service type, or by deploying services so they do not share certificates.
The set of names in a certificate defines the set of names affected by a compromise of any server in that set: the strength of the certificate is determined by the weakest server that presents any of those names. Service providers SHOULD request certificates with as few identifiers as necessary to identify a single service.
The textual representation of an IPv4 address may be misinterpreted as a valid FQDN in some contexts, leading different system components to classify the identifier differently and producing insecure behavior. Consistent classification of identifiers by all components is required to avoid this vulnerability.
Wildcard certificates automatically vouch for any single-label hostnames within their domain, posing the risk of vouching for rogue or buggy hosts. Restricting wildcards to one wildcard character in the left-most label only helps mitigate certain attack vectors; application protocols can disallow wildcard certificates entirely as a more foolproof mitigation.