idnits 2.17.1 draft-ietf-uta-rfc6125bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6125 (ref. 'VERIFY') (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Mozilla 4 Obsoletes: 6125 (if approved) J. Hodges 5 Intended status: Standards Track Google 6 Expires: 16 April 2022 R. Salz 7 Akamai Technologies 8 13 October 2021 10 Representation and Verification of Domain-Based Application Service 11 Identity within Internet Public Key Infrastructure Using X.509 (PKIX) 12 Certificates in the Context of Transport Layer Security (TLS) 13 draft-ietf-uta-rfc6125bis-03 15 Abstract 17 Many application technologies enable secure communication between two 18 entities by means of Transport Layer Security (TLS) with Internet 19 Public Key Infrastructure Using X.509 (PKIX) certificates. This 20 document specifies procedures for representing and verifying the 21 identity of application services in such interactions. 23 This document obsoletes RFC 6125. 25 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Discussion of this document takes place on the Using TLS in 30 Applications Working Group mailing list (uta@ietf.org), which is 31 archived at https://mailarchive.ietf.org/arch/browse/uta/. 33 Source for this draft and an issue tracker can be found at 34 https://github.com/richsalz/draft-ietf-uta-rfc6125bis. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 16 April 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.2. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 3 72 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 73 1.4. Overview of Recommendations . . . . . . . . . . . . . . . 4 74 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.5.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 5 76 1.5.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5 77 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 78 2. Naming of Application Services . . . . . . . . . . . . . . . 9 79 3. Designing Application Protocols . . . . . . . . . . . . . . . 10 80 4. Representing Server Identity . . . . . . . . . . . . . . . . 11 81 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5. Requesting Server Certificates . . . . . . . . . . . . . . . 12 84 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 13 85 6.1. Constructing a List of Reference Identifiers . . . . . . 13 86 6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 15 88 6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 15 89 6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 16 90 6.4. Matching the Application Service Type Portion . . . . . . 17 91 6.5. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 19 94 7.2. Internationalized Domain Names . . . . . . . . . . . . . 19 95 7.3. Multiple Presented Identifiers . . . . . . . . . . . . . 20 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 99 9.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 1.1. Motivation 107 The visible face of the Internet largely consists of services that 108 employ a client-server architecture in which an interactive or 109 automated client communicates with an application service. When a 110 client communicates with an application service using Transport Layer 111 Security [TLS] or Datagram Transport Layer Security [DTLS], it has 112 some notion of the server's identity (e.g., "the website at 113 example.com") while attempting to establish secure communication. 114 Likewise, during TLS negotiation, the server presents its notion of 115 the service's identity in the form of a public-key certificate that 116 was issued by a certification authority (CA) in the context of the 117 Internet Public Key Infrastructure using X.509 [PKIX]. Informally, 118 we can think of these identities as the client's "reference identity" 119 and the server's "presented identity" (more formal definitions are 120 given later). A client needs to verify that the server's presented 121 identity matches its reference identity so it can authenticate the 122 communication. 124 This document defines procedures for how clients do this 125 verification. It therefore implicitly defines requirements on other 126 parties, such as the CA's that issue certificates, the service 127 administrators requesting them, and the protocol designers defining 128 how things are named. 130 1.2. Changes since RFC 6125 132 This document revises and obsoletes [VERIFY] based on the decade of 133 experience and changes since it was first published. The major 134 changes, in no particular order, include: 136 * All references have been updated to the current latest version. 138 * The TLS SNI extension is no longer new, it is commonplace. 140 * The only legal place for a certificate wildcard name is as the 141 left-most component in a domain name. 143 * It is no longer allowed to use the commonName RDN, known as CN-ID, 144 to represent the server identity; only the subjectAltNames 145 extension is used. 147 * References to the X.500 directory, the survey of prior art, and 148 the sample text in Appendix A have been removed. 150 * Detailed discussion of pinning (configuring use of a certificate 151 that doesn't match the criteria in this document) has been 152 removed. 154 * The sections detailing different target audiences and which 155 sections to read (first) have been removed. 157 1.3. Applicability 159 This document does not supersede the rules for certificate issuance 160 or validation specified by [PKIX]. That document also governs any 161 certificate-related topic on which this document is silent. This 162 includes certificate syntax, certificate extensions such as name 163 constraints or extended key usage, and handling of certification 164 paths. 166 This document addresses only name forms in the leaf "end entity" 167 server certificate. It does not address the name forms in the chain 168 of certificates used to validate a cetrificate, let alone creating or 169 checking the validity of such a chain. In order to ensure proper 170 authentication, applications need to verify the entire certification 171 path as per [PKIX]. 173 1.4. Overview of Recommendations 175 The previous version of this specification, [VERIFY], surveyed the 176 current practice from many IETF standards and tried to generalize 177 best practices. This document takes the lessons learned in the past 178 decade and codifies them. he rules are brief: 180 * Only check DNS domain names via the subjectAlternativeName 181 extension designed for that purpose: dNSName. 183 * Allow use of even more specific subjectAlternativeName extensions 184 where appropriate such as uniformResourceIdentifier and the 185 otherName form SRVName. 187 * Constrain wildcard certificates so that the wildcard can only be 188 the left-most component of a domain name. 190 * Do not include or check strings that look like domain names in the 191 subject's Common Name. 193 1.5. Scope 195 1.5.1. In Scope 197 This document applies only to service identities associated with 198 FQDNs only to TLS and DTLS, and only to PKIX-based systems. 200 TLS uses the words client and server, where the client is the entity 201 that initiates the connection. In many cases, this models common 202 practice, such as a browser connecting to a Web origin. For the sake 203 of clarity, and to follow the usage in [TLS] and related 204 specifications, we will continue to use to use the terms client and 205 server in this document. Note that these are TLS-layer roles, and 206 that the application protocol could support the TLS server making 207 requests to the TLS client after the TLS handshake; these is no 208 requirement that the roles at the application layer match the TLS- 209 layer. 211 At the time of this writing, other protocols such as [QUIC] and 212 Network Time Security ([NTS]) use TLS as a service to do the initial 213 establishment of cryptographic key material. Such services MUST also 214 follow the rules specified here. 216 1.5.2. Out of Scope 218 The following topics are out of scope for this specification: 220 * Security protocols other than [TLS] or [DTLS] except as described 221 above. 223 * Keys or certificates employed outside the context of PKIX-based 224 systems. 226 * Client or end-user identities. Certificates representing client 227 identities other than that described above, such as rfc822Name, 228 are beyond the scope of this document. 230 * Identifiers other than FQDNs. Identifiers such as IP address are 231 not discussed. In addition, the focus of this document is on 232 application service identities, not specific resources located at 233 such services. Therefore this document discusses Uniform Resource 234 Identifiers [URI] only as a way to communicate a DNS domain name 235 (via the URI "host" component or its equivalent), not other 236 aspects of a service such as a specific resource (via the URI 237 "path" component) or parameters (via the URI "query" component). 239 * Certification authority policies. This includes items such as the 240 following: 242 - How to certify or validate FQDNs and application service types 243 (see [ACME] for some definition of this). 245 - Issuing certificates with additional identifiers such as IP 246 address or relative domain name, in addition to FQDNs. 248 - Types or "classes" of certificates to issue and whether to 249 apply different policies for them. 251 - How to certify or validate other kinds of information that 252 might be included in a certificate (e.g., organization name). 254 * Resolution of DNS domain names. Although the process whereby a 255 client resolves the DNS domain name of an application service can 256 involve several steps, for our purposes we care only about the 257 fact that the client needs to verify the identity of the entity 258 with which it communicates as a result of the resolution process. 259 Thus the resolution process itself is out of scope for this 260 specification. 262 * User interface issues. In general, such issues are properly the 263 responsibility of client software developers and standards 264 development organizations dedicated to particular application 265 technologies (see, for example, [WSC-UI]). 267 1.6. Terminology 269 Because many concepts related to "identity" are often too vague to be 270 actionable in application protocols, we define a set of more concrete 271 terms for use in this specification. 273 application service: A service on the Internet that enables 274 interactive and automated clients to connect for the purpose of 275 retrieving or uploading information, communicating with other 276 entities, or connecting to a broader network of services. 278 application service provider: An organization or individual that 279 hosts or deploys an application service. 281 application service type: A formal identifier for the application 282 protocol used to provide a particular kind of application service 283 at a domain. This often apepars as a URI scheme [URI] or a DNS 284 SRV Service [DNS-SRV]. 286 automated client: A software agent or device that is not directly 287 controlled by a human user. 289 delegated domain: A domain name or host name that is explicitly 290 configured for communicating with the source domain, by either the 291 human user controlling an interactive client or a trusted 292 administrator. For example, a server at mailhost.example.com for 293 connecting to an IMAP server hosting an email address of 294 user@example.com. 296 derived domain: A domain name or host name that a client has derived 297 from the source domain in an automated fashion (e.g., by means of 298 a [DNS-SRV] lookup). 300 identifier: A particular instance of an identifier type that is 301 either presented by a server in a certificate or referenced by a 302 client for matching purposes. 304 identifier type: A formally defined category of identifier that can 305 be included in a certificate and therefore that can also be used 306 for matching purposes. For conciseness and convenience, we define 307 the following identifier types of interest, which are based on 308 those found in the PKIX specification [PKIX] and various PKIX 309 extensions: 311 * DNS-ID: a subjectAltName entry of type dNSName 313 * SRV-ID: a subjectAltName entry of type otherName whose name 314 form is SRVName; see [SRVNAME] 316 * URI-ID: a subjectAltName entry of type 317 uniformResourceIdentifier whose value includes both (i) a 318 "scheme" and (ii) a "host" component (or its equivalent) that 319 matches the "reg-name" rule (where the quoted terms represent 320 the associated [ABNF] productions from [URI]) An entry which 321 does not have both the scheme and host is not a valid URI-ID 322 and MUST be ignored. 324 interactive client: A software agent or device that is directly 325 controlled by a human user, commonly known as a "user agent." 327 PKIX: PKIX is a short name for the Internet Public Key 328 Infrastructure using X.509 defined in [PKIX]. That document 329 provides a profile of the X.509v3 certificate specifications and 330 X.509v2 certificate revocation list (CRL) specifications for use 331 in the Internet. 333 presented identifier: An identifier presented by a server to a 334 client within a PKIX certificate when the client attempts to 335 establish secure communication with the server. The certificate 336 can include one or more presented identifiers of different types, 337 and if the server hosts more than one domain then the certificate 338 might present distinct identifiers for each domain. 340 reference identifier: An identifier used by the client when 341 examining presented identifiers. It is constructed from the 342 source domain, and optionally an application service type. 344 Relative Distinguished Name (RDN): The ASN.1-based construction 345 comprising a Relative Distinguished Name (RDN), which itself is a 346 building-block component of Distinguished Names. See [LDAP-DN], 347 Section 2. 349 source domain: The FQDN that a client expects an application service 350 to present in the certificate. This is typically input by a human 351 user, configured into a client, or provided by reference such as 352 URL. The combination of a source domain and, optionally, an 353 application service type enables a client to construct one or more 354 reference identifiers. 356 subjectAltName entry: An identifier placed in a subjectAltName 357 extension. 359 subjectAltName extension: A standard PKIX certificate extension 360 [PKIX] enabling identifiers of various types to be bound to the 361 certificate subject. 363 subject name: In this specification, the term refers to the name of 364 a PKIX certificate's subject, encoded in a certificate's subject 365 field (see [PKIX], Section 4.1.2.6). 367 Security-related terms used in this document, but not defined here or 368 in [PKIX] should be understood in the the sense defined in 369 [SECTERMS]. Such terms include "attack", "authentication", 370 "identity", "trust", "validate", and "verify". 372 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 373 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 374 "OPTIONAL" in this document are to be interpreted as described in 375 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 376 capitals, as shown here. 378 2. Naming of Application Services 380 This document assumes that the name of an application service is 381 based on a DNS domain name (e.g., example.com) -- supplemented in 382 some circumstances by an application service type (e.g., "the IMAP 383 server at example.com"). The DNS name conforms to one of the 384 following forms: 386 1. A "traditional domain name", i.e., a FQDN (see [DNS-CONCEPTS]) 387 all of whose labels are "LDH labels" as described in [IDNA-DEFS]. 388 Informally, such labels are constrained to [US-ASCII] letters, 389 digits, and the hyphen, with the hyphen prohibited in the first 390 character position. Additional qualifications apply (refer to 391 the above-referenced specifications for details), but they are 392 not relevant here. 394 2. An "internationalized domain name", a DNS domain name that 395 includes at least one label containing appropriately encoded 396 Unicode code points outside the traditional US-ASCII range. That 397 is, it contains at least one U-label or A-label, but otherwise 398 may contain any mixture of NR-LDH labels, A-labels, or U-labels, 399 as described in [IDNA-DEFS] and the associated documents. 401 From the perspective of the application client or user, some names 402 are _direct_ because they are provided directly by a human user. 403 This includes runtime input, prior configuration, or explicit 404 acceptance of a client communication attempt. Other names are 405 _indirect_ because they are automatically resolved by the application 406 based on user input, such as a target name resolved from a source 407 name using DNS SRV or [NAPTR] records). The distinction matters most 408 for certificate consumption, specifically verification as discussed 409 in this document. 411 From the perspective of the application service, some names are 412 _unrestricted_ because they can be used in any type of service, such 413 as a single certificate being used for both the HTTP and IMAP 414 services at the host example.com. Other names are _restricted_ 415 because they can only be used for one type of service, such as a 416 special-purpose certificate that can only be used for an IMAP 417 service. This distinction matters most for certificate issuance. 419 We can categorize the supported identifier types as follows: 421 * A DNS-ID is direct and unrestricted. 423 * An SRV-ID is typically indirect but can be direct, and is 424 restricted. 426 * A URI-ID is direct and restricted. 428 It is important to keep these distinctions in mind, as best practices 429 for the deployment and use of the identifiers differ. As a further 430 example, cross-protocol attacks such as [ALPACA] are possibile when 431 two different protocol services use the same certificate. This can 432 be addressed by using restricted identifiers, or telling services to 433 not share certificates. Protocol specifications MUST specify which 434 identifiers are mandatory-to-implement and SHOULD provide operational 435 guidance when necessary. 437 The Common Name RDN MUST NOT be used to identify a service. Reasons 438 for this include: 440 * It is not strongly typed and therefore suffers from ambiguities in 441 interpretation. 443 * It can appear more than once in the Subject Name. 445 For similar reasons, other RDN's within the Subject Name MUST NOT be 446 used to identify a service. 448 3. Designing Application Protocols 450 This section defines how protocol designers should reference this 451 document, which MUST be a normative reference in their specification. 452 The technology MUST only use the identifiers defined in this 453 document. Its specification MAY choose to allow only one of them. 455 If the technology does not use DNS SRV records to resolve the DNS 456 domain names of application services then its specification MUST 457 state that SRV-ID as defined in this document is not supported. Note 458 that many existing application technologies use DNS SRV records to 459 resolve the DNS domain names of application services, but do not rely 460 on representations of those records in PKIX certificates by means of 461 SRV-IDs as defined in [SRVNAME]. 463 If the technology does not use URI's to identify application 464 services, then its specification MUST state that URI-ID as defined in 465 this document is not supported. Note that many existing application 466 technologies use URIs to identify application services, but do not 467 rely on representation of those URIs in PKIX certificates by means of 468 URI-IDs. 470 A technology MAY disallow the use of the wildcard character in DNS 471 names. If it does so, then the specification MUST state that 472 wildcard certificates as defined in this document are not supported. 474 4. Representing Server Identity 476 This section provides instructions for issuers of certificates. 478 4.1. Rules 480 When a certification authority issues a certificate based on the FQDN 481 at which the application service provider will provide the relevant 482 application, the following rules apply to the representation of 483 application service identities. Note that some of these rules are 484 cumulative and can interact in important ways that are illustrated 485 later in this document. 487 1. The certificate MUST include a "DNS-ID" as a baseline for 488 interoperability. 490 2. If the service using the certificate deploys a technology for 491 which the relevant specification stipulates that certificates 492 ought to include identifiers of type SRV-ID (e.g., this is true 493 of [XMPP]), then the certificate SHOULD include an SRV-ID. 495 3. If the service using the certificate deploys a technology for 496 which the relevant specification stipulates that certificates 497 ought to include identifiers of type URI-ID (e.g., this is true 498 of [SIP] as specified by [SIP-CERTS]), then the certificate 499 SHOULD include a URI-ID. The scheme MUST be that of the protocol 500 associated with the application service type and the "host" 501 component (or its equivalent) MUST be the FQDN of the service. 502 The application protocol specification MUST specify which URI 503 schemes are acceptable in URI-IDs contained in PKIX certificates 504 used for the application protocol (e.g., sip but not sips or tel 505 for SIP as described in [SIP-SIPS]). 507 4. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 508 ID as further explained under Section 7.3. 510 5. The certificate MAY include other application-specific 511 identifiers for compatibility with a deployed base. Such 512 identifiers are out of scope for this specification. 514 4.2. Examples 516 Consider a simple website at www.example.com, which is not 517 discoverable via DNS SRV lookups. Because HTTP does not specify the 518 use of URIs in server certificates, a certificate for this service 519 might include only a DNS-ID of www.example.com. 521 Consider an IMAP-accessible email server at the host mail.example.net 522 servicing email addresses of the form user@example.net and 523 discoverable via DNS SRV lookups on the application service name of 524 example.net. A certificate for this service might include SRV-IDs of 525 _imap.example.net and _imaps.example.net (see [EMAIL-SRV]) along with 526 DNS-IDs of example.net and mail.example.net. 528 Consider a SIP-accessible voice-over-IP (VoIP) server at the host 529 voice.example.edu servicing SIP addresses of the form 530 user@voice.example.edu and identified by a URI of 531 . A certificate for this service would 532 include a URI-ID of sip:voice.example.edu (see [SIP-CERTS]) along 533 with a DNS-ID of voice.example.edu. 535 Consider an XMPP-compatible instant messaging (IM) server at the host 536 im.example.org servicing IM addresses of the form user@im.example.org 537 and discoverable via DNS SRV lookups on the im.example.org domain. A 538 certificate for this service might include SRV-IDs of _xmpp- 539 client.im.example.org and _xmpp-server.im.example.org (see [XMPP]), a 540 DNS-ID of im.example.org. For backward compatibility, it may also 541 have an XMPP-specific XmppAddr of im.example.org (see [XMPP]). 543 5. Requesting Server Certificates 545 This section provides instructions for service providers regarding 546 the information to include in certificate signing requests (CSRs). 547 In general, service providers SHOULD request certificates that 548 include all of the identifier types that are required or recommended 549 for the application service type that will be secured using the 550 certificate to be issued. 552 If the certificate will be used for only a single type of application 553 service, the service provider SHOULD request a certificate that 554 includes a DNS-ID and, if appropriate for the application service 555 type, an SRV-ID or URI-ID that limits the deployment scope of the 556 certificate to only the defined application service type. 558 If the certificate might be used for any type of application service, 559 then the service provider SHOULD to request a certificate that 560 includes only a DNS-ID. Again, because of multi-protocol attacks 561 this practice is discouraged; this can be mitigated by providing only 562 one service on a host. 564 If a service provider offersmultiple application service types and 565 wishes to limit the applicability of certificates using SRV-IDs or 566 URI-IDs, they SHOULD request multiple certificates, rather than a 567 single certificate containing multiple SRV-IDs or URI-IDs each 568 identifying ia different application service type. This rule does 569 not apply to application service type "bundles" that identify 570 distinct access methods to the same underlying application such as an 571 email application with access methods denoted by the application 572 service types of imap, imaps, pop3, pop3s, and submission as 573 described in [EMAIL-SRV]. 575 6. Verifying Service Identity 577 At a high level, the client verifies the application service's 578 identity by performing the following actions: 580 1. The client constructs a list of acceptable reference identifiers 581 based on the source domain and, optionally, the type of service 582 to which the client is connecting. 584 2. The server provides its identifiers in the form of a PKIX 585 certificate. 587 3. The client checks each of its reference identifiers against the 588 presented identifiers for the purpose of finding a match. When 589 checking a reference identifier against a presented identifier, 590 the client matches the source domain of the identifiers and, 591 optionally, their application service type. 593 Naturally, in addition to checking identifiers, a client should 594 perform further checks, such as expiration and revocation, to ensure 595 that the server is authorized to provide the requested service. Such 596 checking is not a matter of verifying the application service 597 identity presented in a certificate, however, and methods for doing 598 so are therefore out of scope for this document. 600 6.1. Constructing a List of Reference Identifiers 602 6.1.1. Rules 604 The client MUST construct a list of acceptable reference identifiers, 605 and MUST do so independently of the identifiers presented by the 606 service. 608 The inputs used by the client to construct its list of reference 609 identifiers might be a URI that a user has typed into an interface 610 (e.g., an HTTPS URL for a website), configured account information 611 (e.g., the domain name of a host for retrieving email, which might be 612 different from the DNS domain name portion of a username), a 613 hyperlink in a web page that triggers a browser to retrieve a media 614 object or script, or some other combination of information that can 615 yield a source domain and an application service type. 617 The client might need to extract the source domain and application 618 service type from the input(s) it has received. The extracted data 619 MUST include only information that can be securely parsed out of the 620 inputs, such as parsing the FQDN out of the "host" component or 621 deriving the application service type from the scheme of a URI. 622 Other possibilities include pulling the data from a delegated domain 623 that is explicitly established via client or system configuration, 624 resolving the data via [DNSSEC], or obtaining the data from a third- 625 party domain mapping service in which a human user has explicitly 626 placed trust and with which the client communicates over a connection 627 or association that provides both mutual authentication and integrity 628 checking. These considerations apply only to extraction of the 629 source domain from the inputs. Naturally, if the inputs themselves 630 are invalid or corrupt (e.g., a user has clicked a link provided by a 631 malicious entity in a phishing attack), then the client might end up 632 communicating with an unexpected application service. 634 For example, given an input URI of , a client 635 would derive the application service type sip from the scheme and 636 parse the domain name example.net from the host component. 638 Each reference identifier in the list MUST be based on the source 639 domain and MUST NOT be based on a derived domain such as a domain 640 name discovered through DNS resolution of the source domain. This 641 rule is important because only a match between the user inputs and a 642 presented identifier enables the client to be sure that the 643 certificate can legitimately be used to secure the client's 644 communication with the server. 646 Using the combination of FQDN(s) and application service type, the 647 client MUST construct its list of reference identifiers in accordance 648 with the following rules: 650 * The list SHOULD include a DNS-ID. A reference identifier of type 651 DNS-ID can be directly constructed from a FQDN that is (a) 652 contained in or securely derived from the inputs, or (b) 653 explicitly associated with the source domain by means of user 654 configuration. 656 * If a server for the application service type is typically 657 discovered by means of DNS SRV records, then the list SHOULD 658 include an SRV-ID. 660 * If a server for the application service type is typically 661 associated with a URI for security purposes (i.e., a formal 662 protocol document specifies the use of URIs in server 663 certificates), then the list SHOULD include a URI-ID. 665 Which identifier types a client includes in its list of reference 666 identifiers, and their priority, is a matter of local policy. For 667 example, a client that is built to connect only to a particular kind 668 of service might be configured to accept as valid only certificates 669 that include an SRV-ID for that application service type. By 670 contrast, a more lenient client, even if built to connect only to a 671 particular kind of service, might include both SRV-IDs and DNS-IDs in 672 its list of reference identifiers. 674 6.1.2. Examples 676 A web browser that is connecting via HTTPS to the website at 677 www.example.com would have a single reference identifier: a DNS-ID of 678 www.example.com. 680 A mail user agent that is connecting via IMAPS to the email service 681 at example.net (resolved as mail.example.net) might have three 682 reference identifiers: an SRV-ID of _imaps.example.net (see 683 [EMAIL-SRV]), and DNS-IDs of example.net and mail.example.net. An 684 email user agentthat does not support [EMAIL-SRV] would probably be 685 explicitly configured to connect to mail.example.net, whereas an SRV- 686 aware user agent would derive example.net from an email address of 687 the form user@example.net but might also accept mail.example.net as 688 the DNS domain name portion of reference identifiers for the service. 690 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 691 voice service at voice.example.edu might have only one reference 692 identifier: a URI-ID of sip:voice.example.edu (see [SIP-CERTS]). 694 An instant messaging (IM) client that is connecting via XMPP to the 695 IM service at im.example.org might have three reference identifiers: 696 an SRV-ID of _xmpp-client.im.example.org (see [XMPP]), a DNS-ID of 697 im.example.org, and an XMPP-specific XmppAddr of im.example.org (see 698 [XMPP]). 700 6.2. Preparing to Seek a Match 702 Once the client has constructed its list of reference identifiers and 703 has received the server's presented identifiers in the form of a PKIX 704 certificate, the client checks its reference identifiers against the 705 presented identifiers for the purpose of finding a match. The search 706 fails if the client exhausts its list of reference identifiers 707 without finding a match. The search succeeds if any presented 708 identifier matches one of the reference identifiers, at which point 709 the client SHOULD stop the search. 711 Before applying the comparison rules provided in the following 712 sections, the client might need to split the reference identifier 713 into its DNS domain name portion and its application service type 714 portion, as follows: 716 * A DNS-ID reference identifier MUST be used directly as the DNS 717 domain name and there is no application service type. 719 * For an SRV-ID reference identifier, the DNS domain name portion is 720 the Name and the application service type portion is the Service. 721 For example, an SRV-ID of _imaps.example.net has a DNS domain name 722 portion of example.net and an application service type portion of 723 imaps, which maps to the IMAP application protocol as explained in 724 [EMAIL-SRV]. 726 * For a reference identifier of type URI-ID, the DNS domain name 727 portion is the "reg-name" part of the "host" component and the 728 application service type portion is the scheme, as defind above. 729 Matching only the "reg-name" rule from [URI] limits verification 730 to DNS domain names, thereby differentiating a URI-ID from a 731 uniformResourceIdentifier entry that contains an IP address or a 732 mere host name, or that does not contain a "host" component at 733 all. Furthermore, note that extraction of the "reg-name" might 734 necessitate normalization of the URI (as explained in [URI]). For 735 example, a URI-ID of sip:voice.example.edu would be split into a 736 DNS domain name portion of voice.example.edu and an application 737 service type of sip (associated with an application protocol of 738 SIP as explained in [SIP-CERTS]). 740 A client MUST match the DNS name, and if an application service type 741 is present it MUST also match the service type as well. These are 742 described below. 744 6.3. Matching the DNS Domain Name Portion 746 This section describes how the client must determine if the the 747 presented DNS name matches the reference DNS name. The rules differ 748 depending on whether the domain to be checked is a "traditional 749 domain name" or an "internationalized domain name" (as defined under 750 Section 2). For clients that support names containing the wildcard 751 character "*", this section also specifies a supplemental rule for 752 such "wildcard certificates". This section uses the description of 753 labels and domain names in [DNS-CONCEPTS]. 755 If the DNS domain name portion of a reference identifier is a 756 "traditional domain name", then matching of the reference identifier 757 against the presented identifier MUST be performed by comparing the 758 set of domain name labels using a case-insensitive ASCII comparison, 759 as clarified by [DNS-CASE]. For example, WWW.Example.Com would be 760 lower-cased to www.example.com for comparison purposes. Each label 761 MUST match in order for the names to be considered to match, except 762 as supplemented by the rule about checking of wildcard labels given 763 below. 765 If the DNS domain name portion of a reference identifier is an 766 internationalized domain name, then the client MUST convert any 767 U-labels [IDNA-DEFS] in the domain name to A-labels before checking 768 the domain name. In accordance with [IDNA-PROTO], A-labels MUST be 769 compared as case-insensitive ASCII. Each label MUST match in order 770 for the domain names to be considered to match, except as 771 supplemented by the rule about checking of wildcard labels given 772 below. 774 If the technology specification supports wildcards, then the client 775 MUST match the reference identifier against a presented identifier 776 whose DNS domain name portion contains the wildcard character "*" in 777 a label provided these requirements are met: 779 1. There is only one wildcard character. 781 2. The wildcard character appears only as the content of the left- 782 most label. 784 If the requirements are not met, the presented identifier is invalid 785 and MUST be ignored. 787 A wildcard in a presented identifier can only match exactly one label 788 in a reference identifier. Note that this is not the same as DNS 789 wildcard matching, where the "*" label always matches at least one 790 whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3 791 and [DNS-WILDCARDS]. 793 For information regarding the security characteristics of wildcard 794 certificates, see Section 7.1. 796 6.4. Matching the Application Service Type Portion 798 The rules for matching the application service type deopend on 799 whether the identifier is an SRV-ID or a URI-ID. 801 These identifiers provide an application service type portion to be 802 checked, but that portion is combined only with the DNS domain name 803 portion of the SRV-ID or URI-ID itself. For example, if a client's 804 list of reference identifiers includes an SRV-ID of _xmpp- 805 client.im.example.org and a DNS-ID of apps.example.net, the client 806 would check both the combination of an application service type of 807 xmpp-client and a DNS domain name of im.example.org and a DNS domain 808 name of apps.example.net. However, the client would not check the 809 combination of an application service type of xmpp-client and a DNS 810 domain name of apps.example.net because it does not have an SRV-ID of 811 _xmpp-client.apps.example.net in its list of reference identifiers. 813 If the identifier is an SRV-ID, then the application service name 814 MUST be matched in a case-insensitive manner, in accordance with 815 [DNS-SRV]. Note that the _ character is prepended to the service 816 identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and 817 thus does not need to be included in any comparison. 819 If the identifier is a URI-ID, then the scheme name portion MUST be 820 matched in a case-insensitive manner, in accordance with [URI]. Note 821 that the : character is a separator between the scheme name and the 822 rest of the URI, and thus does not need to be included in any 823 comparison. 825 6.5. Outcome 827 If the client has found a presented identifier that matches a 828 reference identifier, then the service identity check has succeeded. 829 In this case, the client MUST use the matched reference identifier as 830 the validated identity of the application service. 832 If the client does not find a presented identifier matching any of 833 the reference identifiers then the client MUST proceed as described 834 as follows. 836 If the client is an automated application not directly controlled by 837 a human user, then it SHOULD terminate the communication attempt with 838 a bad certificate error and log the error appropriately. The 839 application MAY provide a configuration setting to disable this 840 behavior, but it MUST enable it by default. 842 If the client is an interactive client that is directly controlled by 843 a human user, then it SHOULD inform the user of the identity mismatch 844 and automatically terminate the communication attempt with a bad 845 certificate error in order to prevent users from inadvertently 846 bypassing security protections in hostile situations. 848 Some interactive clients MAY give advanced users the option of 849 proceeding with acceptance despite the identity mismatch. Although 850 this behavior can be appropriate in certain specialized 851 circumstances, it needs to be handled with extreme caution, for 852 example by first encouraging even an advanced user to terminate the 853 communication attempt and, if they choose to proceed anyway, by 854 forcing the user to view the entire certification path before 855 proceeding. 857 The application MAY also present the user with the ability to accept 858 the presented certificate as valid for subsequent connections. Such 859 ad-hoc "pinning" SHOULD NOT restrict future connections to just the 860 pinned certificate. Local policy that statically enforces a given 861 certificate for a given peer is best made available only as prior 862 configuration, rather than a just-in-time override for a failed 863 connection. 865 7. Security Considerations 867 7.1. Wildcard Certificates 869 Wildcard certificates, those that have an identifier with "*" as the 870 left-most DNS label, automatically vouch for any single-label host 871 names within their domain, but not multiple levels of domains. This 872 can be convenient for administrators but also poses the risk of 873 vouching for rogue or buggy hosts. See for example [Defeating-SSL] 874 (beginning at slide 91) and [HTTPSbytes] (slides 38-40). 876 Protection against a wildcard that identifies a public suffix 877 [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of 878 this document. 880 7.2. Internationalized Domain Names 882 Allowing internationalized domain names can lead to visually similar 883 characters, also referred to as "confusables", being included within 884 certificates. For discussion, see for example [IDNA-DEFS], 885 Section 4.4 and [UTS-39]. 887 7.3. Multiple Presented Identifiers 889 A given application service might be addressed by multiple DNS domain 890 names for a variety of reasons, and a given deployment might service 891 multiple domains or protocols. TLS Extensions such as TLS Server 892 Name Identification (SNI), discussed in [TLS], Section 4.4.2.2, and 893 Application Layer Protocol Negotiation (ALPN), discussed in [ALPN], 894 provide a way for the application to indicate the desired identifier 895 and protocol to the server, which can be used to select the most 896 appropriate certificate. 898 To accommodate the workaround that was needed before the development 899 of the SNI extension, this specification allows multiple DNS-IDs, 900 SRV-IDs, or URI-IDs in a certificate. 902 8. IANA Considerations 904 This document has no actions for IANA. 906 9. References 908 9.1. Normative References 910 [DNS-CONCEPTS] 911 Mockapetris, P., "Domain names - concepts and facilities", 912 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 913 . 915 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 916 specifying the location of services (DNS SRV)", RFC 2782, 917 DOI 10.17487/RFC2782, February 2000, 918 . 920 [DNS-WILDCARDS] 921 Lewis, E., "The Role of Wildcards in the Domain Name 922 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 923 . 925 [IDNA-DEFS] 926 Klensin, J., "Internationalized Domain Names for 927 Applications (IDNA): Definitions and Document Framework", 928 RFC 5890, DOI 10.17487/RFC5890, August 2010, 929 . 931 [IDNA-PROTO] 932 Klensin, J., "Internationalized Domain Names in 933 Applications (IDNA): Protocol", RFC 5891, 934 DOI 10.17487/RFC5891, August 2010, 935 . 937 [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 938 (LDAP): String Representation of Distinguished Names", 939 RFC 4514, DOI 10.17487/RFC4514, June 2006, 940 . 942 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 943 Housley, R., and W. Polk, "Internet X.509 Public Key 944 Infrastructure Certificate and Certificate Revocation List 945 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 946 . 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 954 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 955 May 2017, . 957 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 958 Subject Alternative Name for Expression of Service Name", 959 RFC 4985, DOI 10.17487/RFC4985, August 2007, 960 . 962 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 963 Resource Identifier (URI): Generic Syntax", STD 66, 964 RFC 3986, DOI 10.17487/RFC3986, January 2005, 965 . 967 9.2. Informative References 969 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 970 Specifications: ABNF", STD 68, RFC 5234, 971 DOI 10.17487/RFC5234, January 2008, 972 . 974 [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 975 Kasten, "Automatic Certificate Management Environment 976 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 977 . 979 [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., 980 Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, 981 "ALPACA: Application Layer Protocol Confusion - Analyzing 982 and Mitigating Cracks in TLS Authentication", September 983 2021, . 985 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 986 "Transport Layer Security (TLS) Application-Layer Protocol 987 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 988 July 2014, . 990 [Defeating-SSL] 991 Marlinspike, M., "New Tricks for Defeating SSL in 992 Practice", BlackHat DC, February 2009, 993 . 997 [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case 998 Insensitivity Clarification", RFC 4343, 999 DOI 10.17487/RFC4343, January 2006, 1000 . 1002 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1003 Rose, "DNS Security Introduction and Requirements", 1004 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1005 . 1007 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1008 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1009 January 2012, . 1011 [EMAIL-SRV] 1012 Daboo, C., "Use of SRV Records for Locating Email 1013 Submission/Access Services", RFC 6186, 1014 DOI 10.17487/RFC6186, March 2011, 1015 . 1017 [HTTPSbytes] 1018 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1019 Dhabi, November 2010, . 1023 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1024 Part Three: The Domain Name System (DNS) Database", 1025 RFC 3403, DOI 10.17487/RFC3403, October 2002, 1026 . 1028 [NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1029 Sundblad, "Network Time Security for the Network Time 1030 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1031 . 1033 [Public-Suffix] 1034 "Public Suffix List", 2020, . 1036 [QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1037 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1038 . 1040 [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", 1041 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1042 . 1044 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1045 A., Peterson, J., Sparks, R., Handley, M., and E. 1046 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1047 DOI 10.17487/RFC3261, June 2002, 1048 . 1050 [SIP-CERTS] 1051 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1052 Certificates in the Session Initiation Protocol (SIP)", 1053 RFC 5922, DOI 10.17487/RFC5922, June 2010, 1054 . 1056 [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session 1057 Initiation Protocol (SIP)", RFC 5630, 1058 DOI 10.17487/RFC5630, October 2009, 1059 . 1061 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1062 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1063 . 1065 [US-ASCII] American National Standards Institute, "Coded Character 1066 Set - 7-bit American Standard Code for Information 1067 Interchange", ANSI X3.4, 1986. 1069 [UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms", 1070 n.d., . 1072 [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and 1073 Verification of Domain-Based Application Service Identity 1074 within Internet Public Key Infrastructure Using X.509 1075 (PKIX) Certificates in the Context of Transport Layer 1076 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1077 2011, . 1079 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1080 Interface Guidelines", August 2010, 1081 . 1083 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1084 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1085 March 2011, . 1087 Acknowledgements 1089 We gratefully acknowledge everyone who contributed to the previous 1090 version of this document, [VERIFY]. Thanks also to Carsten Bormann 1091 for converting the previous document to Markdown so that we could 1092 more easily use Martin Thomson's i-d-template software. 1094 Authors' Addresses 1096 Peter Saint-Andre 1097 Mozilla 1098 United States of America 1100 Email: stpeter@mozilla.com 1102 Jeff Hodges 1103 Google 1104 United States of America 1106 Email: jdhodges@google.com 1108 Rich Salz 1109 Akamai Technologies 1110 United States of America 1112 Email: rsalz@akamai.com