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