idnits 2.17.1 draft-ietf-uta-rfc6125bis-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC6125, but the abstract doesn't seem to directly say this. It does mention RFC6125 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 September 2021) is 961 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 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6125 (ref. 'VERIFY') (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 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: 12 March 2022 R. Salz 7 Akamai Technologies 8 8 September 2021 10 Representation and Verification of Domain-Based Application Service 11 Identity within Internet Public Key Infrastructure Using X.509 (PKIX) 12 Certificates in the Context of Transport Layer Security (TLS) 13 draft-ietf-uta-rfc6125bis-02 15 Abstract 17 Many application technologies enable secure communication between two 18 entities by means of Transport Layer Security (TLS) with Internet 19 Public Key Infrastructure Using X.509 (PKIX) certificates. This 20 document specifies procedures for representing and verifying the 21 identity of application services in such interactions. 23 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 12 March 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 4 70 1.4. How to Read This Document . . . . . . . . . . . . . . . . 5 71 1.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 72 1.6. Overview of Recommendations . . . . . . . . . . . . . . . 6 73 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.7.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 7 75 1.7.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 7 76 1.8. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 77 2. Naming of Application Services . . . . . . . . . . . . . . . 12 78 2.1. Naming Application Services . . . . . . . . . . . . . . . 12 79 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13 80 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14 81 3. Designing Application Protocols . . . . . . . . . . . . . . . 14 82 4. Representing Server Identity . . . . . . . . . . . . . . . . 15 83 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 85 5. Requesting Server Certificates . . . . . . . . . . . . . . . 16 86 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 17 87 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Constructing a List of Reference Identifiers . . . . . . 18 89 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 20 91 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 21 92 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 22 93 6.4.1. Checking of Traditional Domain Names . . . . . . . . 22 94 6.4.2. Checking of Internationalized Domain Names . . . . . 22 95 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 23 97 6.5. Matching the Application Service Type Portion . . . . . . 23 98 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 24 99 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 24 100 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 24 102 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 24 103 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 24 104 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 25 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 106 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 25 107 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 26 108 7.3. Internationalized Domain Names . . . . . . . . . . . . . 26 109 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 26 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 112 8.2. Informative References . . . . . . . . . . . . . . . . . 27 113 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 116 1. Introduction 118 1.1. Motivation 120 The visible face of the Internet largely consists of services that 121 employ a client-server architecture in which an interactive or 122 automated client communicates with an application service in order to 123 retrieve or upload information, communicate with other entities, or 124 access a broader network of services. When a client communicates 125 with an application service using Transport Layer Security [TLS] or 126 Datagram Transport Layer Security [DTLS], it references some notion 127 of the server's identity (e.g., "the website at example.com") while 128 attempting to establish secure communication. Likewise, during TLS 129 negotiation, the server presents its notion of the service's identity 130 in the form of a public-key certificate that was issued by a 131 certification authority (CA) in the context of the Internet Public 132 Key Infrastructure using X.509 [PKIX]. Informally, we can think of 133 these identities as the client's "reference identity" and the 134 server's "presented identity" (these rough ideas are defined more 135 precisely later in this document through the concept of particular 136 identifiers). In general, a client needs to verify that the server's 137 presented identity matches its reference identity so it can 138 authenticate the communication. 140 Many application technologies adhere to the pattern just outlined. 141 Such protocols have traditionally specified their own rules for 142 representing and verifying application service identity. 143 Unfortunately, this divergence of approaches has caused some 144 confusion among certification authorities, application developers, 145 and protocol designers. 147 Therefore, to codify secure procedures for the implementation and 148 deployment of PKIX-based authentication, this document specifies 149 recommended procedures for representing and verifying application 150 service identity in certificates intended for use in application 151 protocols employing TLS. 153 1.2. Audience 155 The primary audience for this document consists of application 156 protocol designers, who can reference this document instead of 157 defining their own rules for the representation and verification of 158 application service identity. Secondarily, the audience consists of 159 certification authorities, service providers, and client developers 160 from technology communities that might reuse the recommendations in 161 this document when defining certificate issuance policies, generating 162 certificate signing requests, or writing software algorithms for 163 identity matching. 165 1.3. Changes since RFC 6125 167 This document revises and obsoletes [VERIFY] based on the decade of 168 experience and changes since it was first published. The major 169 changes, in no particular order, include: 171 * All references have been updated to the current latest version. 173 * The TLS SNI extension is no longer new, it is commonplace. 175 * The only legal place for a certificate wildcard name is as the 176 left-most component in a domain name. 178 * It is no longer allowed to use the commonName RDN, known as "CN- 179 ID", to represent the server identity; only the subjectAltNames 180 extension is used. 182 * References to the X.500 directory, the survey of prior art, and 183 the sample text in Appendix A have been removed. 185 1.4. How to Read This Document 187 This document is longer than the authors would have liked because it 188 was necessary to carefully define terminology, explain the underlying 189 concepts, define the scope, and specify recommended behavior for both 190 certification authorities and application software implementations. 191 The following sections are of special interest to various audiences: 193 * Protocol designers might want to first read the checklist in 194 Section 3. 196 * Certification authorities might want to first read the 197 recommendations for representation of server identity in 198 Section 4. 200 * Service providers might want to first read the recommendations for 201 requesting of server certificates in Section 5. 203 * Software implementers might want to first read the recommendations 204 for verification of server identity in Section 6. 206 The sections on terminology (Section 1.8), naming of application 207 services (Section 2), document scope (Section 1.7), and the like 208 provide useful background information regarding the recommendations 209 and guidelines that are contained in the above-referenced sections, 210 but are not absolutely necessary for a first reading of this 211 document. 213 1.5. Applicability 215 This document does not supersede the rules for certificate issuance 216 or validation provided in [PKIX]. Therefore, [PKIX] is authoritative 217 on any point that might also be discussed in this document. 218 Furthermore, [PKIX] also governs any certificate-related topic on 219 which this document is silent, including but not limited to 220 certificate syntax, certificate extensions such as name constraints 221 and extended key usage, and handling of certification paths. 223 This document addresses only name forms in the leaf "end entity" 224 server certificate, not any name forms in the chain of certificates 225 used to validate the server certificate. Therefore, in order to 226 ensure proper authentication, application clients need to verify the 227 entire certification path per [PKIX]. 229 This document also does not supersede the rules for verifying service 230 identity provided in specifications for existing application 231 protocols published prior to this document. However, the procedures 232 described here can be referenced by future specifications, including 233 updates to specifications for existing application protocols if the 234 relevant technology communities agree to do so. 236 1.6. Overview of Recommendations 238 To orient the reader, this section provides an informational overview 239 of the recommendations contained in this document. 241 The previous version of this specification, [VERIFY], surveyed the 242 current practice from many IETF standards and tried to generalize 243 best practices. This document takes the lessons learned in the past 244 decade and codifies them as best practices. 246 For the primary audience of application protocol designers, this 247 document provides recommended procedures for the representation and 248 verification of application service identity within PKIX certificates 249 used in the context of TLS. 251 For the secondary audiences, in essence this document encourages 252 certification authorities, application service providers, and 253 application client developers to coalesce on the following practices: 255 * Stop including and checking strings that look like domain names in 256 the subject's Common Name. 258 * Check DNS domain names via the subjectAlternativeName extension 259 designed for that purpose: dNSName. 261 * Move toward including and checking even more specific 262 subjectAlternativeName extensions where appropriate for using the 263 protocol (e.g., uniformResourceIdentifier and the otherName form 264 SRVName). 266 * Constrain and simplify the validation of wildcard certificates 267 (e.g., a certificate containing an identifier for 268 "*.example.com"). 270 1.7. Scope 271 1.7.1. In Scope 273 This document applies only to service identities associated with 274 fully qualified DNS domain names, only to TLS and DTLS, and only to 275 PKIX-based systems. As a result, the scenarios described in the 276 following section are out of scope for this specification (although 277 they might be addressed by future specifications). 279 1.7.2. Out of Scope 281 The following topics are out of scope for this specification: 283 * Client or end-user identities. 285 Certificates representing client or end-user identities (e.g., the 286 rfc822Name identifier) can be used for mutual authentication 287 between a client and server or between two clients, thus enabling 288 stronger client-server security or end-to-end security. However, 289 certification authorities, application developers, and service 290 operators have less experience with client certificates than with 291 server certificates, thus giving us fewer models from which to 292 generalize and a less solid basis for defining best practices. 294 * Identifiers other than fully qualified DNS domain names. 296 For example, this specification does not discuss IP addresses or 297 other attributes within a certificate beyond the subjectAltName 298 extension. The focus of this document is on application service 299 identities, not specific resources located at such services. 300 Therefore this document discusses Uniform Resource Identifiers 301 [URI] only as a way to communicate a DNS domain name (via the URI 302 "host" component or its equivalent), not as a way to communicate 303 other aspects of a service such as a specific resource (via the 304 URI "path" component) or parameters (via the URI "query" 305 component). 307 * Security protocols other than [TLS] or [DTLS]. 309 Although other secure, lower-layer protocols exist and even employ 310 PKIX certificates at times (e.g., IPsec [IPSEC]), their use cases 311 can differ from those of TLS-based and DTLS-based application 312 technologies. Furthermore, application technologies have less 313 experience with IPsec than with TLS, thus making it more difficult 314 to gather feedback on proposed best practices. 316 * Keys or certificates employed outside the context of PKIX-based 317 systems. 319 Some deployed application technologies use a web of trust model 320 based on or similar to OpenPGP [OPENPGP], or use self-signed 321 certificates, or are deployed on networks that are not directly 322 connected to the public Internet and therefore cannot depend on 323 Certificate Revocation Lists (CRLs) or the Online Certificate 324 Status Protocol [OCSP] to check CA-issued certificates. However, 325 the method for binding a public key to an identifier in OpenPGP 326 differs essentially from the method in X.509, the data in self- 327 signed certificates has not been certified by a third party in any 328 way, and checking of CA-issued certificates via CRLs or OCSP is 329 critically important to maintaining the security of PKIX-based 330 systems. Attempting to define best practices for such 331 technologies would unduly complicate the rules defined in this 332 specification. 334 * Certification authority policies, such as: 336 - What types or "classes" of certificates to issue and whether to 337 apply different policies for them. 339 - Whether to issue certificates based on IP addresses (or some 340 other form, such as relative domain names) in addition to fully 341 qualified DNS domain names. 343 - Which identifiers to include (e.g., whether to include SRV-IDs 344 or URI-IDs as defined in the body of this specification). 346 - How to certify or validate fully qualified DNS domain names and 347 application service types. 349 - How to certify or validate other kinds of information that 350 might be included in a certificate (e.g., organization name). 352 * Resolution of DNS domain names. 354 Although the process whereby a client resolves the DNS domain name 355 of an application service can involve several steps (e.g., this is 356 true of resolutions that depend on DNS SRV resource records, 357 Naming Authority Pointer (NAPTR) DNS resource records [NAPTR], and 358 related technologies such as [S-NAPTR]), for our purposes we care 359 only about the fact that the client needs to verify the identity 360 of the entity with which it communicates as a result of the 361 resolution process. Thus the resolution process itself is out of 362 scope for this specification. 364 * User interface issues. 366 In general, such issues are properly the responsibility of client 367 software developers and standards development organizations 368 dedicated to particular application technologies (see, for 369 example, [WSC-UI]). 371 1.8. Terminology 373 Because many concepts related to "identity" are often too vague to be 374 actionable in application protocols, we define a set of more concrete 375 terms for use in this specification. 377 application service: A service on the Internet that enables 378 interactive and automated clients to connect for the purpose of 379 retrieving or uploading information, communicating with other 380 entities, or connecting to a broader network of services. 382 application service provider: An organization or individual that 383 hosts or deploys an application service. 385 application service type: A formal identifier for the application 386 protocol used to provide a particular kind of application service 387 at a domain; the application service type typically takes the form 388 of a Uniform Resource Identifier scheme [URI] or a DNS SRV Service 389 [DNS-SRV]. 391 automated client: A software agent or device that is not directly 392 controlled by a human user. 394 delegated domain: A domain name or host name that is explicitly 395 configured for communicating with the source domain, by either (a) 396 the human user controlling an interactive client or (b) a trusted 397 administrator. In case (a), one example of delegation is an 398 account setup that specifies the domain name of a particular host 399 to be used for retrieving information or connecting to a network, 400 which might be different from the server portion of the user's 401 account name (e.g., a server at mailhost.example.com for 402 connecting to an IMAP server hosting an email address of 403 juliet@example.com). In case (b), one example of delegation is an 404 admin-configured host-to-address/address-to-host lookup table. 406 derived domain: A domain name or host name that a client has derived 407 from the source domain in an automated fashion (e.g., by means of 408 a [DNS-SRV] lookup). 410 identifier: A particular instance of an identifier type that is 411 either presented by a server in a certificate or referenced by a 412 client for matching purposes. 414 identifier type: A formally defined category of identifier that can 415 be included in a certificate and therefore that can also be used 416 for matching purposes. For conciseness and convenience, we define 417 the following identifier types of interest, which are based on 418 those found in the PKIX specification [PKIX] and various PKIX 419 extensions. 421 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 423 * SRV-ID = a subjectAltName entry of type otherName whose name 424 form is SRVName; see [SRVNAME] 426 * URI-ID = a subjectAltName entry of type 427 uniformResourceIdentifier whose value includes both (i) a 428 "scheme" and (ii) a "host" component (or its equivalent) that 429 matches the "reg-name" rule (where the quoted terms represent 430 the associated [ABNF] productions from [URI]); see [PKIX] and 431 [URI] 433 interactive client: A software agent or device that is directly 434 controlled by a human user. (Other specifications related to 435 security and application protocols, such as [WSC-UI], often refer 436 to this entity as a "user agent".) 438 pinning: The act of establishing a cached name association between 439 the application service's certificate and one of the client's 440 reference identifiers, despite the fact that none of the presented 441 identifiers matches the given reference identifier. Pinning is 442 accomplished by allowing a human user to positively accept the 443 mismatch during an attempt to communicate with the application 444 service. Once a cached name association is established, the 445 certificate is said to be pinned to the reference identifier and 446 in future communication attempts the client simply verifies that 447 the service's presented certificate matches the pinned 448 certificate, as described under Section 6.6.2. (A similar 449 definition of "pinning" is provided in [WSC-UI].) 451 PKIX: PKIX is a short name for the Internet Public Key 452 Infrastructure using X.509 defined in RFC 5280 [PKIX], which 453 comprises a profile of the X.509v3 certificate specifications and 454 X.509v2 certificate revocation list (CRL) specifications for use 455 in the Internet. 457 PKIX-based system: A software implementation or deployed service 458 that makes use of X.509v3 certificates and X.509v2 certificate 459 revocation lists (CRLs). 461 PKIX certificate: An X.509v3 certificate generated and employed in 462 the context of PKIX. 464 presented identifier: An identifier that is presented by a server to 465 a client within a PKIX certificate when the client attempts to 466 establish secure communication with the server; the certificate 467 can include one or more presented identifiers of different types, 468 and if the server hosts more than one domain then the certificate 469 might present distinct identifiers for each domain. 471 reference identifier: An identifier, constructed from a source 472 domain and optionally an application service type, used by the 473 client for matching purposes when examining presented identifiers. 475 Relative Distinguished Name (RDN): The ASN.1-based construction 476 comprising a Relative Distinguished Name (RDN), which itself is a 477 building-block component of Distinguished Names. See [LDAP-DN], 478 Section 2. 480 source domain: The fully qualified DNS domain name that a client 481 expects an application service to present in the certificate 482 (e.g., "www.example.com"), typically input by a human user, 483 configured into a client, or provided by reference such as in a 484 hyperlink. The combination of a source domain and, optionally, an 485 application service type enables a client to construct one or more 486 reference identifiers. 488 subjectAltName entry: An identifier placed in a subjectAltName 489 extension. 491 subjectAltName extension: A standard PKIX certificate extension 492 [PKIX] enabling identifiers of various types to be bound to the 493 certificate subject. 495 subject name: In this specification, the term refers to the name of 496 a PKIX certificate's subject, encoded in a certificate's subject 497 field (see [PKIX], Section 4.1.2.6). 499 TLS client: An entity that assumes the role of a client in a 500 Transport Layer Security [TLS] negotiation. In this specification 501 we generally assume that the TLS client is an (interactive or 502 automated) application client; however, in application protocols 503 that enable server-to-server communication, the TLS client could 504 be a peer application service. 506 TLS server: An entity that assumes the role of a server in a 507 Transport Layer Security [TLS] negotiation; in this specification 508 we assume that the TLS server is an application service. 510 Most security-related terms in this document are to be understood in 511 the sense defined in [SECTERMS]; such terms include, but are not 512 limited to, "attack", "authentication", "authorization", 513 "certification authority", "certification path", "certificate", 514 "credential", "identity", "self-signed certificate", "trust", "trust 515 anchor", "trust chain", "validate", and "verify". 517 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 518 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 519 "OPTIONAL" in this document are to be interpreted as described in 520 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 521 capitals, as shown here. 523 2. Naming of Application Services 525 This section discusses naming of application services on the 526 Internet, followed by a brief tutorial about subject naming in PKIX. 528 2.1. Naming Application Services 530 This specification assumes that the name of an application service is 531 based on a DNS domain name (e.g., "example.com") -- supplemented in 532 some circumstances by an application service type (e.g., "the IMAP 533 server at example.com"). 535 From the perspective of the application client or user, some names 536 are direct because they are provided directly by a human user (e.g., 537 via runtime input, prior configuration, or explicit acceptance of a 538 client communication attempt), whereas other names are indirect 539 because they are automatically resolved by the client based on user 540 input (e.g., a target name resolved from a source name using DNS SRV 541 or NAPTR records). This dimension matters most for certificate 542 consumption, specifically verification as discussed in this document. 544 From the perspective of the application service, some names are 545 unrestricted because they can be used in any type of service (e.g., a 546 certificate might be reused for both the HTTP service and the IMAP 547 service at example.com), whereas other names are restricted because 548 they can be used in only one type of service (e.g., a special-purpose 549 certificate that can be used only for an IMAP service). This 550 dimension matters most for certificate issuance. 552 Therefore, we can categorize the identifier types of interest as 553 follows: 555 * A DNS-ID is direct and unrestricted. 557 * An SRV-ID is typically indirect but can be direct, and is 558 restricted. 560 * A URI-ID is direct and restricted. 562 When implementing software, deploying services, and issuing 563 certificates for secure PKIX-based authentication, it is important to 564 keep these distinctions in mind. In particular, best practices 565 differ somewhat for application server implementations, application 566 client implementations, application service providers, and 567 certification authorities. Ideally, protocol specifications that 568 reference this document will specify which identifiers are mandatory- 569 to-implement by servers and clients, which identifiers ought to be 570 supported by certificate issuers, and which identifiers ought to be 571 requested by application service providers. Because these 572 requirements differ across applications, it is impossible to 573 categorically stipulate universal rules (e.g., that all software 574 implementations, service providers, and certification authorities for 575 all application protocols need to use or support DNS-IDs as a 576 baseline for the purpose of interoperability). 578 However, it is preferable that each application protocol will at 579 least define a baseline that applies to the community of software 580 developers, application service providers, and CAs actively using or 581 supporting that technology (one such community, the CA/Browser Forum, 582 has codified such a baseline for "Extended Validation Certificates" 583 in [EV-CERTS]). 585 2.2. DNS Domain Names 587 For the purposes of this specification, the name of an application 588 service is (or is based on) a DNS domain name that conforms to one of 589 the following forms: 591 1. A "traditional domain name", i.e., a fully qualified DNS domain 592 name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 593 labels" as described in [IDNA-DEFS]. Informally, such labels are 594 constrained to [US-ASCII] letters, digits, and the hyphen, with 595 the hyphen prohibited in the first character position. 596 Additional qualifications apply (please refer to the above- 597 referenced specifications for details), but they are not relevant 598 to this specification. 600 2. An "internationalized domain name", i.e., a DNS domain name that 601 conforms to the overall form of a domain name (informally, dot- 602 separated letter-digit-hyphen labels) but includes at least one 603 label containing appropriately encoded Unicode code points 604 outside the traditional US-ASCII range. That is, it contains at 605 least one U-label or A-label, but otherwise may contain any 606 mixture of NR-LDH labels, A-labels, or U-labels, as described in 607 [IDNA-DEFS] and the associated documents. 609 2.3. Subject Naming in PKIX Certificates 611 For our purposes, an application service can be identified by a name 612 or names carried in one or more of the following identifier types 613 within subjectAltName entries: 615 * DNS-ID 617 * SRV-ID 619 * URI-ID 621 The Common Name RDN MUST NOT be used to identify a service. Reasons 622 for this include: 624 * It is not strongly typed and therefore suffers from ambiguities in 625 interpretation. 627 * It can appear more than once in the Subject Name. 629 For similar reasons, other RDN's within the Subject Name MUST NOT be 630 used to identify a service. 632 3. Designing Application Protocols 634 This section provides guidelines for designers of application 635 protocols, in the form of a checklist to follow when reusing the 636 recommendations provided in this document. 638 * If your technology does not use DNS SRV records to resolve the DNS 639 domain names of application services then consider stating that 640 SRV-ID as defined in this document is not supported. Note that 641 many existing application technologies use DNS SRV records to 642 resolve the DNS domain names of application services, but do not 643 rely on representations of those records in PKIX certificates by 644 means of SRV-IDs as defined in [SRVNAME]. 646 * If your technology does not use use URIs to identify application 647 services, then consider stating that URI-ID as defined in this 648 document is not supported. Note that many existing application 649 technologies use URIs to identify application services, but do not 650 rely on representation of those URIs in PKIX certificates by means 651 of URI-IDs. 653 * If your technology disallows the wildcard character in DNS domain 654 names, then state the wildcard certificates as defined in this 655 document are not supported. 657 4. Representing Server Identity 659 This section provides rules and guidelines for issuers of 660 certificates. 662 4.1. Rules 664 When a certification authority issues a certificate based on the 665 fully qualified DNS domain name at which the application service 666 provider will provide the relevant application, the following rules 667 apply to the representation of application service identities. The 668 reader needs to be aware that some of these rules are cumulative and 669 can interact in important ways that are illustrated later in this 670 document. 672 1. The certificate SHOULD include a "DNS-ID" if possible as a 673 baseline for interoperability. 675 2. If the service using the certificate deploys a technology for 676 which the relevant specification stipulates that certificates 677 ought to include identifiers of type SRV-ID (e.g., this is true 678 of [XMPP]), then the certificate SHOULD include an SRV-ID. 680 3. If the service using the certificate deploys a technology for 681 which the relevant specification stipulates that certificates 682 ought to include identifiers of type URI-ID (e.g., this is true 683 of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] 684 since [HTTP-TLS] does not describe usage of a URI-ID for HTTP 685 services), then the certificate SHOULD include a URI-ID. The 686 scheme SHALL be that of the protocol associated with the 687 application service type and the "host" component (or its 688 equivalent) SHALL be the fully qualified DNS domain name of the 689 service. A specification that reuses this one MUST specify which 690 URI schemes are to be considered acceptable in URI-IDs contained 691 in PKIX certificates used for the application protocol (e.g., 692 "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], 693 or perhaps http and https for HTTP as might be described in a 694 future specification). 696 4. The certificate MAY include other application-specific 697 identifiers for types that were defined before publication of 698 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names 699 or URI schemes do not exist; however, such application-specific 700 identifiers are not applicable to all application technologies 701 and therefore are out of scope for this specification. 703 5. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 704 ID as further explained under Section 7.4. 706 4.2. Examples 708 Consider a simple website at "www.example.com", which is not 709 discoverable via DNS SRV lookups. Because HTTP does not specify the 710 use of URIs in server certificates, a certificate for this service 711 might include only a DNS-ID of "www.example.com". 713 Consider an IMAP-accessible email server at the host 714 "mail.example.net" servicing email addresses of the form 715 "user@example.net" and discoverable via DNS SRV lookups on the 716 application service name of "example.net". A certificate for this 717 service might include SRV-IDs of "_imap.example.net" and 718 "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of 719 "example.net" and "mail.example.net". 721 Consider a SIP-accessible voice-over-IP (VoIP) server at the host 722 "voice.example.edu" servicing SIP addresses of the form 723 "user@voice.example.edu" and identified by a URI of 724 . A certificate for this service would 725 include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along 726 with a DNS-ID of "voice.example.edu". 728 Consider an XMPP-compatible instant messaging (IM) server at the host 729 "im.example.org" servicing IM addresses of the form 730 "user@im.example.org" and discoverable via DNS SRV lookups on the 731 "im.example.org" domain. A certificate for this service might 732 include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- 733 server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", 734 and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). 736 5. Requesting Server Certificates 738 This section provides rules and guidelines for service providers 739 regarding the information to include in certificate signing requests 740 (CSRs). 742 In general, service providers are encouraged to request certificates 743 that include all of the identifier types that are required or 744 recommended for the application service type that will be secured 745 using the certificate to be issued. 747 If the certificate might be used for any type of application service, 748 then the service provider is encouraged to request a certificate that 749 includes only a DNS-ID. 751 If the certificate will be used for only a single type of application 752 service, then the service provider is encouraged to request a 753 certificate that includes a DNS-ID and, if appropriate for the 754 application service type, an SRV-ID or URI-ID that limits the 755 deployment scope of the certificate to only the defined application 756 service type. 758 If a service provider offering multiple application service types 759 (e.g., a World Wide Web service, an email service, and an instant 760 messaging service) wishes to limit the applicability of certificates 761 using SRV-IDs or URI-IDs, then the service provider is encouraged to 762 request multiple certificates, i.e., one certificate per application 763 service type. Conversely, the service provider is discouraged from 764 requesting a single certificate containing multiple SRV-IDs or URI- 765 IDs identifying each different application service type. This 766 guideline does not apply to application service type "bundles" that 767 are used to identify manifold distinct access methods to the same 768 underlying application (e.g., an email application with access 769 methods denoted by the application service types of "imap", "imaps", 770 "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]). 772 6. Verifying Service Identity 774 This section provides rules and guidelines for implementers of 775 application client software regarding algorithms for verification of 776 application service identity. 778 6.1. Overview 780 At a high level, the client verifies the application service's 781 identity by performing the actions listed below (which are defined in 782 the following subsections of this document): 784 1. The client constructs a list of acceptable reference identifiers 785 based on the source domain and, optionally, the type of service 786 to which the client is connecting. 788 2. The server provides its identifiers in the form of a PKIX 789 certificate. 791 3. The client checks each of its reference identifiers against the 792 presented identifiers for the purpose of finding a match. 794 4. When checking a reference identifier against a presented 795 identifier, the client matches the source domain of the 796 identifiers and, optionally, their application service type. 798 Naturally, in addition to checking identifiers, a client might 799 complete further checks to ensure that the server is authorized to 800 provide the requested service. However, such checking is not a 801 matter of verifying the application service identity presented in a 802 certificate, and therefore methods for doing so (e.g., consulting 803 local policy information) are out of scope for this document. 805 6.2. Constructing a List of Reference Identifiers 807 6.2.1. Rules 809 The client MUST construct a list of acceptable reference identifiers, 810 and MUST do so independently of the identifiers presented by the 811 service. 813 The inputs used by the client to construct its list of reference 814 identifiers might be a URI that a user has typed into an interface 815 (e.g., an HTTPS URL for a website), configured account information 816 (e.g., the domain name of a particular host or URI used for 817 retrieving information or connecting to a network, which might be 818 different from the DNS domain name portion of a username), a 819 hyperlink in a web page that triggers a browser to retrieve a media 820 object or script, or some other combination of information that can 821 yield a source domain and an application service type. 823 The client might need to extract the source domain and application 824 service type from the input(s) it has received. The extracted data 825 MUST include only information that can be securely parsed out of the 826 inputs (e.g., parsing the fully qualified DNS domain name out of the 827 "host" component (or its equivalent) of a URI or deriving the 828 application service type from the scheme of a URI) or information 829 that is derived in a manner not subject to subversion by network 830 attackers (e.g., pulling the data from a delegated domain that is 831 explicitly established via client or system configuration, resolving 832 the data via [DNSSEC], or obtaining the data from a third-party 833 domain mapping service in which a human user has explicitly placed 834 trust and with which the client communicates over a connection or 835 association that provides both mutual authentication and integrity 836 checking). These considerations apply only to extraction of the 837 source domain from the inputs; naturally, if the inputs themselves 838 are invalid or corrupt (e.g., a user has clicked a link provided by a 839 malicious entity in a phishing attack), then the client might end up 840 communicating with an unexpected application service. 842 For example, given an input URI of , a client 843 would derive the application service type "sip" from the scheme and 844 parse the domain name "example.net" from the host component. 846 Each reference identifier in the list SHOULD be based on the source 847 domain and SHOULD NOT be based on a derived domain (e.g., a host name 848 or domain name discovered through DNS resolution of the source 849 domain). This rule is important because only a match between the 850 user inputs and a presented identifier enables the client to be sure 851 that the certificate can legitimately be used to secure the client's 852 communication with the server. There is only one scenario in which 853 it is acceptable for an interactive client to override the 854 recommendation in this rule and therefore communicate with a domain 855 name other than the source domain: because a human user has "pinned" 856 the application service's certificate to the alternative domain name 857 as further discussed under Section 6.6.4 and Section 7.1. In this 858 case, the inputs used by the client to construct its list of 859 reference identifiers might include more than one fully qualified DNS 860 domain name, i.e., both (a) the source domain and (b) the alternative 861 domain contained in the pinned certificate. 863 Using the combination of fully qualified DNS domain name(s) and 864 application service type, the client constructs a list of reference 865 identifiers in accordance with the following rules: 867 * The list SHOULD include a DNS-ID. A reference identifier of type 868 DNS-ID can be directly constructed from a fully qualified DNS 869 domain name that is (a) contained in or securely derived from the 870 inputs (i.e., the source domain), or (b) explicitly associated 871 with the source domain by means of user configuration (i.e., a 872 derived domain). 874 * If a server for the application service type is typically 875 discovered by means of DNS SRV records, then the list SHOULD 876 include an SRV-ID. 878 * If a server for the application service type is typically 879 associated with a URI for security purposes (i.e., a formal 880 protocol document specifies the use of URIs in server 881 certificates), then the list SHOULD include a URI-ID. 883 Which identifier types a client includes in its list of reference 884 identifiers is a matter of local policy. For example, in certain 885 deployment environments, a client that is built to connect only to a 886 particular kind of service (e.g., only IM services) might be 887 configured to accept as valid only certificates that include an SRV- 888 ID for that application service type; in this case, the client would 889 include only SRV-IDs matching the application service type in its 890 list of reference identifiers (not, for example, DNS-IDs). By 891 contrast, a more lenient client (even one built to connect only to a 892 particular kind of service) might include both SRV-IDs and DNS-IDs in 893 its list of reference identifiers. 895 6.2.2. Examples 897 A web browser that is connecting via HTTPS to the website at 898 "www.example.com" would have a single reference identifier: a DNS-ID 899 of "www.example.com". 901 A mail user agent that is connecting via IMAPS to the email service 902 at "example.net" (resolved as "mail.example.net") might have three 903 reference identifiers: an SRV-ID of "_imaps.example.net" (see 904 [EMAIL-SRV]), and DNS-IDs of "example.net" and "mail.example.net". 905 (A legacy email user agent would not support [EMAIL-SRV] and 906 therefore would probably be explicitly configured to connect to 907 "mail.example.net", whereas an SRV-aware user agent would derive 908 "example.net" from an email address of the form "user@example.net" 909 but might also accept "mail.example.net" as the DNS domain name 910 portion of reference identifiers for the service.) 912 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 913 voice service at "voice.example.edu" might have only one reference 914 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 916 An instant messaging (IM) client that is connecting via XMPP to the 917 IM service at "im.example.org" might have three reference 918 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), 919 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of 920 "im.example.org" (see [XMPP]). 922 6.3. Preparing to Seek a Match 924 Once the client has constructed its list of reference identifiers and 925 has received the server's presented identifiers in the form of a PKIX 926 certificate, the client checks its reference identifiers against the 927 presented identifiers for the purpose of finding a match. The search 928 fails if the client exhausts its list of reference identifiers 929 without finding a match. The search succeeds if any presented 930 identifier matches one of the reference identifiers, at which point 931 the client SHOULD stop the search. 933 Before applying the comparison rules provided in the following 934 sections, the client might need to split the reference identifier 935 into its DNS domain name portion and its application service type 936 portion, as follows: 938 * A reference identifier of type DNS-ID does not include an 939 application service type portion and thus can be used directly as 940 the DNS domain name for comparison purposes. As an example, a 941 DNS-ID of "www.example.com" would result in a DNS domain name 942 portion of "www.example.com". 944 * For a reference identifier of type SRV-ID, the DNS domain name 945 portion is the Name and the application service type portion is 946 the Service. As an example, an SRV-ID of "_imaps.example.net" 947 would be split into a DNS domain name portion of "example.net" and 948 an application service type portion of "imaps" (mapping to an 949 application protocol of IMAP as explained in [EMAIL-SRV]). 951 * For a reference identifier of type URI-ID, the DNS domain name 952 portion is the "reg-name" part of the "host" component (or its 953 equivalent) and the application service type portion is the 954 application service type associated with the scheme name matching 955 the [ABNF] "scheme" rule from [URI] (not including the ':' 956 separator). As previously mentioned, this document specifies that 957 a URI-ID always contains a "host" component (or its equivalent) 958 containing a "reg-name". (Matching only the "reg-name" rule from 959 [URI] limits verification to DNS domain names, thereby 960 differentiating a URI-ID from a uniformResourceIdentifier entry 961 that contains an IP address or a mere host name, or that does not 962 contain a "host" component at all.) Furthermore, note that 963 extraction of the "reg-name" might necessitate normalization of 964 the URI (as explained in [URI]). As an example, a URI-ID of 965 "sip:voice.example.edu" would be split into a DNS domain name 966 portion of "voice.example.edu" and an application service type of 967 "sip" (associated with an application protocol of SIP as explained 968 in [SIP-CERTS]). 970 Detailed comparison rules for matching the DNS domain name portion 971 and application service type portion of the reference identifier are 972 provided in the following sections. 974 6.4. Matching the DNS Domain Name Portion 976 The client MUST match the DNS domain name portion of a reference 977 identifier according to the following rules (and SHOULD also check 978 the application service type as described under Section 6.5). The 979 rules differ depending on whether the domain to be checked is a 980 "traditional domain name" or an "internationalized domain name" (as 981 defined under Section 2.2). Furthermore, to meet the needs of 982 clients that support presented identifiers containing the wildcard 983 character "*", we define a supplemental rule for such "wildcard 984 certificates". 986 6.4.1. Checking of Traditional Domain Names 988 If the DNS domain name portion of a reference identifier is a 989 "traditional domain name", then matching of the reference identifier 990 against the presented identifier is performed by comparing the set of 991 domain name labels using a case-insensitive ASCII comparison, as 992 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 993 to "www.example.com" for comparison purposes). Each label MUST match 994 in order for the names to be considered to match, except as 995 supplemented by the rule about checking of wildcard labels 996 (Section 6.4.3). 998 6.4.2. Checking of Internationalized Domain Names 1000 If the DNS domain name portion of a reference identifier is an 1001 internationalized domain name, then an implementation MUST convert 1002 any U-labels [IDNA-DEFS] in the domain name to A-labels before 1003 checking the domain name. In accordance with [IDNA-PROTO], A-labels 1004 MUST be compared as case-insensitive ASCII. Each label MUST match in 1005 order for the domain names to be considered to match, except as 1006 supplemented by the rule about checking of wildcard labels 1007 (Section 6.4.3; but see also Section 7.2 regarding wildcards in 1008 internationalized domain names). 1010 6.4.3. Checking of Wildcard Certificates 1012 A client MAY match the reference identifier against a presented 1013 identifier whose DNS domain name portion contains the wildcard 1014 character "*" in a label (following the description of labels and 1015 domain names in [DNS-CONCEPTS]), provided these requirements are met: 1017 1. There is only one wildcard character. 1019 2. The wildcard character appears only as the content of the left- 1020 most label. 1022 3. The wildcard character is not embedded in an A-label or U-label 1023 [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. 1025 A wildcard in a presented identifier can only match exactly one label 1026 in a reference identifier. Note that this is not the same as DNS 1027 wildcard matching, where the "*" label always matches at least one 1028 whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3 1029 and [DNS-WILDCARDS]. 1031 For information regarding the security characteristics of wildcard 1032 certificates, see Section 7.2. 1034 6.5. Matching the Application Service Type Portion 1036 When a client checks identifiers of type SRV-ID and URI-ID, it MUST 1037 check not only the DNS domain name portion of the identifier but also 1038 the application service type portion. The client does this by 1039 splitting the identifier into the DNS domain name portion and the 1040 application service type portion (as described under Section 6.3), 1041 then checking both the DNS domain name portion (as described under 1042 Section 6.4) and the application service type portion as described in 1043 the following subsections. 1045 Implementation Note: An identifier of type SRV-ID or URI-ID provides 1046 an application service type portion to be checked, but that portion 1047 is combined only with the DNS domain name portion of the SRV-ID or 1048 URI-ID itself. For example, if a client's list of reference 1049 identifiers includes an SRV-ID of "_xmpp-client.im.example.org" and a 1050 DNS-ID of "apps.example.net", the client would check (a) the 1051 combination of an application service type of "xmpp-client" and a DNS 1052 domain name of "im.example.org" and (b) a DNS domain name of 1053 "apps.example.net". However, the client would not check (c) the 1054 combination of an application service type of "xmpp-client" and a DNS 1055 domain name of "apps.example.net" because it does not have an SRV-ID 1056 of "_xmpp-client.apps.example.net" in its list of reference 1057 identifiers. 1059 6.5.1. SRV-ID 1061 The application service name portion of an SRV-ID (e.g., "imaps") 1062 MUST be matched in a case-insensitive manner, in accordance with 1063 [DNS-SRV]. Note that the "_" character is prepended to the service 1064 identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and 1065 thus does not need to be included in any comparison. 1067 6.5.2. URI-ID 1069 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1070 a case-insensitive manner, in accordance with [URI]. Note that the 1071 ":" character is a separator between the scheme name and the rest of 1072 the URI, and thus does not need to be included in any comparison. 1074 6.6. Outcome 1076 The outcome of the matching procedure is one of the following cases. 1078 6.6.1. Case #1: Match Found 1080 If the client has found a presented identifier that matches a 1081 reference identifier, then the service identity check has succeeded. 1082 In this case, the client MUST use the matched reference identifier as 1083 the validated identity of the application service. 1085 6.6.2. Case #2: No Match Found, Pinned Certificate 1087 If the client does not find a presented identifier matching any of 1088 the reference identifiers but the client has previously pinned the 1089 application service's certificate to one of the reference identifiers 1090 in the list it constructed for this communication attempt (as 1091 "pinning" is explained under Section 1.8), and the presented 1092 certificate matches the pinned certificate (including the context as 1093 described under Section 7.1), then the service identity check has 1094 succeeded. 1096 6.6.3. Case #3: No Match Found, No Pinned Certificate 1098 If the client does not find a presented identifier matching any of 1099 the reference identifiers and the client has not previously pinned 1100 the certificate to one of the reference identifiers in the list it 1101 constructed for this communication attempt, then the client MUST 1102 proceed as described under Section 6.6.4. 1104 6.6.4. Fallback 1106 If the client is an interactive client that is directly controlled by 1107 a human user, then it SHOULD inform the user of the identity mismatch 1108 and automatically terminate the communication attempt with a bad 1109 certificate error; this behavior is preferable because it prevents 1110 users from inadvertently bypassing security protections in hostile 1111 situations. 1113 Some interactive clients give advanced users the option of proceeding 1114 with acceptance despite the identity mismatch. Although this 1115 behavior can be appropriate in certain specialized circumstances, it 1116 needs to be handled with extreme caution, for example by first 1117 encouraging even an advanced user to terminate the communication 1118 attempt and, if the advanced user chooses to proceed anyway, by 1119 forcing the user to view the entire certification path before 1120 proceeding. 1122 Otherwise, if the client is an automated application not directly 1123 controlled by a human user, then it SHOULD terminate the 1124 communication attempt with a bad certificate error and log the error 1125 appropriately. An automated application MAY provide a configuration 1126 setting that disables this behavior, but MUST enable the behavior by 1127 default. 1129 7. Security Considerations 1131 7.1. Pinned Certificates 1133 As defined under Section 1.8, a certificate is said to be "pinned" to 1134 a DNS domain name when a user has explicitly chosen to associate a 1135 service's certificate with that DNS domain name despite the fact that 1136 the certificate contains some other DNS domain name (e.g., the user 1137 has explicitly approved "apps.example.net" as a domain associated 1138 with a source domain of "example.com"). The cached name association 1139 MUST take account of both the certificate presented and the context 1140 in which it was accepted or configured (where the "context" includes 1141 the chain of certificates from the presented certificate to the trust 1142 anchor, the source domain, the application service type, the 1143 service's derived domain and port number, and any other relevant 1144 information provided by the user or associated by the client). 1146 7.2. Wildcard Certificates 1148 Wildcard certificates, those that have an identifier with "*" as the 1149 left-most DNS label, automatically vouch for any single-label host 1150 names within their domain, but not multiple levels of domains. This 1151 can be convenient for administrators but also poses the risk of 1152 vouching for rogue or buggy hosts. See for example [Defeating-SSL] 1153 (beginning at slide 91) and [HTTPSbytes] (slides 38-40). 1155 Protection against a wildcard that identifies a so-called "public 1156 suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this 1157 document. 1159 7.3. Internationalized Domain Names 1161 Allowing internationalized domain names can lead to the inclusion of 1162 visually similar (so-called "confusable") characters in certificates; 1163 for discussion, see for example [IDNA-DEFS]. 1165 7.4. Multiple Identifiers 1167 A given application service might be addressed by multiple DNS domain 1168 names for a variety of reasons, and a given deployment might service 1169 multiple domains or protocols. The client SHOULD use the TLS Server 1170 Name Identification (SNI) extension as discussed in [TLS], 1171 Section 4.4.2.2. 1173 To accommodate the workaround that was needed before the development 1174 of the SNI extension, this specification allows multiple DNS-IDs, 1175 SRV-IDs, or URI-IDs in a certificate. 1177 8. References 1179 8.1. Normative References 1181 [DNS-CONCEPTS] 1182 Mockapetris, P.V., "Domain names - concepts and 1183 facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1184 November 1987, . 1186 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1187 specifying the location of services (DNS SRV)", RFC 2782, 1188 DOI 10.17487/RFC2782, February 2000, 1189 . 1191 [DNS-WILDCARDS] 1192 Lewis, E., "The Role of Wildcards in the Domain Name 1193 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 1194 . 1196 [IDNA-DEFS] 1197 Klensin, J., "Internationalized Domain Names for 1198 Applications (IDNA): Definitions and Document Framework", 1199 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1200 . 1202 [IDNA-PROTO] 1203 Klensin, J., "Internationalized Domain Names in 1204 Applications (IDNA): Protocol", RFC 5891, 1205 DOI 10.17487/RFC5891, August 2010, 1206 . 1208 [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1209 (LDAP): String Representation of Distinguished Names", 1210 RFC 4514, DOI 10.17487/RFC4514, June 2006, 1211 . 1213 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1214 Housley, R., and W. Polk, "Internet X.509 Public Key 1215 Infrastructure Certificate and Certificate Revocation List 1216 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1217 . 1219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1220 Requirement Levels", BCP 14, RFC 2119, 1221 DOI 10.17487/RFC2119, March 1997, 1222 . 1224 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1225 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1226 May 2017, . 1228 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1229 Subject Alternative Name for Expression of Service Name", 1230 RFC 4985, DOI 10.17487/RFC4985, August 2007, 1231 . 1233 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1234 Resource Identifier (URI): Generic Syntax", STD 66, 1235 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1236 . 1238 8.2. Informative References 1240 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1241 Specifications: ABNF", STD 68, RFC 5234, 1242 DOI 10.17487/RFC5234, January 2008, 1243 . 1245 [Defeating-SSL] 1246 Marlinspike, M., "New Tricks for Defeating SSL in 1247 Practice", BlackHat DC, February 2009, 1248 . 1252 [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case 1253 Insensitivity Clarification", RFC 4343, 1254 DOI 10.17487/RFC4343, January 2006, 1255 . 1257 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1258 Rose, "DNS Security Introduction and Requirements", 1259 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1260 . 1262 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1263 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1264 January 2012, . 1266 [EMAIL-SRV] 1267 Daboo, C., "Use of SRV Records for Locating Email 1268 Submission/Access Services", RFC 6186, 1269 DOI 10.17487/RFC6186, March 2011, 1270 . 1272 [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And 1273 Management Of Extended Validation Certificates", October 1274 2009, . 1276 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1277 Protocol (HTTP/1.1): Message Syntax and Routing", 1278 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1279 . 1281 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, 1282 DOI 10.17487/RFC2818, May 2000, 1283 . 1285 [HTTPSbytes] 1286 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1287 Dhabi, November 2010, . 1291 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1292 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1293 December 2005, . 1295 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1296 Part Three: The Domain Name System (DNS) Database", 1297 RFC 3403, DOI 10.17487/RFC3403, October 2002, 1298 . 1300 [OCSP] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1301 Galperin, S., and C. Adams, "X.509 Internet Public Key 1302 Infrastructure Online Certificate Status Protocol - OCSP", 1303 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1304 . 1306 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1307 Thayer, "OpenPGP Message Format", RFC 4880, 1308 DOI 10.17487/RFC4880, November 2007, 1309 . 1311 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1312 Service Location Using SRV RRs and the Dynamic Delegation 1313 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 1314 January 2005, . 1316 [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", 1317 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1318 . 1320 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1321 A., Peterson, J., Sparks, R., Handley, M., and E. 1322 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1323 DOI 10.17487/RFC3261, June 2002, 1324 . 1326 [SIP-CERTS] 1327 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1328 Certificates in the Session Initiation Protocol (SIP)", 1329 RFC 5922, DOI 10.17487/RFC5922, June 2010, 1330 . 1332 [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session 1333 Initiation Protocol (SIP)", RFC 5630, 1334 DOI 10.17487/RFC5630, October 2009, 1335 . 1337 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1338 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1339 . 1341 [US-ASCII] American National Standards Institute, "Coded Character 1342 Set - 7-bit American Standard Code for Information 1343 Interchange", ANSI X3.4, 1986. 1345 [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and 1346 Verification of Domain-Based Application Service Identity 1347 within Internet Public Key Infrastructure Using X.509 1348 (PKIX) Certificates in the Context of Transport Layer 1349 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1350 2011, . 1352 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1353 Interface Guidelines", World Wide Web Consortium LastCall 1354 WD-wsc-ui-20100309, March 2010, 1355 . 1357 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1358 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1359 March 2011, . 1361 Acknowledgements 1363 We gratefully acknowledge everyone who contributed to the previous 1364 version of this document, [VERIFY]. 1366 Authors' Addresses 1368 Peter Saint-Andre 1369 Mozilla 1370 United States of America 1372 Email: stpeter@mozilla.com 1374 Jeff Hodges 1375 Google 1376 United States of America 1378 Email: jdhodges@google.com 1379 Rich Salz 1380 Akamai Technologies 1381 United States of America 1383 Email: rsalz@akamai.com