| RFC 9525 | Service Identity in TLS | November 2023 |
| Saint-Andre & Salz | Standards Track | [Page] |
Many application technologies enable secure communication between two entitiesby means of Transport Layer Security (TLS) withInternet Public Key Infrastructure using X.509 (PKIX) certificates.This document specifiesprocedures for representing and verifying the identity of application servicesin such interactions.¶
This document obsoletes RFC 6125.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9525.¶
Copyright (c) 2023 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The visible face of the Internet largely consists of services that employ aclient-server architecture in which a clientcommunicates with an application service. When a client communicates with anapplication service using[TLS],[DTLS], or a protocol built on those([QUIC] being a notable example),it has some notion of the server'sidentity (e.g., "the website at bigcompany.example") while attempting to establishsecure communication. Likewise, during TLS negotiation, the server presentsits notion of the service's identity in the form of a public key certificatethat was issued by a certification authority (CA) in the context of theInternet Public Key Infrastructure using X.509[PKIX]. Informally, we canthink of these identities as the client's "reference identity" and theserver's "presented identity"; more formal definitions are given later. Aclient needs to verify that the server's presented identity matches itsreference identity so it can deterministically and automatically authenticate the communication.¶
This document defines procedures for how clients perform this verification.It therefore defines requirements on other parties, such asthe certification authorities that issue certificates, the service administrators requesting them, and the protocol designers defining interactions between clients and servers.¶
This document obsoletes RFC 6125[VERIFY]. Changes from RFC 6125[VERIFY] are described underAppendix A.¶
This document does not supersede the rules for certificate issuance orvalidation specified by[PKIX]. That document also governs anycertificate-related topic on which this document is silent. This includescertificate syntax, extensions such as name constraints orextended key usage, and handling of certification paths.¶
This document addresses only name forms in the leaf "end entity" servercertificate. It does not address the name forms in the chain of certificatesused to validate a certificate, nor does it create or check the validityof such a chain. In order to ensure proper authentication, applications needto verify the entire certification path.¶
The previous version of this specification,[VERIFY], surveyed the then-currentpractice from many IETF standards and tried to generalize best practices(seeAppendix A of [VERIFY] for details).¶
This document takes the lessons learned since then and codifies them.The following is a summary of the rules, which are described at greaterlength in the remainder of this document:¶
This document applies only to service identities that are used in TLS or DTLSand that are included in PKIX certificates.¶
With regard to TLS and DTLS, these security protocols are used toprotect data exchanged over a wide variety of application protocols,which use both the TLS or DTLS handshake protocol and the TLS orDTLS record layer, either directly or through a profile as in NetworkTime Security[NTS]. The TLS handshake protocol can also be usedwith different record layers to define secure transport protocols;at present, the most prominent example is QUIC[RFC9000]. Therules specified here are intended to apply to all protocols in thisextended TLS "family".¶
With regard to PKIX certificates, the primary usage is in thecontext of the public key infrastructure described in[PKIX].In addition, technologies such as DNS-Based Authenticationof Named Entities (DANE)[DANE] sometimes use certificates basedon PKIX (more precisely, certificates structured via[X.509] orspecific encodings thereof such as[X.690]), at least in certainmodes. Alternatively, a TLS peer could issue delegated credentialsthat are based on a CA-issued certificate, as in[TLS-SUBCERTS].In both cases, a TLS client could learn of a service identitythrough its inclusion in the relevant certificate. The rules specifiedhere are intended to apply whenever service identities are included inX.509 certificates or credentials that are derived from such certificates.¶
The following topics are out of scope for this specification:¶
Certification authority policies.This includes items such as the following:¶
Because many concepts related to "identity" are often too vague to beactionable in application protocols, we define a set of more concrete termsfor use in this specification.¶
A service on the Internet that enables clients to connect for thepurpose of retrieving or uploading information, communicating with otherentities, or connecting to a broader network of services.¶
An entity that hosts or deploys an application service.¶
A formal identifier for the application protocol used to provide aparticular kind of application service at a domain. This often appears asa URI scheme[URI], a DNS SRV Service[DNS-SRV], or an Application-Layer Protocol Negotiation (ALPN)[ALPN]identifier.¶
A particular instance of an identifier type that is either presented by aserver in a certificate or referenced by a client for matching purposes.¶
A formally defined category of identifier that can be included in acertificate and therefore be used for matching purposes. Forconciseness and convenience, we define the following identifier types ofinterest:¶
The short name for the Internet Public Key Infrastructure using X.509defined in[PKIX]. That document provides a profile of the X.509v3certificate specifications and X.509v2 certificate revocation list (CRL)specifications for use on the Internet.¶
An identifier presented by a server to a client within a PKIX certificatewhen the client attempts to establish secure communication with the server.The certificate can include one or more presented identifiers of differenttypes, and if the server hosts more than one domain, then the certificatemight present distinct identifiers for each domain.¶
An identifier expected by the client when examining presented identifiers.It is constructed from the source domain and, optionally, an applicationservice type.¶
An ASN.1-based construction that is itself a building-block component ofDistinguished Names. See[LDAP-DN],Section 2.¶
The FQDN that a client expects an applicationservice to present in the certificate. This is typically input bya human user, configured into a client, or provided by reference such asa URL. The combination of a source domain and, optionally, an applicationservice type enables a client to construct one or more referenceidentifiers. This specification covers FQDNs. Use of any names thatare not fully qualified is out of scope and may result in unexpectedor undefined behavior.¶
An identifier placed in a subjectAltName extension.¶
A standard PKIX extension enabling identifiers of various types to bebound to the certificate subject.¶
The name of a PKIX certificate's subject, encoded in a certificate'ssubject field (see[PKIX],Section 4.1.2.6).¶
TLS uses the words "client" and "server", where the client is the entitythat initiates the connection. In many cases, this is consistent with common practice,such as a browser connecting to a web origin.For the sake of clarity, and to follow the usage in[TLS] and relatedspecifications, we will continueto use the terms client and server in this document.However, these are TLS-layer roles, and the application protocolcould support the TLS server making requests to the TLS client after theTLS handshake; there is no requirement that the roles at the applicationlayer match the TLS layer.¶
Security-related terms used in this document, but not defined here or in[PKIX], should be understood in the sense defined in[SECTERMS]. Suchterms include "attack", "authentication", "identity", "trust", "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 asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.¶
This document assumes that an application service is identified by a DNS domainname (e.g.,bigcompany.example), an IP address (IPv4 or IPv6), or an identifierthat contains additional supplementary information. Supplementary informationis limited to the application service type as expressed in a DNS SRV record(e.g., "the IMAP server at isp.example" for "_imap.isp.example") or a URI.¶
In a DNS-ID -- and in the DNS domain name portion of an SRV-ID or URI-ID -- anycharacters outside the range described in[US-ASCII] are prohibited, and internationalizeddomain labels are represented as A-labels[IDNA-DEFS].¶
An IP address is either a 4-octet IPv4 address[IPv4] or a 16-octetIPv6 address[IPv6]. The identifier might need to be converted from atextual representation to obtain this value.¶
From the perspective of the application client or user, some identifiers aredirect because they are provided directly by a human user. This includesruntime input, prior configuration, or explicit acceptance of a clientcommunication attempt. Other names areindirect because they areautomatically resolved by the application based on user input, such as atarget name resolved from a source name using DNS SRV or the records described in[NAPTR].The distinction matters most for certificate consumption, specificallyverification as discussed in this document.¶
From the perspective of the application service, some identifiers areunrestricted because they can be used in any type of service, such as asingle certificate being used for both the HTTP and IMAP services at the host"bigcompany.example". Other identifiers arerestricted because they can only be used forone type of service, such as a special-purpose certificate that can only beused for an IMAP service. This distinction matters most for certificateissuance.¶
The four identifier types can be categorized as follows:¶
It is important to keep these distinctions in mind because best practicesfor the deployment and use of the identifiers differ.Note that cross-protocol attacks such as those described in[ALPACA]are possible when twodifferent protocol services use the same certificate.This can be addressed by using restricted identifiers or deployingservices so that they do not share certificates.Protocol specificationsMUST specify which identifiers aremandatory to implement andSHOULD provide operational guidance when necessary.¶
The Common Name RDNMUST NOT be used to identify a service becauseit is not strongly typed (it is essentially free-form text) and thereforesuffers from ambiguities in interpretation.¶
For similar reasons, other RDNs within the subjectNameMUST NOT be used toidentify a service.¶
An IP address that is the result of a DNS query is indirect. Use of IP-IDsthat are indirect is out of scope for this document.¶
The IETF continues to define methods for looking up information neededto make connections to network services. One recent example is servicebinding via the "SVCB" and "HTTPS" DNS resource record (RR) types. Thisdocument does not define any identity representation or verification proceduresthat are specific to SVCB-compatible records, because the use of such records duringconnection establishment does not currently alter any of the PKIX validationrequirements specified herein or in any other relevant specification.For example,the PKIX validation rules for[HTTP] and[DNS-OVER-TLS] do not changewhen the client uses the DNS resource records defined in[SVCB-FOR-HTTPS] or[SVCB-FOR-DNS] to look up connection information. However, it is possiblethat future SVCB mapping documents could specify altered PKIX rules for new use cases.¶
This section defines how protocol designers should reference this document, which would typically be a normative reference in their specification.¶
A specificationMAY choose to allow only one of the identifier types defined here.¶
If the technology does not use DNS SRV records to resolve the DNS domainnames of application services, then the specificationMUST state that SRV-IDas defined in this document is not supported. Note that many existingapplication technologies use DNS SRV records to resolve the DNS domain namesof application services, but they do not rely on representations of those recordsin PKIX certificates by means of SRV-IDs as defined in[SRVNAME].¶
If the technology does not use URIs to identify application services, thenthe specificationMUST state that URI-ID as defined in this document is notsupported. Note that many existing application technologies use URIs toidentify application services, but they do not rely on representation of thoseURIs in PKIX certificates by means of URI-IDs.¶
A technologyMAY disallow the use of the wildcard character in presented identifiers. Ifit does so, then the specificationMUST state that wildcard certificates asdefined in this document are not supported.¶
A protocol can allow the use of an IP address in place of a DNS name. Thismight use the same field without distinguishing the type of identifier as, forexample, in the "host" components of a URI. In this case, applications need to be aware that the textualrepresentation of an IPv4 address is a valid DNS name. The twotypes can be distinguished by first testing if the identifier is a valid IPv4address, as is done by the "first-match-wins" algorithm inSection 3.2.2 of [URI].¶
This section provides instructions for issuers ofcertificates.¶
When a certification authority issues a certificate based on the FQDNat which the application service providerwill provide the relevant application, the following rules apply tothe representation of application service identities.Note that some of these rules are cumulativeand can interact in important ways that are illustrated later in thisdocument.¶
sip but notsipsortel for SIP as described in[SIP-SIPS]). Typically, thisidentifier type would supplement the DNS-ID, unless the certificateis meant to be scoped to only the protocol in question.¶Consider a simple website at<www.bigcompany.example>, which is not discoverable viaDNS SRV lookups. Because HTTP does not specify the use of URIs in servercertificates, a certificate for this service might include only a DNS-ID of<www.bigcompany.example>.¶
Consider another website, which is reachable by a fixed IP address of2001:db8::5c. If the two sites refer to the same web service, thenthe certificate might also include this value in an IP-ID to allowclients to use the fixed IP address as a reference identity.¶
Consider an IMAP-accessible email server at the hostmail.isp.exampleservicing email addresses of the formuser@isp.example and discoverable viaDNS SRV lookups on the application service name ofisp.example. Acertificate for this service might include SRV-IDs of_imap.isp.example and_imaps.isp.example (see[EMAIL-SRV]) along with DNS-IDs ofisp.example andmail.isp.example.¶
Consider a SIP-accessible voice-over-IP (VoIP) server at the hostvoice.college.example servicing SIP addresses of the formuser@voice.college.example and identified by a URI of <sip:voice.college.example>.A certificate for this service would include a URI-ID of<sip:voice.college.example> (see[SIP-CERTS]) along with a DNS-ID ofvoice.college.example.¶
Consider an XMPP-compatible instant messaging (IM) server at the hostmessenger.example that services IM addresses of the formuser@messenger.example and that isdiscoverable via DNS SRV lookups on themessenger.example domain. Acertificate for this service might include SRV-IDs of_xmpp-client.messenger.example and_xmpp-server.messenger.example (see[XMPP]), as well as a DNS-ID ofmessenger.example.¶
This section provides instructions for service providers regardingthe information to include in certificate signing requests (CSRs).In general, service providersSHOULD request certificates thatinclude all the identifier types that are required or recommended forthe application service type that will be secured using the certificate tobe issued.¶
A service providerSHOULD request certificates with as few identifiers asnecessary to identify a single service; seeSection 7.5.¶
If the certificate will be used for only a single type of applicationservice, the service providerSHOULD request a certificate that includesDNS-ID or IP-ID values that identify that service or,if appropriate for the application service type, SRV-ID orURI-ID values that limit the deployment scope of the certificate to only thedefined application service type.¶
If the certificate might be used for any type of application service, the service providerSHOULD request a certificate that includesonly DNS-IDs or IP-IDs. Again, because of multiprotocol attacks, this practice isdiscouraged; it can be mitigated by deploying only one service ona host.¶
If a service provider offers multiple application service types and wishes tolimit the applicability of certificates using SRV-IDs or URI-IDs, itSHOULDrequest that multiple certificates rather than a single certificate containingmultiple SRV-IDs or URI-IDs each identify a different application servicetype. This rule does not apply to application service type "bundles" thatidentify distinct access methods to the same underlying application such asan email application with access methods denoted by the application servicetypes ofimap,imaps,pop3,pop3s, andsubmission as described in[EMAIL-SRV].¶
At a high level, the client verifies the application service'sidentity by performing the following actions:¶
Naturally, in addition to checking identifiers, a client should performfurther checks, such as expiration and revocation, to ensure that the serveris authorized to provide the requested service. Because such checking is not amatter of verifying the application service identity presented in acertificate, methods for doing so are out of scope forthis document.¶
The clientMUST construct a list of acceptable reference identifiersandMUST do so independently of the identifiers presented by theserver.¶
The inputs used by the client to construct its list of reference identifiersmight be a URI that a user has typed into an interface (e.g., an HTTPS URLfor a website), configured account information (e.g., the domain name of ahost for retrieving email, which might be different from the DNS domain nameportion of a username), a hyperlink in a web page that triggers a browser toretrieve a media object or script, or some other combination of informationthat can yield a source domain and an application service type.¶
This document does not precisely define how reference identifiers are generated.Defining reference identifiers is the responsibility of applications or protocols that use thisdocument. Because the security of a system that uses this document will dependon how reference identifiers are generated, great care should be taken in thisprocess. For example, a protocol or application could specify that the applicationservice type is obtained through a one-to-one mapping of URI schemes to servicetypes or that the protocol or application supports only a restricted set of URI schemes.Similarly, it couldspecify that a domain name or an IP address taken as input to the referenceidentifier must be obtained in a secure context such as a hyperlink embedded ina web page that was delivered over an authenticated and encrypted channel(for instance, see[SECURE-CONTEXTS] with regard to the web platform).¶
Naturally, if the inputs themselves are invalid or corrupt (e.g., a user hasclicked a hyperlink provided by a malicious entity in a phishing attack),then the client might end up communicating with an unexpected applicationservice.¶
During the course of processing, a client might be exposed to identifiers thatlook like, but are not, reference identifiers. For example, DNS resolution thatstarts at a DNS-ID reference identifier might produce intermediate domain namesthat need to be further resolved. Unless an application defines a processfor authenticating intermediate identifiers in a way that then allowsthem to be used as a reference identifier (for example, see[SMTP-TLS]),any intermediate values are not referenceidentifiers andMUST NOT be treated as such.In the DNS case, not treating intermediate domain names as reference identifiersremoves DNS and DNS resolution from the attack surface.¶
As one example of the process of generating a reference identifier, from the userinput of the URI <sip:alice@voice.college.example>, a client could derive the applicationservice typesip from the URI scheme and parse the domain namecollege.example from the "host" component.¶
Using the combination of one or more FQDNs or IP addresses, plus optionally an application service type, the clientMUST construct its list of reference identifiers in accordance with thefollowing rules:¶
Which identifier types a client includes in its list of referenceidentifiers, and their priority, is a matter of local policy. For example, aclient that is built to connect only to a particular kind of service might beconfigured to accept as valid only certificates that include an SRV-ID forthat application service type. By contrast, a more lenient client, even ifbuilt to connect only to a particular kind of service, might includeSRV-IDs, DNS-IDs, and IP-IDs in its list of reference identifiers.¶
The following examples are for illustrative purposes only and are notintended to be comprehensive.¶
<https://www.bigcompany.example/> would have a single reference identifier:a DNS-ID ofwww.bigcompany.example.¶<https://192.0.2.107/> would have a singleIP-ID reference identifier of192.0.2.107. Likewise, if connectingto<https://[2001:db8::abcd]>, it would have a single IP-IDreference identifier of2001:db8::abcd.¶isp.example (resolved asmail.isp.example) might have three referenceidentifiers: an SRV-ID of_imaps.isp.example (see[EMAIL-SRV]) andDNS-IDs ofisp.example andmail.isp.example. An email user agent thatdoes not support[EMAIL-SRV] would probably be explicitly configured toconnect tomail.isp.example, whereas an SRV-aware user agent would deriveisp.example from an email address of the formuser@isp.example but mightalso acceptmail.isp.example as the DNS domain name portion of referenceidentifiers for the service.¶voice.college.example might have only one reference identifier:a URI-ID ofsip:voice.college.example (see[SIP-CERTS]).¶messenger.example might have three reference identifiers: anSRV-ID of_xmpp-client.messenger.example (see[XMPP]), a DNS-ID ofmessenger.example, and an XMPP-specificXmppAddr ofmessenger.example(see[XMPP]).¶In all these cases, presented identifiers that do not match the referenceidentifier(s) would be rejected; for instance:¶
web.bigcompany.example wouldbe rejected because the DNS domain name portion does not matchwww.bigcompany.example.¶Once the client has constructed its list of reference identifiers and hasreceived the server's presented identifiers,the client checks its reference identifiers against the presented identifiersfor the purpose of finding a match.The search fails if the client exhaustsits list of reference identifiers without finding a match. The search succeedsif any presented identifier matches one of the reference identifiers, atwhich point the clientSHOULD stop the search.¶
Before applying the comparison rules provided in the followingsections, the client might need to split the reference identifier intocomponents.Each reference identifier produces either a domain name or an IP address andoptionally an application service type as follows:¶
_imaps.isp.example has a DNS domain name portionofisp.example and an application service type portion ofimaps, which maps to the IMAP application protocol as explained in[EMAIL-SRV].¶<sip:voice.college.example> would be splitinto a DNS domain name portion ofvoice.college.example and an applicationservice type ofsip (associated with an application protocol of SIP asexplained in[SIP-CERTS]).¶If the reference identifier produces a domain name, the clientMUST match theDNS name; seeSection 6.3.If the reference identifier produces an IP address, the clientMUST match the IPaddress; seeSection 6.4.If an application service type is present, itMUST also match theservice type; seeSection 6.5.¶
This section describes how the client must determine if the presented DNSname matches the reference DNS name. The rules differ depending on whetherthe domain to be checked is aninternationalized domain name, as defined inSection 2, or not.For clientsthat support presented identifiers containing the wildcard character "*", this sectionalso specifies a supplemental rule for such "wildcard certificates".This section uses the description of labels and domain names in[DNS-CONCEPTS].¶
If the DNS domain name portion of a reference identifier is not an internationalized domain name (i.e., an FQDN that conforms to "preferred name syntax" asdescribed inSection 3.5 of [DNS-CONCEPTS]),then the matching of the reference identifier against the presentedidentifierMUST be performed by comparing the set of domain name labels usinga case-insensitive ASCII comparison, as clarified by[DNS-CASE]. Forexample,WWW.BigCompany.Example would be lower-cased towww.bigcompany.example forcomparison purposes. Each labelMUST match in order for the names to beconsidered a match, except as supplemented by the rule about checkingwildcard labels in presented identifiers given below.¶
If the DNS domain name portion of a reference identifier is aninternationalized domain name, then the clientMUST convert any U-labels[IDNA-DEFS] in the domain name to A-labels before checking the domain nameor comparing it with others. In accordance with[IDNA-PROTO], A-labelsMUST be compared as case-insensitive ASCII. Each labelMUST match in orderfor the domain names to be considered to match, except as supplemented bythe rule about checking wildcard labels in presented identifiers given below.¶
If the technology specification supports wildcards in presented identifiers, then the clientMUSTmatch the reference identifier against a presented identifier whose DNSdomain name portion contains the wildcard character "*" in a label, providedthese requirements are met:¶
If the requirements are not met, the presented identifier is invalid andMUSTbe ignored.¶
A wildcard in a presented identifier can only match one label in areference identifier. This specification covers only wildcard characters inpresented identifiers, not wildcard characters in reference identifiers or inDNS domain names more generally. Therefore, the use of wildcard charactersas described herein is not to be confused with DNS wildcardmatching, where the "*" label always matches at least one whole label andsometimes more; see[DNS-CONCEPTS],Section 4.3.3 and[DNS-WILDCARDS].In particular, it also deviates from[DNS-WILDCARDS],Section 2.1.3.¶
For information regarding the security characteristics of wildcardcertificates, seeSection 7.1.¶
Matching of an IP-ID is based on an octet-for-octet comparison of the bytes of thereference identity with the bytes contained in the iPAddress subjectAltName.¶
For an IP address that appears in a URI-ID, the "host" component of both thereference identity and the presented identifier must match. These are parsed as eitheran "IPv6address" (following[URI],Section 3.2.2) or an "IPv4address" (following[IPv4]).If the resulting octets are equal, the IP address matches.¶
This document does not specify how an SRV-ID reference identity can include anIP address, as[SRVNAME] only defines string names, not octet identifierssuch as an IP address.¶
The rules for matching the application service type depend on whetherthe identifier is an SRV-ID or a URI-ID.¶
These identifiers provide an application service type portion to be checked,but that portion is combined only with the DNS domain name portion of theSRV-ID or URI-ID itself. Consider the example of a messaging client that has two referenceidentifiers: (1) an SRV-ID of_xmpp-client.messenger.example and (2) a DNS-IDofapp.example. The clientMUST check (1) the combination of (a) anapplication service type ofxmpp-client and (b) a DNS domain name ofmessenger.example as well as (2)a DNS domain name ofapp.example. However, theclientMUST NOT check the combination of an application service type ofxmpp-client and a DNS domain name ofapp.example because it does nothave an SRV-ID of_xmpp-client.app.example in its list of referenceidentifiers.¶
If the identifier is an SRV-ID, then the application service nameMUSTbe matched in a case-insensitive manner, in accordance with[DNS-SRV].Note that per[SRVNAME], the underscore "_" is part of the service name inDNS SRV records and in SRV-IDs.¶
If the identifier is a URI-ID, then the scheme name portionMUST bematched in a case-insensitive manner, in accordance with[URI].Note that the colon ":" is a separator between the scheme nameand the rest of the URI and thus does not need to be included in anycomparison.¶
If the client has found a presented identifier that matches a referenceidentifier, then the service identity check has succeeded. In this case, theclientMUST use the matched reference identifier as the validated identity ofthe application service.¶
If the client does not find a presented identifier matching any of thereference identifiers, then the clientMUST proceed as follows.¶
If the client is an automated application,then itSHOULD terminate the communication attempt with a badcertificate error and log the error appropriately. The applicationMAYprovide a configuration setting to disable this behavior, but itMUST NOTdisable this security control by default.¶
If the client is one that is directly controlled by a humanuser, then itSHOULD inform the user of the identity mismatch andautomatically terminate the communication attempt with a bad certificateerror in order to prevent users from inadvertently bypassing securityprotections in hostile situations.Such clientsMAY give advanced users the option of proceedingwith acceptance despite the identity mismatch. Although this behavior can beappropriate in certain specialized circumstances, it needs to be handled withextreme caution, for example by first encouraging even an advanced user toterminate the communication attempt and, if they choose to proceed anyway, byforcing the user to view the entire certification path before proceeding.¶
The applicationMAY also present the user with the ability to accept thepresented certificate as valid for subsequent connections. Such ad hoc"pinning"SHOULD NOT restrict future connections to just the pinnedcertificate. Local policy that statically enforces a given certificate for agiven peerSHOULD be made available only as prior configuration rather than ajust-in-time override for a failed connection.¶
Wildcard certificates automatically vouch for any single-label hostnameswithin their domain, but not multiple levels of domains. This can beconvenient for administrators but also poses the risk of vouching for rogueor buggy hosts. For example, see[Defeating-SSL] (beginning at slide 91) and[HTTPSbytes] (slides 38-40).¶
As specified inSection 6.3, restricting the presented identifiers in certificates to only onewildcard character (e.g., "*.bigcompany.example" but not "*.*.bigcompany.example") andrestricting the use of wildcards to only the left-most domain label canhelp to mitigate certain aspects of the attack described in[Defeating-SSL].¶
That same attack also relies on the initial use of a cleartext HTTP connection,which is hijacked by an active on-path attacker and subsequently upgraded toHTTPS. In order to mitigate such an attack, administrators and softwaredevelopers are advised to follow the strict TLS guidelines provided in[TLS-REC],Section 3.2.¶
Because the attack described in[HTTPSbytes] relies on an underlyingcross-site scripting (XSS) attack, web browsers and applications are advisedto follow best practices to prevent XSS attacks; for example, see[XSS], which waspublished by the Open Web Application Security Project (OWASP).¶
Protection against a wildcard that identifies a public suffix[Public-Suffix], such as*.co.uk or*.com, is beyond the scope of thisdocument.¶
As noted inSection 3, application protocols can disallow the use ofwildcard certificates entirely as a more foolproof mitigation.¶
The URI-ID type is a subjectAltName entry of type uniformResourceIdentifieras defined in[PKIX]. For the purposes of this specification, the URI-IDMUST include both a "scheme" and a "host" component that matches the "reg-name"rule; if the entry does not include both, it is not a valid URI-ID andMUST beignored. Any other components are ignored because only the "scheme" and "host"components are used for certificate matching as specified underSection 6.¶
The quoted component names in the previous paragraph represent the associated[ABNF] productions from the IETF Proposed Standard for Uniform Resource Identifiers[URI]. Although the reader should be aware that some applications (e.g.,web browsers) might instead conform to the Uniform Resource Locator (URL)specification maintained by the WHATWG[URL], it is not expected thatdifferences between the URI and URL specifications would manifest themselvesin certificate matching.¶
This document specifies only matching between reference identifiers andpresented identifiers, not the visual presentation of domain names. Specifically, the matching of internationalized domain names is performed onA-labels only (Section 6.3). The limited scope of this specification likelymitigates potential confusion caused by the use of visually similar charactersin domain names (for example, as described inSection 4.4 of [IDNA-DEFS],[UTS-36], and[UTS-39]); in any case, such concerns are a matter forapplication-level protocols and user interfaces, not the matching of certificates.¶
The TLS Server Name Indication (SNI) extension only conveys domain names.Therefore, a client with an IP-ID reference identity cannot present anyinformation about its reference identity when connecting to a server. Serversthat wish to present an IP-ID therefore need to present this identity when aconnection is made without SNI.¶
The textual representation of an IPv4 address might be misinterpretedas a valid FQDN in some contexts. This can result in differentsecurity treatment that might cause different components of a systemto classify the value differently, which might lead tovulnerabilities. Consider a system in which one component enforces asecurity rule that is conditional on the type of identifier but misclassifies an IP address as an FQDN, whereas a second component correctly classifies the identifier but incorrectly assumes that rules regarding IP addresses have been enforced by the first component. As a result, the system as a whole might behave in an insecure manner. Consistent classification of identifiers avoids this problem.¶
A given application service might be addressed by multiple DNS domain namesfor a variety of reasons, and a given deployment might service multipledomains or protocols.TLS extensions such as the Server Name Indication (SNI), as discussed in[TLS-EXT],Section 3, and ALPN, as discussed in[ALPN], provide a way for the applicationto indicate the desired identifier and protocol to the server, which itcan then use to select the most appropriate certificate.¶
This specification allows multiple DNS-IDs, IP-IDs, SRV-IDs, or URI-IDs in acertificate. As a result, an application service can use the samecertificate for multiple hostnames, such as when a client does not supportthe TLS SNI extension, or for multiple protocols, such as SMTP and HTTP, on asingle hostname. Note that the set of names in a certificate is the set ofnames that could be affected by a compromise of any other server named inthe set: the strength of any server in the set of names is determined by theweakest of those servers that offer the names.¶
The way to mitigate this risk is to limit the number of names thatany server can speak for and to ensure that all servers in the sethave a strong minimum configuration as described in[TLS-REC],Section 3.9.¶
This specification describes how a client may construct multiple acceptablereference identifiers and may match any of those reference identifiers withthe set of presented identifiers.[PKIX],Section 4.2.1.10 describes amechanism to allow CA certificates to be constrained in the set of presentedidentifiers that they may include within server certificates. However, theseconstraints only apply to the explicitly enumerated name forms. For example,a CA that is only name-constrained for DNS-IDs is not constrained for SRV-IDsand URI-IDs, unless those name forms are also explicitly included within thename constraints extension.¶
A client that constructs multiple reference identifiers of different types,such as both DNS-IDs and SRV-IDs as described inSection 6.1.1,SHOULD take care to ensure that CAs issuing such certificates areappropriately constrained. ThisMAY take the form of local policy throughagreement with the issuing CA orMAY be enforced by the client requiringthat if one form of presented identifier is constrained, such as a dNSNamename constraint for DNS-IDs, then all other forms of acceptable referenceidentities are also constrained, such as requiring a uniformResourceIndicatorname constraint for URI-IDs.¶
This document assumes that if a client trusts a given CA, it trusts allcertificates issued by that CA. The certificate checking process does notinclude additional checks for bad behavior by the hosts identified withsuch certificates, for instance, rogue servers or buggy applications. Anyadditional checks (e.g., checking the server name against trusted blocklists) are the responsibility of the application protocol or the clientitself.¶
This document has no IANA actions.¶
This document revises and obsoletes[VERIFY] basedon the decade of experience and changes since it was published.The major changes, in no particular order, include:¶
CN-ID in[VERIFY].¶We gratefully acknowledge everyone who contributed to the previousversion of this specification[VERIFY].Thanks also toCarsten Bormann for converting the previous version of this specification to Markdown so that we could more easily useMartin Thomson'si-d-templatesoftware.¶
In addition to discussions within the UTA Working Group, the following peopleprovided official reviews or especially significant feedback:Corey Bonnell,Roman Danyliw,Viktor Dukhovni,Lars Eggert,Patrik Fältström,Jim Fenton,Olle Johansson,John Klensin,Murray Kucherawy,Warren Kumari,John Mattson,Alexey Melnikov,Derrell Piper,Maria Ines Robles,Rob Sayre,Yaron Sheffer,Ryan Sleevi,Brian Smith,Petr Špaček,Orie Steele,Martin Thomson,Joe Touch,Éric Vyncke,Paul Wouters,andQin Wu.¶
Jeff Hodges coauthored the previous version of this specification[VERIFY].The authors gratefully acknowledge his essential contributions to this work.¶
Martin Thomson contributed the text on the handling of IP-IDs.¶