idnits 2.17.1 draft-ietf-uta-rfc6125bis-05.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 (2 May 2022) is 718 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 4 Obsoletes: 6125 (if approved) J. Hodges 5 Intended status: Standards Track 6 Expires: 3 November 2022 R. Salz 7 Akamai Technologies 8 2 May 2022 10 Service Names in TLS 11 draft-ietf-uta-rfc6125bis-05 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 3 November 2022. 50 Copyright Notice 52 Copyright (c) 2022 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. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 69 1.3. Overview of Recommendations . . . . . . . . . . . . . . . 4 70 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 4 72 1.4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5 73 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 74 2. Naming of Application Services . . . . . . . . . . . . . . . 8 75 3. Designing Application Protocols . . . . . . . . . . . . . . . 10 76 4. Representing Server Identity . . . . . . . . . . . . . . . . 10 77 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5. Requesting Server Certificates . . . . . . . . . . . . . . . 12 80 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 12 81 6.1. Constructing a List of Reference Identifiers . . . . . . 13 82 6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 14 84 6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 15 85 6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 16 86 6.4. Matching the Application Service Type Portion . . . . . . 17 87 6.5. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 18 90 7.2. Internationalized Domain Names . . . . . . . . . . . . . 19 91 7.3. Multiple Presented Identifiers . . . . . . . . . . . . . 19 92 7.4. Multiple Reference Identifiers . . . . . . . . . . . . . 19 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 96 9.2. Informative References . . . . . . . . . . . . . . . . . 21 97 Appendix A. Changes from RFC 6125 . . . . . . . . . . . . . . . 24 98 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 101 1. Introduction 103 1.1. Motivation 105 The visible face of the Internet largely consists of services that 106 employ a client-server architecture in which a client communicates 107 with an application service. When a client communicates with an 108 application service using [TLS], [DTLS], or a protocol built on 109 those, it has some notion of the server's identity (e.g., "the 110 website at example.com") while attempting to establish secure 111 communication. Likewise, during TLS negotiation, the server presents 112 its notion of the service's identity in the form of a public-key 113 certificate that was issued by a certificate authority (CA) in the 114 context of the Internet Public Key Infrastructure using X.509 [PKIX]. 115 Informally, we can think of these identities as the client's 116 "reference identity" and the server's "presented identity"; more 117 formal definitions are given later. A client needs to verify that 118 the server's presented identity matches its reference identity so it 119 can deterministically and automatically authenticate the 120 communication. 122 This document defines procedures for how clients do this 123 verification. It therefore also defines requirements on other 124 parties, such as the certificate authorities that issue certificates, 125 the service administrators requesting them, and the protocol 126 designers defining how things are named. 128 This document obsoletes RFC 6125. Changes from RFC 6125 are 129 described under Appendix A. 131 * Additional text on multiple identifiers, and their security 132 considerations, has been added. 134 1.2. Applicability 136 This document does not supersede the rules for certificate issuance 137 or validation specified by [PKIX]. That document also governs any 138 certificate-related topic on which this document is silent. This 139 includes certificate syntax, extensions such as name constraints or 140 extended key usage, and handling of certification paths. 142 This document addresses only name forms in the leaf "end entity" 143 server certificate. It does not address the name forms in the chain 144 of certificates used to validate a cetrificate, let alone creating or 145 checking the validity of such a chain. In order to ensure proper 146 authentication, applications need to verify the entire certification 147 path as per [PKIX]. 149 1.3. Overview of Recommendations 151 The previous version of this specification, [VERIFY], surveyed the 152 then-current practice from many IETF standards and tried to 153 generalize best practices (see Appendix A [VERIFY] for details). 154 This document takes the lessons learned since then and codifies them. 155 The rules are brief: 157 * Only check DNS domain names via the subjectAlternativeName 158 extension designed for that purpose: dNSName. 160 * Allow use of even more specific subjectAlternativeName extensions 161 where appropriate such as uniformResourceIdentifier and the 162 otherName form SRVName. 164 * Wildcard support is now the default. Constrain wildcard 165 certificates so that the wildcard can only be the complete left- 166 most component of a domain name. 168 * Do not include or check strings that look like domain names in the 169 subject's Common Name. 171 1.4. Scope 173 1.4.1. In Scope 175 This document applies only to service identities that meet these 176 three characteristics: associated with fully-qualified domain names 177 (FQDNs), used with TLS and DTLS, and are PKIX-based. 179 TLS uses the words client and server, where the client is the entity 180 that initiates the connection. In many cases, this is consistent 181 with common practice, such as a browser connecting to a Web origin. 182 For the sake of clarity, and to follow the usage in [TLS] and related 183 specifications, we will continue to use the terms client and server 184 in this document. However, these are TLS-layer roles, and the 185 application protocol could support the TLS server making requests to 186 the TLS client after the TLS handshake; these is no requirement that 187 the roles at the application layer match the TLS layer. 189 At the time of this writing, other protocols such as [QUIC] and 190 Network Time Security ([NTS]) use DTLS or TLS to do the initial 191 establishment of cryptographic key material. The rules specified 192 here apply to such services, as well. 194 1.4.2. Out of Scope 196 The following topics are out of scope for this specification: 198 * Security protocols other than [TLS] or [DTLS] except as described 199 above. 201 * Keys or certificates employed outside the context of PKIX-based 202 systems. 204 * Client or end-user identities. Certificates representing client 205 identities other than as described above, such as rfc822Name, are 206 beyond the scope of this document. 208 * Identifiers other than FQDNs. Identifiers such as IP address are 209 not discussed. In addition, the focus of this document is on 210 application service identities, not specific resources located at 211 such services. Therefore this document discusses Uniform Resource 212 Identifiers [URI] only as a way to communicate a DNS domain name 213 (via the URI "host" component or its equivalent), not other 214 aspects of a service such as a specific resource (via the URI 215 "path" component) or parameters (via the URI "query" component). 217 * Certification authority policies. This includes items such as the 218 following: 220 - How to certify or validate FQDNs and application service types 221 (see [ACME] for some definition of this). 223 - Issuance of certificates with identifiers such as IP addresses 224 instead of or in addition to FQDNs. 226 - Types or "classes" of certificates to issue and whether to 227 apply different policies for them. 229 - How to certify or validate other kinds of information that 230 might be included in a certificate (e.g., organization name). 232 * Resolution of DNS domain names. Although the process whereby a 233 client resolves the DNS domain name of an application service can 234 involve several steps, for our purposes we care only about the 235 fact that the client needs to verify the identity of the entity 236 with which it communicates as a result of the resolution process. 237 Thus the resolution process itself is out of scope for this 238 specification. 240 * User interface issues. In general, such issues are properly the 241 responsibility of client software developers and standards 242 development organizations dedicated to particular application 243 technologies (see, for example, [WSC-UI]). 245 1.5. Terminology 247 Because many concepts related to "identity" are often too vague to be 248 actionable in application protocols, we define a set of more concrete 249 terms for use in this specification. 251 application service: A service on the Internet that enables clients 252 to connect for the purpose of retrieving or uploading information, 253 communicating with other entities, or connecting to a broader 254 network of services. 256 application service provider: An entity that hosts or deploys an 257 application service. 259 application service type: A formal identifier for the application 260 protocol used to provide a particular kind of application service 261 at a domain. This often appears as a URI scheme [URI], DNS SRV 262 Service [DNS-SRV], or an ALPN [ALPN] identifier. 264 delegated domain: A domain name or host name that is explicitly 265 configured for communicating with the source domain, either by the 266 human user controlling the client or by a trusted administrator. 267 For example, a server at mail.example.net could be a delegated 268 domain for connecting to an IMAP server hosting an email address 269 of user@example.net. 271 derived domain: A domain name or host name that a client has derived 272 from the source domain in an automated fashion (e.g., by means of 273 a [DNS-SRV] lookup). 275 identifier: A particular instance of an identifier type that is 276 either presented by a server in a certificate or referenced by a 277 client for matching purposes. 279 identifier type: A formally-defined category of identifier that can 280 be included in a certificate and therefore that can also be used 281 for matching purposes. For conciseness and convenience, we define 282 the following identifier types of interest: 284 * DNS-ID: a subjectAltName entry of type dNSName as defined in 285 [PKIX]. 287 * SRV-ID: a subjectAltName entry of type otherName whose name 288 form is SRVName, as defined in [SRVNAME]. 290 * URI-ID: a subjectAltName entry of type 291 uniformResourceIdentifier as defined in [PKIX]. This entry 292 MUST include both a "scheme" and a "host" component (or its 293 equivalent) that matches the "reg-name" rule (where the quoted 294 terms represent the associated [ABNF] productions from [URI]). 295 If the entry does not have both, it is not a valid URI-ID and 296 MUST be ignored. 298 PKIX: The short name for the Internet Public Key Infrastructure 299 using X.509 defined in [PKIX]. That document provides a profile 300 of the X.509v3 certificate specifications and X.509v2 certificate 301 revocation list (CRL) specifications for use in the Internet. 303 presented identifier: An identifier presented by a server to a 304 client within a PKIX certificate when the client attempts to 305 establish secure communication with the server. The certificate 306 can include one or more presented identifiers of different types, 307 and if the server hosts more than one domain then the certificate 308 might present distinct identifiers for each domain. 310 reference identifier: An identifier used by the client when 311 examining presented identifiers. It is constructed from the 312 source domain, and optionally an application service type. 314 Relative Distinguished Name (RDN): An ASN.1-based construction which 315 itself is a building-block component of Distinguished Names. See 316 [LDAP-DN], Section 2. 318 source domain: The FQDN that a client expects an application service 319 to present in the certificate. This is typically input by a human 320 user, configured into a client, or provided by reference such as a 321 URL. The combination of a source domain and, optionally, an 322 application service type enables a client to construct one or more 323 reference identifiers. 325 subjectAltName entry: An identifier placed in a subjectAltName 326 extension. 328 subjectAltName extension: A standard PKIX extension enabling 329 identifiers of various types to be bound to the certificate 330 subject. 332 subjectName: The name of a PKIX certificate's subject, encoded in a 333 certificate's subject field (see [PKIX], Section 4.1.2.6). 335 Security-related terms used in this document, but not defined here or 336 in [PKIX] should be understood in the the sense defined in 337 [SECTERMS]. Such terms include "attack", "authentication", 338 "identity", "trust", "validate", and "verify". 340 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 341 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 342 "OPTIONAL" in this document are to be interpreted as described in 343 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 344 capitals, as shown here. 346 2. Naming of Application Services 348 This document assumes that the name of an application service is 349 based on a DNS domain name (e.g., example.com) -- supplemented in 350 some circumstances by an application service type (e.g., "the IMAP 351 server at example.net"). The DNS name conforms to one of the 352 following forms: 354 1. A "traditional domain name", i.e., a FQDN (see [DNS-CONCEPTS]) 355 all of whose labels are "LDH labels" as described in [IDNA-DEFS]. 356 Informally, such labels are constrained to [US-ASCII] letters, 357 digits, and the hyphen, with the hyphen prohibited in the first 358 character position. Additional qualifications apply (refer to 359 the above-referenced specifications for details), but they are 360 not relevant here. 362 2. An "internationalized domain name", i.e., a DNS domain name that 363 includes at least one label containing appropriately encoded 364 Unicode code points outside the traditional US-ASCII range. That 365 is, it contains at least one U-label or A-label, but otherwise 366 may contain any mixture of NR-LDH labels, A-labels, or U-labels, 367 as described in [IDNA-DEFS] and the associated documents. 369 From the perspective of the application client or user, some names 370 are _direct_ because they are provided directly by a human user. 371 This includes runtime input, prior configuration, or explicit 372 acceptance of a client communication attempt. Other names are 373 _indirect_ because they are automatically resolved by the application 374 based on user input, such as a target name resolved from a source 375 name using DNS SRV or [NAPTR] records. The distinction matters most 376 for certificate consumption, specifically verification as discussed 377 in this document. 379 From the perspective of the application service, some names are 380 _unrestricted_ because they can be used in any type of service, such 381 as a single certificate being used for both the HTTP and IMAP 382 services at the host example.com. Other names are _restricted_ 383 because they can only be used for one type of service, such as a 384 special-purpose certificate that can only be used for an IMAP 385 service. This distinction matters most for certificate issuance. 387 We can categorize the three identifier types as follows: 389 * A DNS-ID is direct and unrestricted. 391 * An SRV-ID is typically indirect but can be direct, and is 392 restricted. 394 * A URI-ID is direct and restricted. 396 It is important to keep these distinctions in mind, because best 397 practices for the deployment and use of the identifiers differ. Note 398 that cross-protocol attacks such as [ALPACA] are possibile when two 399 different protocol services use the same certificate. This can be 400 addressed by using restricted identifiers, or deploying services so 401 that they do not share certificates. Protocol specifications MUST 402 specify which identifiers are mandatory-to-implement and SHOULD 403 provide operational guidance when necessary. 405 The Common Name RDN MUST NOT be used to identify a service. Reasons 406 for this include: 408 * It is not strongly typed and therefore suffers from ambiguities in 409 interpretation. 411 * It can appear more than once in the subjectName. 413 For similar reasons, other RDN's within the subjectName MUST NOT be 414 used to identify a service. 416 3. Designing Application Protocols 418 This section defines how protocol designers should reference this 419 document, which would typically be a normative reference in their 420 specification. Its specification MAY choose to allow only one of the 421 identifier types defined here. 423 If the technology does not use DNS SRV records to resolve the DNS 424 domain names of application services then its specification MUST 425 state that SRV-ID as defined in this document is not supported. Note 426 that many existing application technologies use DNS SRV records to 427 resolve the DNS domain names of application services, but do not rely 428 on representations of those records in PKIX certificates by means of 429 SRV-IDs as defined in [SRVNAME]. 431 If the technology does not use URIs to identify application services, 432 then its specification MUST state that URI-ID as defined in this 433 document is not supported. Note that many existing application 434 technologies use URIs to identify application services, but do not 435 rely on representation of those URIs in PKIX certificates by means of 436 URI-IDs. 438 A technology MAY disallow the use of the wildcard character in DNS 439 names. If it does so, then the specification MUST state that 440 wildcard certificates as defined in this document are not supported. 442 4. Representing Server Identity 444 This section provides instructions for issuers of certificates. 446 4.1. Rules 448 When a certificate authority issues a certificate based on the FQDN 449 at which the application service provider will provide the relevant 450 application, the following rules apply to the representation of 451 application service identities. Note that some of these rules are 452 cumulative and can interact in important ways that are illustrated 453 later in this document. 455 1. The certificate SHOULD include a "DNS-ID" as a baseline for 456 interoperability. 458 2. If the service using the certificate deploys a technology for 459 which the relevant specification stipulates that certificates 460 ought to include identifiers of type SRV-ID (e.g., [XMPP]), then 461 the certificate SHOULD include an SRV-ID. 463 3. If the service using the certificate deploys a technology for 464 which the relevant specification stipulates that certificates 465 ought to include identifiers of type URI-ID (e.g., [SIP] as 466 specified by [SIP-CERTS]), then the certificate SHOULD include a 467 URI-ID. The scheme MUST be that of the protocol associated with 468 the application service type and the "host" component (or its 469 equivalent) MUST be the FQDN of the service. The application 470 protocol specification MUST specify which URI schemes are 471 acceptable in URI-IDs contained in PKIX certificates used for the 472 application protocol (e.g., sip but not sips or tel for SIP as 473 described in [SIP-SIPS]). 475 4. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 476 ID as further explained under Section 7.3. 478 5. The certificate MAY include other application-specific 479 identifiers for compatibility with a deployed base. Such 480 identifiers are out of scope for this specification. 482 4.2. Examples 484 Consider a simple website at www.example.com, which is not 485 discoverable via DNS SRV lookups. Because HTTP does not specify the 486 use of URIs in server certificates, a certificate for this service 487 might include only a DNS-ID of www.example.com. 489 Consider an IMAP-accessible email server at the host mail.example.net 490 servicing email addresses of the form user@example.net and 491 discoverable via DNS SRV lookups on the application service name of 492 example.net. A certificate for this service might include SRV-IDs of 493 _imap.example.net and _imaps.example.net (see [EMAIL-SRV]) along with 494 DNS-IDs of example.net and mail.example.net. 496 Consider a SIP-accessible voice-over-IP (VoIP) server at the host 497 voice.example.edu servicing SIP addresses of the form 498 user@voice.example.edu and identified by a URI of 499 . A certificate for this service would 500 include a URI-ID of sip:voice.example.edu (see [SIP-CERTS]) along 501 with a DNS-ID of voice.example.edu. 503 Consider an XMPP-compatible instant messaging (IM) server at the host 504 im.example.org servicing IM addresses of the form user@im.example.org 505 and discoverable via DNS SRV lookups on the im.example.org domain. A 506 certificate for this service might include SRV-IDs of _xmpp- 507 client.im.example.org and _xmpp-server.im.example.org (see [XMPP]), a 508 DNS-ID of im.example.org. For backward compatibility, it may also 509 have an XMPP-specific XmppAddr of im.example.org (see [XMPP]). 511 5. Requesting Server Certificates 513 This section provides instructions for service providers regarding 514 the information to include in certificate signing requests (CSRs). 515 In general, service providers SHOULD request certificates that 516 include all of the identifier types that are required or recommended 517 for the application service type that will be secured using the 518 certificate to be issued. 520 If the certificate will be used for only a single type of application 521 service, the service provider SHOULD request a certificate that 522 includes a DNS-ID and, if appropriate for the application service 523 type, an SRV-ID or URI-ID that limits the deployment scope of the 524 certificate to only the defined application service type. 526 If the certificate might be used for any type of application service, 527 then the service provider SHOULD request a certificate that includes 528 only a DNS-ID. Again, because of multi-protocol attacks this 529 practice is discouraged; this can be mitigated by deploying only one 530 service on a host. 532 If a service provider offers multiple application service types and 533 wishes to limit the applicability of certificates using SRV-IDs or 534 URI-IDs, they SHOULD request multiple certificates, rather than a 535 single certificate containing multiple SRV-IDs or URI-IDs each 536 identifying a different application service type. This rule does not 537 apply to application service type "bundles" that identify distinct 538 access methods to the same underlying application such as an email 539 application with access methods denoted by the application service 540 types of imap, imaps, pop3, pop3s, and submission as described in 541 [EMAIL-SRV]. 543 6. Verifying Service Identity 545 At a high level, the client verifies the application service's 546 identity by performing the following actions: 548 1. The client constructs a list of acceptable reference identifiers 549 based on the source domain and, optionally, the type of service 550 to which the client is connecting. 552 2. The server provides its identifiers in the form of a PKIX 553 certificate. 555 3. The client checks each of its reference identifiers against the 556 presented identifiers for the purpose of finding a match. When 557 checking a reference identifier against a presented identifier, 558 the client matches the source domain of the identifiers and, 559 optionally, their application service type. 561 Naturally, in addition to checking identifiers, a client should 562 perform further checks, such as expiration and revocation, to ensure 563 that the server is authorized to provide the requested service. 564 Because such checking is not a matter of verifying the application 565 service identity presented in a certificate, methods for doing so are 566 out of scope for this document. 568 6.1. Constructing a List of Reference Identifiers 570 6.1.1. Rules 572 The client MUST construct a list of acceptable reference identifiers, 573 and MUST do so independently of the identifiers presented by the 574 service. 576 The inputs used by the client to construct its list of reference 577 identifiers might be a URI that a user has typed into an interface 578 (e.g., an HTTPS URL for a website), configured account information 579 (e.g., the domain name of a host for retrieving email, which might be 580 different from the DNS domain name portion of a username), a 581 hyperlink in a web page that triggers a browser to retrieve a media 582 object or script, or some other combination of information that can 583 yield a source domain and an application service type. 585 The client might need to extract the source domain and application 586 service type from the input(s) it has received. The extracted data 587 MUST include only information that can be securely parsed out of the 588 inputs, such as parsing the FQDN out of the "host" component or 589 deriving the application service type from the scheme of a URI. 590 Other possibilities include pulling the data from a delegated domain 591 that is explicitly established via client or system configuration or 592 resolving the data via [DNSSEC]. These considerations apply only to 593 extraction of the source domain from the inputs. Naturally, if the 594 inputs themselves are invalid or corrupt (e.g., a user has clicked a 595 link provided by a malicious entity in a phishing attack), then the 596 client might end up communicating with an unexpected application 597 service. 599 For example, given an input URI of , a client 600 would derive the application service type sip from the scheme and 601 parse the domain name example.net from the host component. 603 Each reference identifier in the list MUST be based on the source 604 domain and MUST NOT be based on a derived domain such as a domain 605 name discovered through DNS resolution of the source domain. This 606 rule is important because only a match between the user inputs and a 607 presented identifier enables the client to be sure that the 608 certificate can legitimately be used to secure the client's 609 communication with the server. This removes DNS and DNS resolution 610 from the attack surface. 612 Using the combination of FQDN(s) and application service type, the 613 client MUST construct its list of reference identifiers in accordance 614 with the following rules: 616 * The list SHOULD include a DNS-ID. A reference identifier of type 617 DNS-ID can be directly constructed from a FQDN that is (a) 618 contained in or securely derived from the inputs, or (b) 619 explicitly associated with the source domain by means of user 620 configuration. 622 * If a server for the application service type is typically 623 discovered by means of DNS SRV records, then the list SHOULD 624 include an SRV-ID. 626 * If a server for the application service type is typically 627 associated with a URI for security purposes (i.e., a formal 628 protocol document specifies the use of URIs in server 629 certificates), then the list SHOULD include a URI-ID. 631 Which identifier types a client includes in its list of reference 632 identifiers, and their priority, is a matter of local policy. For 633 example, a client that is built to connect only to a particular kind 634 of service might be configured to accept as valid only certificates 635 that include an SRV-ID for that application service type. By 636 contrast, a more lenient client, even if built to connect only to a 637 particular kind of service, might include both SRV-IDs and DNS-IDs in 638 its list of reference identifiers. 640 6.1.2. Examples 642 A web browser that is connecting via HTTPS to the website at 643 www.example.com would have a single reference identifier: a DNS-ID of 644 www.example.com. 646 A mail user agent that is connecting via IMAPS to the email service 647 at example.net (resolved as mail.example.net) might have three 648 reference identifiers: an SRV-ID of _imaps.example.net (see 649 [EMAIL-SRV]), and DNS-IDs of example.net and mail.example.net. An 650 email user agent that does not support [EMAIL-SRV] would probably be 651 explicitly configured to connect to mail.example.net, whereas an SRV- 652 aware user agent would derive example.net from an email address of 653 the form user@example.net but might also accept mail.example.net as 654 the DNS domain name portion of reference identifiers for the service. 656 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 657 voice service at voice.example.edu might have only one reference 658 identifier: a URI-ID of sip:voice.example.edu (see [SIP-CERTS]). 660 An instant messaging (IM) client that is connecting via XMPP to the 661 IM service at im.example.org might have three reference identifiers: 662 an SRV-ID of _xmpp-client.im.example.org (see [XMPP]), a DNS-ID of 663 im.example.org, and an XMPP-specific XmppAddr of im.example.org (see 664 [XMPP]). 666 6.2. Preparing to Seek a Match 668 Once the client has constructed its list of reference identifiers and 669 has received the server's presented identifiers, the client checks 670 its reference identifiers against the presented identifiers for the 671 purpose of finding a match. The search fails if the client exhausts 672 its list of reference identifiers without finding a match. The 673 search succeeds if any presented identifier matches one of the 674 reference identifiers, at which point the client SHOULD stop the 675 search. 677 Before applying the comparison rules provided in the following 678 sections, the client might need to split the reference identifier 679 into its DNS domain name portion and its application service type 680 portion, as follows: 682 * A DNS-ID reference identifier MUST be used directly as the DNS 683 domain name and there is no application service type. 685 * For an SRV-ID reference identifier, the DNS domain name portion is 686 the Name and the application service type portion is the Service. 687 For example, an SRV-ID of _imaps.example.net has a DNS domain name 688 portion of example.net and an application service type portion of 689 imaps, which maps to the IMAP application protocol as explained in 690 [EMAIL-SRV]. 692 * For a reference identifier of type URI-ID, the DNS domain name 693 portion is the "reg-name" part of the "host" component and the 694 application service type portion is the scheme, as defined above. 695 Matching only the "reg-name" rule from [URI] limits verification 696 to DNS domain names, thereby differentiating a URI-ID from a 697 uniformResourceIdentifier entry that contains an IP address or a 698 mere host name, or that does not contain a "host" component at 699 all. Furthermore, note that extraction of the "reg-name" might 700 necessitate normalization of the URI (as explained in [URI]). For 701 example, a URI-ID of sip:voice.example.edu would be split into a 702 DNS domain name portion of voice.example.edu and an application 703 service type of sip (associated with an application protocol of 704 SIP as explained in [SIP-CERTS]). 706 A client MUST match the DNS name, and if an application service type 707 is present it MUST also match the service type as well. These are 708 described below. 710 6.3. Matching the DNS Domain Name Portion 712 This section describes how the client must determine if the presented 713 DNS name matches the reference DNS name. The rules differ depending 714 on whether the domain to be checked is a traditional domain name or 715 an internationalized domain name, as defined in Section 2. For 716 clients that support names containing the wildcard character "*", 717 this section also specifies a supplemental rule for such "wildcard 718 certificates". This section uses the description of labels and 719 domain names in [DNS-CONCEPTS]. 721 If the DNS domain name portion of a reference identifier is a 722 traditional domain name, then matching of the reference identifier 723 against the presented identifier MUST be performed by comparing the 724 set of domain name labels using a case-insensitive ASCII comparison, 725 as clarified by [DNS-CASE]. For example, WWW.Example.Com would be 726 lower-cased to www.example.com for comparison purposes. Each label 727 MUST match in order for the names to be considered to match, except 728 as supplemented by the rule about checking of wildcard labels given 729 below. 731 If the DNS domain name portion of a reference identifier is an 732 internationalized domain name, then the client MUST convert any 733 U-labels [IDNA-DEFS] in the domain name to A-labels before checking 734 the domain name. In accordance with [IDNA-PROTO], A-labels MUST be 735 compared as case-insensitive ASCII. Each label MUST match in order 736 for the domain names to be considered to match, except as 737 supplemented by the rule about checking of wildcard labels given 738 below. 740 If the technology specification supports wildcards, then the client 741 MUST match the reference identifier against a presented identifier 742 whose DNS domain name portion contains the wildcard character "*" in 743 a label provided these requirements are met: 745 1. There is only one wildcard character. 747 2. The wildcard character appears only as the complete content of 748 the left-most label. 750 If the requirements are not met, the presented identifier is invalid 751 and MUST be ignored. 753 A wildcard in a presented identifier can only match exactly one label 754 in a reference identifier. Note that this is not the same as DNS 755 wildcard matching, where the "*" label always matches at least one 756 whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3 757 and [DNS-WILDCARDS]. 759 For information regarding the security characteristics of wildcard 760 certificates, see Section 7.1. 762 6.4. Matching the Application Service Type Portion 764 The rules for matching the application service type depend on whether 765 the identifier is an SRV-ID or a URI-ID. 767 These identifiers provide an application service type portion to be 768 checked, but that portion is combined only with the DNS domain name 769 portion of the SRV-ID or URI-ID itself. For example, if a client's 770 list of reference identifiers includes an SRV-ID of _xmpp- 771 client.im.example.org and a DNS-ID of apps.example.net, the client 772 MUST check both the combination of an application service type of 773 xmpp-client and a DNS domain name of im.example.org and a DNS domain 774 name of apps.example.net. However, the client MUST NOT check the 775 combination of an application service type of xmpp-client and a DNS 776 domain name of apps.example.net because it does not have an SRV-ID of 777 _xmpp-client.apps.example.net in its list of reference identifiers. 779 If the identifier is an SRV-ID, then the application service name 780 MUST be matched in a case-insensitive manner, in accordance with 781 [DNS-SRV]. Note that the _ character is prepended to the service 782 identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and 783 thus does not need to be included in any comparison. 785 If the identifier is a URI-ID, then the scheme name portion MUST be 786 matched in a case-insensitive manner, in accordance with [URI]. Note 787 that the : character is a separator between the scheme name and the 788 rest of the URI, and thus does not need to be included in any 789 comparison. 791 6.5. Outcome 793 If the client has found a presented identifier that matches a 794 reference identifier, then the service identity check has succeeded. 795 In this case, the client MUST use the matched reference identifier as 796 the validated identity of the application service. 798 If the client does not find a presented identifier matching any of 799 the reference identifiers, then the client MUST proceed as described 800 as follows. 802 If the client is an automated application, then it SHOULD terminate 803 the communication attempt with a bad certificate error and log the 804 error appropriately. The application MAY provide a configuration 805 setting to disable this behavior, but it MUST enable it by default. 807 If the client is one that is directly controlled by a human user, 808 then it SHOULD inform the user of the identity mismatch and 809 automatically terminate the communication attempt with a bad 810 certificate error in order to prevent users from inadvertently 811 bypassing security protections in hostile situations. Such clients 812 MAY give advanced users the option of proceeding with acceptance 813 despite the identity mismatch. Although this behavior can be 814 appropriate in certain specialized circumstances, it needs to be 815 handled with extreme caution, for example by first encouraging even 816 an advanced user to terminate the communication attempt and, if they 817 choose to proceed anyway, by forcing the user to view the entire 818 certification path before proceeding. 820 The application MAY also present the user with the ability to accept 821 the presented certificate as valid for subsequent connections. Such 822 ad-hoc "pinning" SHOULD NOT restrict future connections to just the 823 pinned certificate. Local policy that statically enforces a given 824 certificate for a given peer SHOULD made available only as prior 825 configuration, rather than a just-in-time override for a failed 826 connection. 828 7. Security Considerations 830 7.1. Wildcard Certificates 832 Wildcard certificates automatically vouch for any single-label host 833 names within their domain, but not multiple levels of domains. This 834 can be convenient for administrators but also poses the risk of 835 vouching for rogue or buggy hosts. See for example [Defeating-SSL] 836 (beginning at slide 91) and [HTTPSbytes] (slides 38-40). 838 Protection against a wildcard that identifies a public suffix 839 [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of 840 this document. 842 7.2. Internationalized Domain Names 844 Allowing internationalized domain names can lead to visually similar 845 characters, also referred to as "confusables", being included within 846 certificates. For discussion, see for example [IDNA-DEFS], 847 Section 4.4 and [UTS-39]. 849 7.3. Multiple Presented Identifiers 851 A given application service might be addressed by multiple DNS domain 852 names for a variety of reasons, and a given deployment might service 853 multiple domains or protocols. TLS Extensions such as TLS Server 854 Name Indication (SNI), discussed in [TLS], Section 4.4.2.2, and 855 Application Layer Protocol Negotiation (ALPN), discussed in [ALPN], 856 provide a way for the application to indicate the desired identifier 857 and protocol to the server, which it can then use to select the most 858 appropriate certificate. 860 This specification allows multiple DNS-IDs, SRV-IDs, or URI-IDs in a 861 certificate. As a result, an application service can use the same 862 certificate for multiple hostnames, such as when a client does not 863 support the TLS SNI extension, or for multiple protocols, such as 864 SMTP and HTTP, on a single hostname. The use of a single certificate 865 and its keypair in such environments can make it easier to launch 866 cross-protocol attacks, particularly when used in inconsistent TLS 867 configurations; see, for example, [ALPACA] and [DROWN]. Server 868 operators SHOULD take steps to mitigate the risk of cross-protocol 869 attacks, such as ensuring all TLS endpoints using a given certificate 870 support exactly the same TLS version(s) and ciphersuite(s), and 871 SHOULD use the TLS ALPN extension to ensure the correct protocol is 872 used. 874 7.4. Multiple Reference Identifiers 876 This specification describes how a client may construct multiple 877 acceptable reference identifiers, and may match any of those 878 reference identifiers with the set of presented identifiers. [PKIX], 879 Section 4.2.1.10 describes a mechanism to allow CA certificates to be 880 constrained in the set of presented identifiers that they may include 881 within server certificates. However, these constraints only apply to 882 the explicitly enumerated name forms. For example, a CA that is only 883 name constrained for DNS-IDs is not constrained for SRV-IDs and URI- 884 IDs, unless those name forms are also explicitly included within the 885 name constraints extension. 887 A client that constructs multiple reference identifiers of different 888 types, such as both DNS-ID and SRV-IDs, as described in 889 Section 6.1.1, SHOULD take care to ensure that CAs issuing such 890 certificates are appropriately constrained. This MAY take the form 891 of local policy through agreement with the issuing CA, or MAY be 892 enforced by the client requiring that if one form of presented 893 identifier is constrained, such as a dNSName name constraint for DNS- 894 IDs, then all other forms of acceptable reference identities are also 895 constrained, such as requiring a uniformResourceIndicator name 896 constraint for URI-IDs. 898 8. IANA Considerations 900 This document has no actions for IANA. 902 9. References 904 9.1. Normative References 906 [DNS-CONCEPTS] 907 Mockapetris, P., "Domain names - concepts and facilities", 908 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 909 . 911 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 912 specifying the location of services (DNS SRV)", RFC 2782, 913 DOI 10.17487/RFC2782, February 2000, 914 . 916 [DNS-WILDCARDS] 917 Lewis, E., "The Role of Wildcards in the Domain Name 918 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 919 . 921 [IDNA-DEFS] 922 Klensin, J., "Internationalized Domain Names for 923 Applications (IDNA): Definitions and Document Framework", 924 RFC 5890, DOI 10.17487/RFC5890, August 2010, 925 . 927 [IDNA-PROTO] 928 Klensin, J., "Internationalized Domain Names in 929 Applications (IDNA): Protocol", RFC 5891, 930 DOI 10.17487/RFC5891, August 2010, 931 . 933 [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 934 (LDAP): String Representation of Distinguished Names", 935 RFC 4514, DOI 10.17487/RFC4514, June 2006, 936 . 938 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 939 Housley, R., and W. Polk, "Internet X.509 Public Key 940 Infrastructure Certificate and Certificate Revocation List 941 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 942 . 944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 945 Requirement Levels", BCP 14, RFC 2119, 946 DOI 10.17487/RFC2119, March 1997, 947 . 949 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 950 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 951 May 2017, . 953 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 954 Subject Alternative Name for Expression of Service Name", 955 RFC 4985, DOI 10.17487/RFC4985, August 2007, 956 . 958 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 959 Resource Identifier (URI): Generic Syntax", STD 66, 960 RFC 3986, DOI 10.17487/RFC3986, January 2005, 961 . 963 9.2. Informative References 965 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 966 Specifications: ABNF", STD 68, RFC 5234, 967 DOI 10.17487/RFC5234, January 2008, 968 . 970 [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 971 Kasten, "Automatic Certificate Management Environment 972 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 973 . 975 [ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., 976 Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, 977 "ALPACA: Application Layer Protocol Confusion - Analyzing 978 and Mitigating Cracks in TLS Authentication", September 979 2021, . 981 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 982 "Transport Layer Security (TLS) Application-Layer Protocol 983 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 984 July 2014, . 986 [Defeating-SSL] 987 Marlinspike, M., "New Tricks for Defeating SSL in 988 Practice", BlackHat DC, February 2009, 989 . 993 [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case 994 Insensitivity Clarification", RFC 4343, 995 DOI 10.17487/RFC4343, January 2006, 996 . 998 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 999 Rose, "DNS Security Introduction and Requirements", 1000 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1001 . 1003 [DROWN] "The DROWN Attack", n.d., . 1005 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1006 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1007 January 2012, . 1009 [EMAIL-SRV] 1010 Daboo, C., "Use of SRV Records for Locating Email 1011 Submission/Access Services", RFC 6186, 1012 DOI 10.17487/RFC6186, March 2011, 1013 . 1015 [HTTPSbytes] 1016 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1017 Dhabi, November 2010, . 1021 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1022 Part Three: The Domain Name System (DNS) Database", 1023 RFC 3403, DOI 10.17487/RFC3403, October 2002, 1024 . 1026 [NTS] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 1027 Sundblad, "Network Time Security for the Network Time 1028 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 1029 . 1031 [Public-Suffix] 1032 "Public Suffix List", 2020, . 1034 [QUIC] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1035 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1036 . 1038 [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", 1039 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1040 . 1042 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1043 A., Peterson, J., Sparks, R., Handley, M., and E. 1044 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1045 DOI 10.17487/RFC3261, June 2002, 1046 . 1048 [SIP-CERTS] 1049 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1050 Certificates in the Session Initiation Protocol (SIP)", 1051 RFC 5922, DOI 10.17487/RFC5922, June 2010, 1052 . 1054 [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session 1055 Initiation Protocol (SIP)", RFC 5630, 1056 DOI 10.17487/RFC5630, October 2009, 1057 . 1059 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1060 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1061 . 1063 [US-ASCII] American National Standards Institute, "Coded Character 1064 Set - 7-bit American Standard Code for Information 1065 Interchange", ANSI X3.4, 1986. 1067 [UTS-39] Davis, M. and M. Suignard, "Unicode Security Mechanisms", 1068 n.d., . 1070 [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and 1071 Verification of Domain-Based Application Service Identity 1072 within Internet Public Key Infrastructure Using X.509 1073 (PKIX) Certificates in the Context of Transport Layer 1074 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1075 2011, . 1077 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1078 Interface Guidelines", August 2010, 1079 . 1081 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1082 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1083 March 2011, . 1085 Appendix A. Changes from RFC 6125 1087 This document revises and obsoletes [VERIFY] based on the decade of 1088 experience and changes since it was published. The major changes, in 1089 no particular order, include: 1091 * The only legal place for a certificate wildcard name is as the 1092 complete left-most component in a domain name. 1094 * The server identity can only be expressed in the subjectAltNames 1095 extension; it is no longer valid to use the commonName RDN, known 1096 as CN-ID in [VERIFY]. 1098 * Detailed discussion of pinning (configuring use of a certificate 1099 that doesn't match the criteria in this document) has been removed 1100 and replaced with two paragraphs in Section 6.5. 1102 * The sections detailing different target audiences and which 1103 sections to read (first) have been removed. 1105 * References to the X.500 directory, the survey of prior art, and 1106 the sample text in Appendix A have been removed. 1108 * All references have been updated to the current latest version. 1110 * The TLS SNI extension is no longer new, it is commonplace. 1112 Acknowledgements 1114 We gratefully acknowledge everyone who contributed to the previous 1115 version of this document, [VERIFY]. Thanks also to Carsten Bormann 1116 for converting the previous document to Markdown so that we could 1117 more easily use Martin Thomson's i-d-template software. 1119 In addition to discussion on the mailing list, the following people 1120 contributed significant changes: Viktor Dukhovni, Jim Fenton, Olle 1121 Johansson, and Ryan Sleevi. 1123 Authors' Addresses 1125 Peter Saint-Andre 1126 United States of America 1127 Email: stpeter@stpeter.im 1129 Jeff Hodges 1130 United States of America 1131 Email: netwerkeddude@gmail.com 1133 Rich Salz 1134 Akamai Technologies 1135 United States of America 1136 Email: rsalz@akamai.com