idnits 2.17.1 draft-ietf-uta-rfc6125bis-01.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 July 2021) is 1023 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6125 (ref. 'VERIFY') (Obsoleted by RFC 9525) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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: 9 January 2022 R. Salz 7 Akamai Technologies 8 8 July 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-01 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 9 January 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. How to Read This Document . . . . . . . . . . . . . . . . 4 70 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 71 1.5. Overview of Recommendations . . . . . . . . . . . . . . . 5 72 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.6.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 6 74 1.6.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 6 75 1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 76 2. Naming of Application Services . . . . . . . . . . . . . . . 12 77 2.1. Naming Application Services . . . . . . . . . . . . . . . 12 78 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . 13 79 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 14 80 3. Designing Application Protocols . . . . . . . . . . . . . . . 15 81 4. Representing Server Identity . . . . . . . . . . . . . . . . 16 82 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 84 5. Requesting Server Certificates . . . . . . . . . . . . . . . 18 85 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 19 86 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 87 6.2. Constructing a List of Reference Identifiers . . . . . . 19 88 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 19 89 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 22 90 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 22 91 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . 24 92 6.4.1. Checking of Traditional Domain Names . . . . . . . . 24 93 6.4.2. Checking of Internationalized Domain Names . . . . . 24 94 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 24 95 6.5. Matching the Application Service Type Portion . . . . . . 25 96 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . 25 97 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . 26 98 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . 26 100 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 26 101 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . 26 102 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . 26 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 104 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 27 105 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 27 106 7.3. Internationalized Domain Names . . . . . . . . . . . . . 28 107 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . 28 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 110 8.2. Informative References . . . . . . . . . . . . . . . . . 29 111 Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . 33 112 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 115 1. Introduction 117 1.1. Motivation 119 The visible face of the Internet largely consists of services that 120 employ a client-server architecture in which an interactive or 121 automated client communicates with an application service in order to 122 retrieve or upload information, communicate with other entities, or 123 access a broader network of services. When a client communicates 124 with an application service using Transport Layer Security [TLS] or 125 Datagram Transport Layer Security [DTLS], it references some notion 126 of the server's identity (e.g., "the website at example.com") while 127 attempting to establish secure communication. Likewise, during TLS 128 negotiation, the server presents its notion of the service's identity 129 in the form of a public-key certificate that was issued by a 130 certification authority (CA) in the context of the Internet Public 131 Key Infrastructure using X.509 [PKIX]. Informally, we can think of 132 these identities as the client's "reference identity" and the 133 server's "presented identity" (these rough ideas are defined more 134 precisely later in this document through the concept of particular 135 identifiers). In general, a client needs to verify that the server's 136 presented identity matches its reference identity so it can 137 authenticate the communication. 139 Many application technologies adhere to the pattern just outlined. 140 Such protocols have traditionally specified their own rules for 141 representing and verifying application service identity. 142 Unfortunately, this divergence of approaches has caused some 143 confusion among certification authorities, application developers, 144 and protocol designers. 146 Therefore, to codify secure procedures for the implementation and 147 deployment of PKIX-based authentication, this document specifies 148 recommended procedures for representing and verifying application 149 service identity in certificates intended for use in application 150 protocols employing TLS. 152 1.2. Audience 154 The primary audience for this document consists of application 155 protocol designers, who can reference this document instead of 156 defining their own rules for the representation and verification of 157 application service identity. Secondarily, the audience consists of 158 certification authorities, service providers, and client developers 159 from technology communities that might reuse the recommendations in 160 this document when defining certificate issuance policies, generating 161 certificate signing requests, or writing software algorithms for 162 identity matching. 164 1.3. How to Read This Document 166 This document is longer than the authors would have liked because it 167 was necessary to carefully define terminology, explain the underlying 168 concepts, define the scope, and specify recommended behavior for both 169 certification authorities and application software implementations. 170 The following sections are of special interest to various audiences: 172 * Protocol designers might want to first read the checklist in 173 Section 3. 175 * Certification authorities might want to first read the 176 recommendations for representation of server identity in 177 Section 4. 179 * Service providers might want to first read the recommendations for 180 requesting of server certificates in Section 5. 182 * Software implementers might want to first read the recommendations 183 for verification of server identity in Section 6. 185 The sections on terminology (Section 1.7), naming of application 186 services (Section 2), document scope (Section 1.6), and the like 187 provide useful background information regarding the recommendations 188 and guidelines that are contained in the above-referenced sections, 189 but are not absolutely necessary for a first reading of this 190 document. 192 1.4. Applicability 194 This document does not supersede the rules for certificate issuance 195 or validation provided in [PKIX]. Therefore, [PKIX] is authoritative 196 on any point that might also be discussed in this document. 197 Furthermore, [PKIX] also governs any certificate-related topic on 198 which this document is silent, including but not limited to 199 certificate syntax, certificate extensions such as name constraints 200 and extended key usage, and handling of certification paths. 202 This document addresses only name forms in the leaf "end entity" 203 server certificate, not any name forms in the chain of certificates 204 used to validate the server certificate. Therefore, in order to 205 ensure proper authentication, application clients need to verify the 206 entire certification path per [PKIX]. 208 This document also does not supersede the rules for verifying service 209 identity provided in specifications for existing application 210 protocols published prior to this document. However, the procedures 211 described here can be referenced by future specifications, including 212 updates to specifications for existing application protocols if the 213 relevant technology communities agree to do so. 215 1.5. Overview of Recommendations 217 To orient the reader, this section provides an informational overview 218 of the recommendations contained in this document. 220 The previous version of this specification, [VERIFY], surveyed the 221 current practice from many IETF standards and tried to generalize 222 best practices. This document takes the lessons learned in the past 223 decade and codifies them as best practices. 225 For the primary audience of application protocol designers, this 226 document provides recommended procedures for the representation and 227 verification of application service identity within PKIX certificates 228 used in the context of TLS. 230 For the secondary audiences, in essence this document encourages 231 certification authorities, application service providers, and 232 application client developers to coalesce on the following practices: 234 * Stop including and checking strings that look like domain names in 235 the subject's Common Name. 237 * Check DNS domain names via the subjectAlternativeName extension 238 designed for that purpose: dNSName. 240 * Move toward including and checking even more specific 241 subjectAlternativeName extensions where appropriate for using the 242 protocol (e.g., uniformResourceIdentifier and the otherName form 243 SRVName). 245 * Constrain and simplify the validation of wildcard certificates 246 (e.g., a certificate containing an identifier for 247 "*.example.com"). 249 1.6. Scope 251 1.6.1. In Scope 253 This document applies only to service identities associated with 254 fully qualified DNS domain names, only to TLS and DTLS (or the older 255 Secure Sockets Layer (SSL) technology), and only to PKIX-based 256 systems. As a result, the scenarios described in the following 257 section are out of scope for this specification (although they might 258 be addressed by future specifications). 260 1.6.2. Out of Scope 262 The following topics are out of scope for this specification: 264 * Client or end-user identities. 266 Certificates representing client or end-user identities (e.g., the 267 rfc822Name identifier) can be used for mutual authentication 268 between a client and server or between two clients, thus enabling 269 stronger client-server security or end-to-end security. However, 270 certification authorities, application developers, and service 271 operators have less experience with client certificates than with 272 server certificates, thus giving us fewer models from which to 273 generalize and a less solid basis for defining best practices. 275 * Identifiers other than fully qualified DNS domain names. 277 Some certification authorities issue server certificates based on 278 IP addresses, but preliminary evidence indicates that such 279 certificates are a very small percentage (less than 1%) of issued 280 certificates. Furthermore, IP addresses are not necessarily 281 reliable identifiers for application services because of the 282 existence of private internets [PRIVATE], host mobility, multiple 283 interfaces on a given host, Network Address Translators (NATs) 284 resulting in different addresses for a host from different 285 locations on the network, the practice of grouping many hosts 286 together behind a single IP address, etc. Most fundamentally, 287 most users find DNS domain names much easier to work with than IP 288 addresses, which is why the domain name system was designed in the 289 first place. We prefer to define best practices for the much more 290 common use case and not to complicate the rules in this 291 specification. 293 Furthermore, we focus here on application service identities, not 294 specific resources located at such services. Therefore this 295 document discusses Uniform Resource Identifiers [URI] only as a 296 way to communicate a DNS domain name (via the URI "host" component 297 or its equivalent), not as a way to communicate other aspects of a 298 service such as a specific resource (via the URI "path" component) 299 or parameters (via the URI "query" component). 301 We also do not discuss attributes unrelated to DNS domain names, 302 such as those defined in [X.520] and other such specifications 303 (e.g., organizational attributes, geographical attributes, company 304 logos, and the like). 306 * Security protocols other than [TLS], [DTLS], or the older Secure 307 Sockets Layer (SSL) technology. 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.7. 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 attribute-type-and-value pair: A colloquial name for the ASN.1-based 392 construction comprising a Relative Distinguished Name (RDN), which 393 itself is a building-block component of Distinguished Names. See 394 Section 2 of [LDAP-DN]. 396 automated client: A software agent or device that is not directly 397 controlled by a human user. 399 delegated domain: A domain name or host name that is explicitly 400 configured for communicating with the source domain, by either (a) 401 the human user controlling an interactive client or (b) a trusted 402 administrator. In case (a), one example of delegation is an 403 account setup that specifies the domain name of a particular host 404 to be used for retrieving information or connecting to a network, 405 which might be different from the server portion of the user's 406 account name (e.g., a server at mailhost.example.com for 407 connecting to an IMAP server hosting an email address of 408 juliet@example.com). In case (b), one example of delegation is an 409 admin-configured host-to-address/address-to-host lookup table. 411 derived domain: A domain name or host name that a client has derived 412 from the source domain in an automated fashion (e.g., by means of 413 a [DNS-SRV] lookup). 415 identifier: A particular instance of an identifier type that is 416 either presented by a server in a certificate or referenced by a 417 client for matching purposes. 419 identifier type: A formally defined category of identifier that can 420 be included in a certificate and therefore that can also be used 421 for matching purposes. For conciseness and convenience, we define 422 the following identifier types of interest, which are based on 423 those found in the PKIX specification [PKIX] and various PKIX 424 extensions. 426 * DNS-ID = a subjectAltName entry of type dNSName; see [PKIX] 428 * SRV-ID = a subjectAltName entry of type otherName whose name 429 form is SRVName; see [SRVNAME] 431 * URI-ID = a subjectAltName entry of type 432 uniformResourceIdentifier whose value includes both (i) a 433 "scheme" and (ii) a "host" component (or its equivalent) that 434 matches the "reg-name" rule (where the quoted terms represent 435 the associated [ABNF] productions from [URI]); see [PKIX] and 436 [URI] 438 interactive client: A software agent or device that is directly 439 controlled by a human user. (Other specifications related to 440 security and application protocols, such as [WSC-UI], often refer 441 to this entity as a "user agent".) 443 pinning: The act of establishing a cached name association between 444 the application service's certificate and one of the client's 445 reference identifiers, despite the fact that none of the presented 446 identifiers matches the given reference identifier. Pinning is 447 accomplished by allowing a human user to positively accept the 448 mismatch during an attempt to communicate with the application 449 service. Once a cached name association is established, the 450 certificate is said to be pinned to the reference identifier and 451 in future communication attempts the client simply verifies that 452 the service's presented certificate matches the pinned 453 certificate, as described under Section 6.6.2. (A similar 454 definition of "pinning" is provided in [WSC-UI].) 456 PKIX: PKIX is a short name for the Internet Public Key 457 Infrastructure using X.509 defined in RFC 5280 [PKIX], which 458 comprises a profile of the X.509v3 certificate specifications and 459 X.509v2 certificate revocation list (CRL) specifications for use 460 in the Internet. 462 PKIX-based system: A software implementation or deployed service 463 that makes use of X.509v3 certificates and X.509v2 certificate 464 revocation lists (CRLs). 466 PKIX certificate: An X.509v3 certificate generated and employed in 467 the context of PKIX. 469 presented identifier: An identifier that is presented by a server to 470 a client within a PKIX certificate when the client attempts to 471 establish secure communication with the server; the certificate 472 can include one or more presented identifiers of different types, 473 and if the server hosts more than one domain then the certificate 474 might present distinct identifiers for each domain. 476 reference identifier: An identifier, constructed from a source 477 domain and optionally an application service type, used by the 478 client for matching purposes when examining presented identifiers. 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 -- in addition to, or in place of, identifiers 494 that may be embedded within or provided as a certificate's subject 495 field. 497 subject field: The subject field of a PKIX certificate identifies 498 the entity associated with the public key stored in the subject 499 public key field (see Section 4.1.2.6 of [PKIX]). 501 subject name: In an overall sense, a subject's name(s) can be 502 represented by or in the subject field, the subjectAltName 503 extension, or both (see [PKIX] for details). More specifically, 504 the term often refers to the name of a PKIX certificate's subject, 505 encoded as the X.501 type Name and conveyed in a certificate's 506 subject field (see Section 4.1.2.6 of [PKIX]). 508 TLS client: An entity that assumes the role of a client in a 509 Transport Layer Security [TLS] negotiation. In this specification 510 we generally assume that the TLS client is an (interactive or 511 automated) application client; however, in application protocols 512 that enable server-to-server communication, the TLS client could 513 be a peer application service. 515 TLS server: An entity that assumes the role of a server in a 516 Transport Layer Security [TLS] negotiation; in this specification 517 we assume that the TLS server is an application service. 519 Most security-related terms in this document are to be understood in 520 the sense defined in [SECTERMS]; such terms include, but are not 521 limited to, "attack", "authentication", "authorization", 522 "certification authority", "certification path", "certificate", 523 "credential", "identity", "self-signed certificate", "trust", "trust 524 anchor", "trust chain", "validate", and "verify". 526 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 527 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 528 "OPTIONAL" in this document are to be interpreted as described in 529 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 530 capitals, as shown here. 532 2. Naming of Application Services 534 This section discusses naming of application services on the 535 Internet, followed by a brief tutorial about subject naming in PKIX. 537 2.1. Naming Application Services 539 This specification assumes that the name of an application service is 540 based on a DNS domain name (e.g., "example.com") -- supplemented in 541 some circumstances by an application service type (e.g., "the IMAP 542 server at example.com"). 544 From the perspective of the application client or user, some names 545 are direct because they are provided directly by a human user (e.g., 546 via runtime input, prior configuration, or explicit acceptance of a 547 client communication attempt), whereas other names are indirect 548 because they are automatically resolved by the client based on user 549 input (e.g., a target name resolved from a source name using DNS SRV 550 or NAPTR records). This dimension matters most for certificate 551 consumption, specifically verification as discussed in this document. 553 From the perspective of the application service, some names are 554 unrestricted because they can be used in any type of service (e.g., a 555 certificate might be reused for both the HTTP service and the IMAP 556 service at example.com), whereas other names are restricted because 557 they can be used in only one type of service (e.g., a special-purpose 558 certificate that can be used only for an IMAP service). This 559 dimension matters most for certificate issuance. 561 Therefore, we can categorize the identifier types of interest as 562 follows: 564 * A DNS-ID is direct and unrestricted. 566 * An SRV-ID can be either direct or (more typically) indirect, and 567 is restricted. 569 * A URI-ID is direct and restricted. 571 We summarize this taxonomy in the following table. 573 +-----------+-----------+---------------+ 574 | | Direct | Restricted | 575 +-----------+-----------+---------------+ 576 | DNS-ID | Yes | No | 577 +-----------+-----------+---------------+ 578 | SRV-ID | Either | Yes | 579 +-----------+-----------+---------------+ 580 | URI-ID | Yes | Yes | 581 +-----------+-----------+---------------+ 583 When implementing software, deploying services, and issuing 584 certificates for secure PKIX-based authentication, it is important to 585 keep these distinctions in mind. In particular, best practices 586 differ somewhat for application server implementations, application 587 client implementations, application service providers, and 588 certification authorities. Ideally, protocol specifications that 589 reference this document will specify which identifiers are mandatory- 590 to-implement by servers and clients, which identifiers ought to be 591 supported by certificate issuers, and which identifiers ought to be 592 requested by application service providers. Because these 593 requirements differ across applications, it is impossible to 594 categorically stipulate universal rules (e.g., that all software 595 implementations, service providers, and certification authorities for 596 all application protocols need to use or support DNS-IDs as a 597 baseline for the purpose of interoperability). 599 However, it is preferable that each application protocol will at 600 least define a baseline that applies to the community of software 601 developers, application service providers, and CAs actively using or 602 supporting that technology (one such community, the CA/Browser Forum, 603 has codified such a baseline for "Extended Validation Certificates" 604 in [EV-CERTS]). 606 2.2. DNS Domain Names 608 For the purposes of this specification, the name of an application 609 service is (or is based on) a DNS domain name that conforms to one of 610 the following forms: 612 1. A "traditional domain name", i.e., a fully qualified DNS domain 613 name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH 614 labels" as described in [IDNA-DEFS]. Informally, such labels are 615 constrained to [US-ASCII] letters, digits, and the hyphen, with 616 the hyphen prohibited in the first character position. 617 Additional qualifications apply (please refer to the above- 618 referenced specifications for details), but they are not relevant 619 to this specification. 621 2. An "internationalized domain name", i.e., a DNS domain name that 622 conforms to the overall form of a domain name (informally, dot- 623 separated letter-digit-hyphen labels) but includes at least one 624 label containing appropriately encoded Unicode code points 625 outside the traditional US-ASCII range. That is, it contains at 626 least one U-label or A-label, but otherwise may contain any 627 mixture of NR-LDH labels, A-labels, or U-labels, as described in 628 [IDNA-DEFS] and the associated documents. 630 2.3. Subject Naming in PKIX Certificates 632 In theory, the Internet Public Key Infrastructure using X.509 [PKIX] 633 employs the global directory service model defined in [X.500] and 634 [X.501]. Under that model, information is held in a directory 635 information base (DIB) and entries in the DIB are organized in a 636 hierarchy called the directory information tree (DIT). An object or 637 alias entry in that hierarchy consists of a set of attributes (each 638 of which has a defined type and one or more values) and is uniquely 639 identified by a Distinguished Name (DN). The DN of an entry is 640 constructed by combining the Relative Distinguished Names of its 641 superior entries in the tree (all the way down to the root of the 642 DIT) with one or more specially nominated attributes of the entry 643 itself (which together comprise the Relative Distinguished Name (RDN) 644 of the entry, so-called because it is relative to the Distinguished 645 Names of the superior entries in the tree). The entry closest to the 646 root is sometimes referred to as the "most significant" entry, and 647 the entry farthest from the root is sometimes referred to as the 648 "least significant" entry. An RDN is a set (i.e., an unordered 649 group) of attribute-type-and-value pairs (see also [LDAP-DN]), each 650 of which asserts some attribute about the entry. 652 In practice, the certificates used in [X.509] and [PKIX] borrow key 653 concepts from X.500 and X.501 (e.g., DNs and RDNs) to identify 654 entities, but such certificates are not necessarily part of a global 655 directory information base. Specifically, the subject field of a 656 PKIX certificate is an X.501 type Name that "identifies the entity 657 associated with the public key stored in the subject public key 658 field" (see Section 4.1.2.6 of [PKIX]). However, it is perfectly 659 acceptable for the subject field to be empty, as long as the 660 certificate contains a subject alternative name ("subjectAltName") 661 extension that includes at least one subjectAltName entry, because 662 the subjectAltName extension allows various identities to be bound to 663 the subject (see Section 4.2.1.6 of [PKIX]). The subjectAltName 664 extension itself is a sequence of typed entries, where each type is a 665 distinct kind of identifier. 667 For our purposes, an application service can be identified by a name 668 or names carried in one or more of the following identifier types 669 within subjectAltName entries: 671 * DNS-ID 673 * SRV-ID 675 * URI-ID 677 The Common Name RDN should not be used to identify a service. 678 Reasons for this include: 680 * It is not strongly typed and therefore suffers from ambiguities in 681 interpretation. 683 * It can appear more than once in the Subject Name. 685 Likewise, other RDN's within the Subject Name SHOULD NOT be used to 686 identify a service. 688 3. Designing Application Protocols 690 This section provides guidelines for designers of application 691 protocols, in the form of a checklist to follow when reusing the 692 recommendations provided in this document. 694 * Does your technology use DNS SRV records to resolve the DNS domain 695 names of application services? If so, consider recommending or 696 requiring support for the SRV-ID identifier type in PKIX 697 certificates issued and used in your technology community. (Note 698 that many existing application technologies use DNS SRV records to 699 resolve the DNS domain names of application services, but do not 700 rely on representations of those records in PKIX certificates by 701 means of SRV-IDs as defined in [SRVNAME].) 703 * Does your technology use URIs to identify application services? 704 If so, consider recommending or requiring support for the URI-ID 705 identifier type. (Note that many existing application 706 technologies use URIs to identify application services, but do not 707 rely on representation of those URIs in PKIX certificates by means 708 of URI-IDs.) 710 * Does your technology need to allow the wildcard character in DNS 711 domain names? If so, consider recommending support for wildcard 712 certificates, and specify exactly where the wildcard character is 713 allowed to occur (e.g., only the complete left-most label of a DNS 714 domain name). 716 Sample text is provided under Appendix A. 718 4. Representing Server Identity 720 This section provides rules and guidelines for issuers of 721 certificates. 723 4.1. Rules 725 When a certification authority issues a certificate based on the 726 fully qualified DNS domain name at which the application service 727 provider will provide the relevant application, the following rules 728 apply to the representation of application service identities. The 729 reader needs to be aware that some of these rules are cumulative and 730 can interact in important ways that are illustrated later in this 731 document. 733 1. The certificate SHOULD include a "DNS-ID" if possible as a 734 baseline for interoperability. 736 2. If the service using the certificate deploys a technology for 737 which the relevant specification stipulates that certificates 738 ought to include identifiers of type SRV-ID (e.g., this is true 739 of [XMPP]), then the certificate SHOULD include an SRV-ID. 741 3. If the service using the certificate deploys a technology for 742 which the relevant specification stipulates that certificates 743 ought to include identifiers of type URI-ID (e.g., this is true 744 of [SIP] as specified by [SIP-CERTS], but not true of [HTTP] 745 since [HTTP-TLS] does not describe usage of a URI-ID for HTTP 746 services), then the certificate SHOULD include a URI-ID. The 747 scheme SHALL be that of the protocol associated with the 748 application service type and the "host" component (or its 749 equivalent) SHALL be the fully qualified DNS domain name of the 750 service. A specification that reuses this one MUST specify which 751 URI schemes are to be considered acceptable in URI-IDs contained 752 in PKIX certificates used for the application protocol (e.g., 753 "sip" but not "sips" or "tel" for SIP as described in [SIP-SIPS], 754 or perhaps http and https for HTTP as might be described in a 755 future specification). 757 4. The certificate MAY include other application-specific 758 identifiers for types that were defined before publication of 759 [SRVNAME] (e.g., XmppAddr for [XMPP]) or for which service names 760 or URI schemes do not exist; however, such application-specific 761 identifiers are not applicable to all application technologies 762 and therefore are out of scope for this specification. 764 5. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 765 ID as further explained under Section 7.4. 767 6. Unless a specification that reuses this one allows continued 768 support for the wildcard character "*", the DNS domain name 769 portion of a presented identifier SHOULD NOT contain the wildcard 770 character, whether as the complete left-most label within the 771 identifier (following the description of labels and domain names 772 in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment 773 thereof (e.g., "*oo.example.com", "f*o.example.com", or 774 "fo*.example.com"). A more detailed discussion of so-called 775 "wildcard certificates" is provided under Section 7.2. 777 4.2. Examples 779 Consider a simple website at "www.example.com", which is not 780 discoverable via DNS SRV lookups. Because HTTP does not specify the 781 use of URIs in server certificates, a certificate for this service 782 might include only a DNS-ID of "www.example.com". 784 Consider an IMAP-accessible email server at the host 785 "mail.example.net" servicing email addresses of the form 786 "user@example.net" and discoverable via DNS SRV lookups on the 787 application service name of "example.net". A certificate for this 788 service might include SRV-IDs of "_imap.example.net" and 789 "_imaps.example.net" (see [EMAIL-SRV]) along with DNS-IDs of 790 "example.net" and "mail.example.net". 792 Consider a SIP-accessible voice-over-IP (VoIP) server at the host 793 "voice.example.edu" servicing SIP addresses of the form 794 "user@voice.example.edu" and identified by a URI of 795 . A certificate for this service would 796 include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]) along 797 with a DNS-ID of "voice.example.edu". 799 Consider an XMPP-compatible instant messaging (IM) server at the host 800 "im.example.org" servicing IM addresses of the form 801 "user@im.example.org" and discoverable via DNS SRV lookups on the 802 "im.example.org" domain. A certificate for this service might 803 include SRV-IDs of "_xmpp-client.im.example.org" and "_xmpp- 804 server.im.example.org" (see [XMPP]), a DNS-ID of "im.example.org", 805 and an XMPP-specific "XmppAddr" of "im.example.org" (see [XMPP]). 807 5. Requesting Server Certificates 809 This section provides rules and guidelines for service providers 810 regarding the information to include in certificate signing requests 811 (CSRs). 813 In general, service providers are encouraged to request certificates 814 that include all of the identifier types that are required or 815 recommended for the application service type that will be secured 816 using the certificate to be issued. 818 If the certificate might be used for any type of application service, 819 then the service provider is encouraged to request a certificate that 820 includes only a DNS-ID. 822 If the certificate will be used for only a single type of application 823 service, then the service provider is encouraged to request a 824 certificate that includes a DNS-ID and, if appropriate for the 825 application service type, an SRV-ID or URI-ID that limits the 826 deployment scope of the certificate to only the defined application 827 service type. 829 If a service provider offering multiple application service types 830 (e.g., a World Wide Web service, an email service, and an instant 831 messaging service) wishes to limit the applicability of certificates 832 using SRV-IDs or URI-IDs, then the service provider is encouraged to 833 request multiple certificates, i.e., one certificate per application 834 service type. Conversely, the service provider is discouraged from 835 requesting a single certificate containing multiple SRV-IDs or URI- 836 IDs identifying each different application service type. This 837 guideline does not apply to application service type "bundles" that 838 are used to identify manifold distinct access methods to the same 839 underlying application (e.g., an email application with access 840 methods denoted by the application service types of "imap", "imaps", 841 "pop3", "pop3s", and "submission" as described in [EMAIL-SRV]). 843 6. Verifying Service Identity 845 This section provides rules and guidelines for implementers of 846 application client software regarding algorithms for verification of 847 application service identity. 849 6.1. Overview 851 At a high level, the client verifies the application service's 852 identity by performing the actions listed below (which are defined in 853 the following subsections of this document): 855 1. The client constructs a list of acceptable reference identifiers 856 based on the source domain and, optionally, the type of service 857 to which the client is connecting. 859 2. The server provides its identifiers in the form of a PKIX 860 certificate. 862 3. The client checks each of its reference identifiers against the 863 presented identifiers for the purpose of finding a match. 865 4. When checking a reference identifier against a presented 866 identifier, the client matches the source domain of the 867 identifiers and, optionally, their application service type. 869 Naturally, in addition to checking identifiers, a client might 870 complete further checks to ensure that the server is authorized to 871 provide the requested service. However, such checking is not a 872 matter of verifying the application service identity presented in a 873 certificate, and therefore methods for doing so (e.g., consulting 874 local policy information) are out of scope for this document. 876 6.2. Constructing a List of Reference Identifiers 878 6.2.1. Rules 880 The client MUST construct a list of acceptable reference identifiers, 881 and MUST do so independently of the identifiers presented by the 882 service. 884 The inputs used by the client to construct its list of reference 885 identifiers might be a URI that a user has typed into an interface 886 (e.g., an HTTPS URL for a website), configured account information 887 (e.g., the domain name of a particular host or URI used for 888 retrieving information or connecting to a network, which might be 889 different from the DNS domain name portion of a username), a 890 hyperlink in a web page that triggers a browser to retrieve a media 891 object or script, or some other combination of information that can 892 yield a source domain and an application service type. 894 The client might need to extract the source domain and application 895 service type from the input(s) it has received. The extracted data 896 MUST include only information that can be securely parsed out of the 897 inputs (e.g., parsing the fully qualified DNS domain name out of the 898 "host" component (or its equivalent) of a URI or deriving the 899 application service type from the scheme of a URI) or information 900 that is derived in a manner not subject to subversion by network 901 attackers (e.g., pulling the data from a delegated domain that is 902 explicitly established via client or system configuration, resolving 903 the data via [DNSSEC], or obtaining the data from a third-party 904 domain mapping service in which a human user has explicitly placed 905 trust and with which the client communicates over a connection or 906 association that provides both mutual authentication and integrity 907 checking). These considerations apply only to extraction of the 908 source domain from the inputs; naturally, if the inputs themselves 909 are invalid or corrupt (e.g., a user has clicked a link provided by a 910 malicious entity in a phishing attack), then the client might end up 911 communicating with an unexpected application service. 913 Example: Given an input URI of , a client 914 would derive the application service type "sip" from the "scheme" 915 and parse the domain name "example.net" from the "host" component 916 (or its equivalent). 918 Each reference identifier in the list SHOULD be based on the source 919 domain and SHOULD NOT be based on a derived domain (e.g., a host name 920 or domain name discovered through DNS resolution of the source 921 domain). This rule is important because only a match between the 922 user inputs and a presented identifier enables the client to be sure 923 that the certificate can legitimately be used to secure the client's 924 communication with the server. There is only one scenario in which 925 it is acceptable for an interactive client to override the 926 recommendation in this rule and therefore communicate with a domain 927 name other than the source domain: because a human user has "pinned" 928 the application service's certificate to the alternative domain name 929 as further discussed under Section 6.6.4 and Section 7.1. In this 930 case, the inputs used by the client to construct its list of 931 reference identifiers might include more than one fully qualified DNS 932 domain name, i.e., both (a) the source domain and (b) the alternative 933 domain contained in the pinned certificate. 935 Using the combination of fully qualified DNS domain name(s) and 936 application service type, the client constructs a list of reference 937 identifiers in accordance with the following rules: 939 * The list SHOULD include a DNS-ID. A reference identifier of type 940 DNS-ID can be directly constructed from a fully qualified DNS 941 domain name that is (a) contained in or securely derived from the 942 inputs (i.e., the source domain), or (b) explicitly associated 943 with the source domain by means of user configuration (i.e., a 944 derived domain). 946 * If a server for the application service type is typically 947 discovered by means of DNS SRV records, then the list SHOULD 948 include an SRV-ID. 950 * If a server for the application service type is typically 951 associated with a URI for security purposes (i.e., a formal 952 protocol document specifies the use of URIs in server 953 certificates), then the list SHOULD include a URI-ID. 955 Which identifier types a client includes in its list of reference 956 identifiers is a matter of local policy. For example, in certain 957 deployment environments, a client that is built to connect only to a 958 particular kind of service (e.g., only IM services) might be 959 configured to accept as valid only certificates that include an SRV- 960 ID for that application service type; in this case, the client would 961 include only SRV-IDs matching the application service type in its 962 list of reference identifiers (not, for example, DNS-IDs). By 963 contrast, a more lenient client (even one built to connect only to a 964 particular kind of service) might include both SRV-IDs and DNS-IDs in 965 its list of reference identifiers. 967 Implementation Note: The client does not need to construct the 968 foregoing identifiers in the actual formats found in a certificate 969 (e.g., as ASN.1 types); it only needs to construct the functional 970 equivalent of such identifiers for matching purposes. 972 6.2.2. Examples 974 A web browser that is connecting via HTTPS to the website at 975 "www.example.com" would have a single reference identifier: a DNS-ID 976 of "www.example.com". 978 A mail user agent that is connecting via IMAPS to the email service 979 at "example.net" (resolved as "mail.example.net") might have three 980 reference identifiers: an SRV-ID of "_imaps.example.net" (see 981 [EMAIL-SRV]), and DNS-IDs of "example.net" and "mail.example.net". 982 (A legacy email user agent would not support [EMAIL-SRV] and 983 therefore would probably be explicitly configured to connect to 984 "mail.example.net", whereas an SRV-aware user agent would derive 985 "example.net" from an email address of the form "user@example.net" 986 but might also accept "mail.example.net" as the DNS domain name 987 portion of reference identifiers for the service.) 989 A voice-over-IP (VoIP) user agent that is connecting via SIP to the 990 voice service at "voice.example.edu" might have only one reference 991 identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). 993 An instant messaging (IM) client that is connecting via XMPP to the 994 IM service at "im.example.org" might have three reference 995 identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), 996 a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of 997 "im.example.org" (see [XMPP]). 999 6.3. Preparing to Seek a Match 1001 Once the client has constructed its list of reference identifiers and 1002 has received the server's presented identifiers in the form of a PKIX 1003 certificate, the client checks its reference identifiers against the 1004 presented identifiers for the purpose of finding a match. The search 1005 fails if the client exhausts its list of reference identifiers 1006 without finding a match. The search succeeds if any presented 1007 identifier matches one of the reference identifiers, at which point 1008 the client SHOULD stop the search. 1010 Implementation Note: A client might be configured to perform 1011 multiple searches, i.e., to match more than one reference 1012 identifier. Although such behavior is not forbidden by this 1013 specification, rules for matching multiple reference identifiers 1014 are a matter for implementation or future specification. 1016 Before applying the comparison rules provided in the following 1017 sections, the client might need to split the reference identifier 1018 into its DNS domain name portion and its application service type 1019 portion, as follows: 1021 * A reference identifier of type DNS-ID does not include an 1022 application service type portion and thus can be used directly as 1023 the DNS domain name for comparison purposes. As an example, a 1024 DNS-ID of "www.example.com" would result in a DNS domain name 1025 portion of "www.example.com". 1027 * For a reference identifier of type SRV-ID, the DNS domain name 1028 portion is the Name and the application service type portion is 1029 the Service. As an example, an SRV-ID of "_imaps.example.net" 1030 would be split into a DNS domain name portion of "example.net" and 1031 an application service type portion of "imaps" (mapping to an 1032 application protocol of IMAP as explained in [EMAIL-SRV]). 1034 * For a reference identifier of type URI-ID, the DNS domain name 1035 portion is the "reg-name" part of the "host" component (or its 1036 equivalent) and the application service type portion is the 1037 application service type associated with the scheme name matching 1038 the [ABNF] "scheme" rule from [URI] (not including the ':' 1039 separator). As previously mentioned, this document specifies that 1040 a URI-ID always contains a "host" component (or its equivalent) 1041 containing a "reg-name". (Matching only the "reg-name" rule from 1042 [URI] limits verification to DNS domain names, thereby 1043 differentiating a URI-ID from a uniformResourceIdentifier entry 1044 that contains an IP address or a mere host name, or that does not 1045 contain a "host" component at all.) Furthermore, note that 1046 extraction of the "reg-name" might necessitate normalization of 1047 the URI (as explained in [URI]). As an example, a URI-ID of 1048 "sip:voice.example.edu" would be split into a DNS domain name 1049 portion of "voice.example.edu" and an application service type of 1050 "sip" (associated with an application protocol of SIP as explained 1051 in [SIP-CERTS]). 1053 Detailed comparison rules for matching the DNS domain name portion 1054 and application service type portion of the reference identifier are 1055 provided in the following sections. 1057 6.4. Matching the DNS Domain Name Portion 1059 The client MUST match the DNS domain name portion of a reference 1060 identifier according to the following rules (and SHOULD also check 1061 the application service type as described under Section 6.5). The 1062 rules differ depending on whether the domain to be checked is a 1063 "traditional domain name" or an "internationalized domain name" (as 1064 defined under Section 2.2). Furthermore, to meet the needs of 1065 clients that support presented identifiers containing the wildcard 1066 character "*", we define a supplemental rule for so-called "wildcard 1067 certificates". 1069 6.4.1. Checking of Traditional Domain Names 1071 If the DNS domain name portion of a reference identifier is a 1072 "traditional domain name", then matching of the reference identifier 1073 against the presented identifier is performed by comparing the set of 1074 domain name labels using a case-insensitive ASCII comparison, as 1075 clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased 1076 to "www.example.com" for comparison purposes). Each label MUST match 1077 in order for the names to be considered to match, except as 1078 supplemented by the rule about checking of wildcard labels 1079 (Section 6.4.3). 1081 6.4.2. Checking of Internationalized Domain Names 1083 If the DNS domain name portion of a reference identifier is an 1084 internationalized domain name, then an implementation MUST convert 1085 any U-labels [IDNA-DEFS] in the domain name to A-labels before 1086 checking the domain name. In accordance with [IDNA-PROTO], A-labels 1087 MUST be compared as case-insensitive ASCII. Each label MUST match in 1088 order for the domain names to be considered to match, except as 1089 supplemented by the rule about checking of wildcard labels 1090 (Section 6.4.3; but see also Section 7.2 regarding wildcards in 1091 internationalized domain names). 1093 6.4.3. Checking of Wildcard Certificates 1095 A client employing this specification's rules MAY match the reference 1096 identifier against a presented identifier whose DNS domain name 1097 portion contains the wildcard character "*" as part or all of a label 1098 (following the description of labels and domain names in 1099 [DNS-CONCEPTS]), provided the requirements listed below are met. 1101 For information regarding the security characteristics of wildcard 1102 certificates, see Section 7.2. 1104 A client MUST NOT use the wildcard identifier if the reference 1105 identifier does not follow the following rules: 1107 1. There is more than one wildcard character. 1109 2. The wildcard appears other than in the left-most label (e.g., do 1110 not match "bar.*.example.net"). 1112 3. The wildcard is not the first character (e.g., do not match 1113 "w*.example.com") 1115 4. The wildcard character is embedded in an A-label or U-label 1116 [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. 1118 6.5. Matching the Application Service Type Portion 1120 When a client checks identifiers of type SRV-ID and URI-ID, it MUST 1121 check not only the DNS domain name portion of the identifier but also 1122 the application service type portion. The client does this by 1123 splitting the identifier into the DNS domain name portion and the 1124 application service type portion (as described under Section 6.3), 1125 then checking both the DNS domain name portion (as described under 1126 Section 6.4) and the application service type portion as described in 1127 the following subsections. 1129 Implementation Note: An identifier of type SRV-ID or URI-ID provides 1130 an application service type portion to be checked, but that portion 1131 is combined only with the DNS domain name portion of the SRV-ID or 1132 URI-ID itself. For example, if a client's list of reference 1133 identifiers includes an SRV-ID of "_xmpp-client.im.example.org" and a 1134 DNS-ID of "apps.example.net", the client would check (a) the 1135 combination of an application service type of "xmpp-client" and a DNS 1136 domain name of "im.example.org" and (b) a DNS domain name of 1137 "apps.example.net". However, the client would not check (c) the 1138 combination of an application service type of "xmpp-client" and a DNS 1139 domain name of "apps.example.net" because it does not have an SRV-ID 1140 of "_xmpp-client.apps.example.net" in its list of reference 1141 identifiers. 1143 6.5.1. SRV-ID 1145 The application service name portion of an SRV-ID (e.g., "imaps") 1146 MUST be matched in a case-insensitive manner, in accordance with 1147 [DNS-SRV]. Note that the "_" character is prepended to the service 1148 identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and 1149 thus does not need to be included in any comparison. 1151 6.5.2. URI-ID 1153 The scheme name portion of a URI-ID (e.g., "sip") MUST be matched in 1154 a case-insensitive manner, in accordance with [URI]. Note that the 1155 ":" character is a separator between the scheme name and the rest of 1156 the URI, and thus does not need to be included in any comparison. 1158 6.6. Outcome 1160 The outcome of the matching procedure is one of the following cases. 1162 6.6.1. Case #1: Match Found 1164 If the client has found a presented identifier that matches a 1165 reference identifier, then the service identity check has succeeded. 1166 In this case, the client MUST use the matched reference identifier as 1167 the validated identity of the application service. 1169 6.6.2. Case #2: No Match Found, Pinned Certificate 1171 If the client does not find a presented identifier matching any of 1172 the reference identifiers but the client has previously pinned the 1173 application service's certificate to one of the reference identifiers 1174 in the list it constructed for this communication attempt (as 1175 "pinning" is explained under Section 1.7), and the presented 1176 certificate matches the pinned certificate (including the context as 1177 described under Section 7.1), then the service identity check has 1178 succeeded. 1180 6.6.3. Case #3: No Match Found, No Pinned Certificate 1182 If the client does not find a presented identifier matching any of 1183 the reference identifiers and the client has not previously pinned 1184 the certificate to one of the reference identifiers in the list it 1185 constructed for this communication attempt, then the client MUST 1186 proceed as described under Section 6.6.4. 1188 6.6.4. Fallback 1190 If the client is an interactive client that is directly controlled by 1191 a human user, then it SHOULD inform the user of the identity mismatch 1192 and automatically terminate the communication attempt with a bad 1193 certificate error; this behavior is preferable because it prevents 1194 users from inadvertently bypassing security protections in hostile 1195 situations. 1197 Security Warning: Some interactive clients give advanced users the 1198 option of proceeding with acceptance despite the identity 1199 mismatch, thereby "pinning" the certificate to one of the 1200 reference identifiers in the list constructed by the client for 1201 this communication attempt. Although this behavior can be 1202 appropriate in certain specialized circumstances, in general it 1203 ought to be exposed only to advanced users. Even then it needs to 1204 be handled with extreme caution, for example by first encouraging 1205 even an advanced user to terminate the communication attempt and, 1206 if the advanced user chooses to proceed anyway, by forcing the 1207 user to view the entire certification path and only then allowing 1208 the user to pin the certificate (on a temporary or permanent 1209 basis, at the user's option). 1211 Otherwise, if the client is an automated application not directly 1212 controlled by a human user, then it SHOULD terminate the 1213 communication attempt with a bad certificate error and log the error 1214 appropriately. An automated application MAY provide a configuration 1215 setting that disables this behavior, but MUST enable the behavior by 1216 default. 1218 7. Security Considerations 1220 7.1. Pinned Certificates 1222 As defined under Section 1.7, a certificate is said to be "pinned" to 1223 a DNS domain name when a user has explicitly chosen to associate a 1224 service's certificate with that DNS domain name despite the fact that 1225 the certificate contains some other DNS domain name (e.g., the user 1226 has explicitly approved "apps.example.net" as a domain associated 1227 with a source domain of "example.com"). The cached name association 1228 MUST take account of both the certificate presented and the context 1229 in which it was accepted or configured (where the "context" includes 1230 the chain of certificates from the presented certificate to the trust 1231 anchor, the source domain, the application service type, the 1232 service's derived domain and port number, and any other relevant 1233 information provided by the user or associated by the client). 1235 7.2. Wildcard Certificates 1237 This document states that the wildcard character "*" SHOULD NOT be 1238 included in presented identifiers but SHOULD be checked by 1239 application clients if the requirements specified in Section 6.4.3 1240 are met. 1242 Wildcard certificates automatically vouch for any and all host names 1243 within their domain. This can be convenient for administrators but 1244 also poses the risk of vouching for rogue or buggy hosts. See for 1245 example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] 1246 (slides 38-40). 1248 Protection against a wildcard that identifies a so-called "public 1249 suffix" (e.g., "*.co.uk" or "*.com") is beyond the scope of this 1250 document. 1252 7.3. Internationalized Domain Names 1254 Allowing internationalized domain names can lead to the inclusion of 1255 visually similar (so-called "confusable") characters in certificates; 1256 for discussion, see for example [IDNA-DEFS]. 1258 7.4. Multiple Identifiers 1260 A given application service might be addressed by multiple DNS domain 1261 names for a variety of reasons, and a given deployment might service 1262 multiple domains (e.g., in so-called "virtual hosting" environments). 1263 In the default TLS handshake exchange, the client is not able to 1264 indicate the DNS domain name with which it wants to communicate, and 1265 the TLS server returns only one certificate for itself. Absent an 1266 extension to TLS, a typical workaround used to facilitate mapping an 1267 application service to multiple DNS domain names is to embed all of 1268 the domain names into a single certificate. 1270 A more recent approach, formally specified in [TLS-EXT], is for the 1271 client to use the TLS "Server Name Indication" (SNI) extension when 1272 sending the client_hello message, stipulating the DNS domain name it 1273 desires or expects of the service. The service can then return the 1274 appropriate certificate in its Certificate message, and that 1275 certificate can represent a single DNS domain name. 1277 To accommodate the workaround that was needed before the development 1278 of the SNI extension, this specification allows multiple DNS-IDs, 1279 SRV-IDs, or URI-IDs in a certificate. 1281 8. References 1283 8.1. Normative References 1285 [DNS-CONCEPTS] 1286 Mockapetris, P., "Domain names - concepts and facilities", 1287 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1288 . 1290 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1291 specifying the location of services (DNS SRV)", RFC 2782, 1292 DOI 10.17487/RFC2782, February 2000, 1293 . 1295 [IDNA-DEFS] 1296 Klensin, J., "Internationalized Domain Names for 1297 Applications (IDNA): Definitions and Document Framework", 1298 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1299 . 1301 [IDNA-PROTO] 1302 Klensin, J., "Internationalized Domain Names in 1303 Applications (IDNA): Protocol", RFC 5891, 1304 DOI 10.17487/RFC5891, August 2010, 1305 . 1307 [LDAP-DN] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1308 (LDAP): String Representation of Distinguished Names", 1309 RFC 4514, DOI 10.17487/RFC4514, June 2006, 1310 . 1312 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1313 Housley, R., and W. Polk, "Internet X.509 Public Key 1314 Infrastructure Certificate and Certificate Revocation List 1315 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1316 . 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, 1320 DOI 10.17487/RFC2119, March 1997, 1321 . 1323 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1324 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1325 May 2017, . 1327 [SRVNAME] Santesson, S., "Internet X.509 Public Key Infrastructure 1328 Subject Alternative Name for Expression of Service Name", 1329 RFC 4985, DOI 10.17487/RFC4985, August 2007, 1330 . 1332 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1333 Resource Identifier (URI): Generic Syntax", STD 66, 1334 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1335 . 1337 8.2. Informative References 1339 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1340 Specifications: ABNF", STD 68, RFC 5234, 1341 DOI 10.17487/RFC5234, January 2008, 1342 . 1344 [Defeating-SSL] 1345 Marlinspike, M., "New Tricks for Defeating SSL in 1346 Practice", BlackHat DC, February 2009, 1347 . 1351 [DNS-CASE] Eastlake 3rd, D., "Domain Name System (DNS) Case 1352 Insensitivity Clarification", RFC 4343, 1353 DOI 10.17487/RFC4343, January 2006, 1354 . 1356 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1357 Rose, "DNS Security Introduction and Requirements", 1358 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1359 . 1361 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1362 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 1363 . 1365 [EMAIL-SRV] 1366 Daboo, C., "Use of SRV Records for Locating Email 1367 Submission/Access Services", RFC 6186, 1368 DOI 10.17487/RFC6186, March 2011, 1369 . 1371 [EV-CERTS] CA/Browser Forum, "Guidelines For The Issuance And 1372 Management Of Extended Validation Certificates", October 1373 2009, . 1375 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1376 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1377 Transfer Protocol -- HTTP/1.1", RFC 2616, 1378 DOI 10.17487/RFC2616, June 1999, 1379 . 1381 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, 1382 DOI 10.17487/RFC2818, May 2000, 1383 . 1385 [HTTPSbytes] 1386 Sokol, J. and R. Hansen, "HTTPS Can Byte Me", BlackHat Abu 1387 Dhabi, November 2010, . 1391 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 1392 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1393 December 2005, . 1395 [NAPTR] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 1396 Part Three: The Domain Name System (DNS) Database", 1397 RFC 3403, DOI 10.17487/RFC3403, October 2002, 1398 . 1400 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1401 Adams, "X.509 Internet Public Key Infrastructure Online 1402 Certificate Status Protocol - OCSP", RFC 2560, 1403 DOI 10.17487/RFC2560, June 1999, 1404 . 1406 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1407 Thayer, "OpenPGP Message Format", RFC 4880, 1408 DOI 10.17487/RFC4880, November 2007, 1409 . 1411 [PRIVATE] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 1412 J., and E. Lear, "Address Allocation for Private 1413 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 1414 February 1996, . 1416 [S-NAPTR] Daigle, L. and A. Newton, "Domain-Based Application 1417 Service Location Using SRV RRs and the Dynamic Delegation 1418 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 1419 January 2005, . 1421 [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", 1422 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1423 . 1425 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1426 A., Peterson, J., Sparks, R., Handley, M., and E. 1427 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1428 DOI 10.17487/RFC3261, June 2002, 1429 . 1431 [SIP-CERTS] 1432 Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1433 Certificates in the Session Initiation Protocol (SIP)", 1434 RFC 5922, DOI 10.17487/RFC5922, June 2010, 1435 . 1437 [SIP-SIPS] Audet, F., "The Use of the SIPS URI Scheme in the Session 1438 Initiation Protocol (SIP)", RFC 5630, 1439 DOI 10.17487/RFC5630, October 2009, 1440 . 1442 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1443 (TLS) Protocol Version 1.2", RFC 5246, 1444 DOI 10.17487/RFC5246, August 2008, 1445 . 1447 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 1448 Extensions: Extension Definitions", RFC 6066, 1449 DOI 10.17487/RFC6066, January 2011, 1450 . 1452 [US-ASCII] American National Standards Institute, "Coded Character 1453 Set - 7-bit American Standard Code for Information 1454 Interchange", ANSI X3.4, 1986. 1456 [VERIFY] Saint-Andre, P. and J. Hodges, "Representation and 1457 Verification of Domain-Based Application Service Identity 1458 within Internet Public Key Infrastructure Using X.509 1459 (PKIX) Certificates in the Context of Transport Layer 1460 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1461 2011, . 1463 [WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User 1464 Interface Guidelines", World Wide Web Consortium LastCall 1465 WD-wsc-ui-20100309, March 2010, 1466 . 1468 [X.500] International Telecommunications Union, "Information 1469 Technology - Open Systems Interconnection - The Directory: 1470 Overview of concepts, models and services", 1471 ITU-T Recommendation X.500, ISO Standard 9594-1, August 1472 2005. 1474 [X.501] International Telecommunications Union, "Information 1475 Technology - Open Systems Interconnection - The Directory: 1476 Models", ITU-T Recommendation X.501, ISO Standard 9594-2, 1477 August 2005. 1479 [X.509] International Telecommunications Union, "Information 1480 Technology - Open Systems Interconnection - The Directory: 1481 Public-key and attribute certificate frameworks", 1482 ITU-T Recommendation X.509, ISO Standard 9594-8, August 1483 2005. 1485 [X.520] International Telecommunications Union, "Information 1486 Technology - Open Systems Interconnection - The Directory: 1487 Selected attribute types", ITU-T Recommendation X.509, 1488 ISO Standard 9594-6, August 2005. 1490 [XMPP] Saint-Andre, P., "Extensible Messaging and Presence 1491 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 1492 March 2011, . 1494 Appendix A. Sample Text 1496 At the time of this writing, two application technologies reuse the 1497 recommendations in this specification: email [EMAIL-SRV] and XMPP 1498 [XMPP]. Here we include the text from [XMPP] to illustrate the 1499 thought process that might be followed by protocol designers for 1500 other application technologies. Specifically, because XMPP uses DNS 1501 SRV records for resolution of the DNS domain names for application 1502 services, the XMPP specification recommends the use of SRV-IDs. 1504 The text regarding certificate issuance is as follows: 1506 ###### 1508 In a PKIX certificate to be presented by an XMPP server (i.e., a 1509 "server certificate"), the certificate MUST include one or more XMPP 1510 addresses (i.e., domainparts) associated with XMPP services hosted at 1511 the server. The rules and guidelines defined in this specification 1512 apply to XMPP server certificates, with the following XMPP-specific 1513 considerations: 1515 * Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP 1516 client and server software implementations. Certification 1517 authorities that issue XMPP-specific certificates MUST support the 1518 DNS-ID identifier type. XMPP service providers SHOULD include the 1519 DNS-ID identifier type in certificate requests. 1521 * Support for the SRV-ID identifier type [SRVNAME] is REQUIRED for 1522 XMPP client and server software implementations (for verification 1523 purposes XMPP client implementations need to support only the 1524 "_xmpp-client" application service type, whereas XMPP server 1525 implementations need to support both the "_xmpp-client" and 1526 "_xmpp-server" application service types). Certification 1527 authorities that issue XMPP-specific certificates SHOULD support 1528 the SRV-ID identifier type. XMPP service providers SHOULD include 1529 the SRV-ID identifier type in certificate requests. 1531 * Support for the XmppAddr identifier type is encouraged in XMPP 1532 client and server software implementations for the sake of 1533 backward-compatibility, but is no longer encouraged in 1534 certificates issued by certification authorities or requested by 1535 XMPP service providers. 1537 * DNS domain names in server certificates MAY contain the wildcard 1538 character "*" as the complete left-most label within the 1539 identifier. 1541 ###### 1543 The text regarding certificate verification is as follows: 1545 ###### 1547 For server certificates, the rules and guidelines defined in this 1548 specification apply, with the proviso that the XmppAddr identifier is 1549 allowed as a reference identifier. 1551 The identities to be checked are set as follows: 1553 * The initiating entity sets its reference identifier to the 'to' 1554 address it communicates in the initial stream header; i.e., this 1555 is the identity it expects the receiving entity to provide in a 1556 PKIX certificate. 1558 * The receiving entity sets its reference identifier to the 'from' 1559 address communicated by the initiating entity in the initial 1560 stream header; i.e., this is the identity that the initiating 1561 entity is trying to assert. 1563 ###### 1565 Acknowledgements 1567 We gratefully acknowledge everyone who contributed to the previous 1568 version of this document, [VERIFY]. 1570 Authors' Addresses 1571 Peter Saint-Andre 1572 Mozilla 1573 United States of America 1575 Email: stpeter@mozilla.com 1577 Jeff Hodges 1578 Google 1579 United States of America 1581 Email: jdhodges@google.com 1583 Rich Salz 1584 Akamai Technologies 1585 United States of America 1587 Email: rsalz@akamai.com