idnits 2.17.1 draft-ietf-xmpp-posh-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2015) is 3377 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 normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-06 == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-14 == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7238 (Obsoleted by RFC 7538) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP Working Group M. Miller 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Saint-Andre 5 Expires: July 30, 2015 &yet 6 January 26, 2015 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-03 11 Abstract 13 Experience has shown that it is extremely difficult to deploy proper 14 PKIX certificates for TLS in multi-tenanted environments. As a 15 result, domains hosted in such environments often deploy applications 16 using certificates that identify the hosting service, not the hosted 17 domain. Such deployments force end users and peer services to accept 18 a certificate with an improper identifier, resulting in obvious 19 security implications. This document defines two methods that make 20 it easier to deploy certificates for proper server identity checking 21 in non-HTTP application protocols. While these methods developed for 22 use in the Extensible Messaging and Presence Protocol (XMPP) as a 23 Domain Name Association (DNA) prooftype, they might also be usable in 24 other non-HTTP application protocols. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 30, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Obtaining Verification Materials . . . . . . . . . . . . . . 4 63 3.1. Source Domain Possesses PKIX Certificate Information . . 5 64 3.2. Source Domain References PKIX Certificate . . . . . . . . 6 65 3.3. Performing Verification . . . . . . . . . . . . . . . . . 7 66 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9 69 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 10.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 We begin with a thought experiment. 82 Imagine that you work on the operations team of a hosting company 83 that provides the "foo" service (or email or instant messaging or 84 social networking service) for ten thousand different customer 85 organizations. Each customer wants their service to be identified by 86 the customer's domain name (e.g., bar.example.com), not the hosting 87 company's domain name (e.g., hosting.example.net). 89 In order to properly secure each customer's "foo" service via 90 Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX 91 certificates [RFC5280] containing identifiers such as 92 bar.example.com, as explained in the "CertID" specification 93 [RFC6125]. Unfortunately, you can't obtain such certificates 94 because: 96 o Certification authorities won't issue such certificates to you 97 because you work for the hosting company, not the customer 98 organization. 100 o Customers won't obtain such certificates and then give them (plus 101 the associated private keys) to you because their legal department 102 is worried about liability. 104 o You don't want to install such certificates (plus the associated 105 private keys) on your servers anyway because your legal department 106 is worried about liability, too. 108 o Even if your legal department is happy, this still means managing 109 one certificate for each customer across the infrastructure, 110 contributing to a large administrative load. 112 Given your inability to deploy public keys / certificates containing 113 the right identifiers, your back-up approach has always been to use a 114 certificate containing hosting.example.net as the identifier. 115 However, more and more customers and end users are complaining about 116 warning messages in user agents and the inherent security issues 117 involved with taking a "leap of faith" to accept the identity 118 mismatch between what [RFC6125] calls the Source Domain 119 (bar.example.com) and the Delegated Domain (hosting.example.net). 121 This situation is both insecure and unsustainable. You have 122 investigated the possibility of using DNS Security [RFC4033] and DNS- 123 Based Authentication of Named Entities (DANE) [RFC6698] to solve the 124 problem. However, your customers and your operations team have told 125 you that it will be several years before they will be able to deploy 126 DNSSEC and DANE for all of your customers (because of tooling 127 updates, slow deployment of DNSSEC at some top-level domains, etc.). 128 The product managers in your company are pushing you to find a method 129 that can be deployed more quickly to overcome the lack of proper 130 server identity checking for your hosted customers. 132 One possible approach that your team has investigated is to ask each 133 customer to provide the public key / certificate for the "foo" 134 service at a special HTTPS URL on their website 135 ("https://bar.example.com/.well-known/posh.foo.json" is one 136 possibility). This could be a public key that you generate for the 137 customer, but because the customer hosts it via HTTPS, any user agent 138 can find that public key and check it against the public key you 139 provide during TLS negotiation for the "foo" service (as one added 140 benefit, the customer never needs to hand you a private key). 141 Alternatively, the customer can redirect requests for that special 142 HTTPS URL to an HTTPS URL at your own website, thus making it 143 explicit that they have delegated the "foo" service to you. 145 The approach sketched out above, called POSH ("PKIX Over Secure 146 HTTP"), is explained in the remainder of this document. While this 147 approach was developed for use in the Extensible Messaging and 148 Presence Protocol (XMPP) as a prooftype for Domain Name Associations 149 (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP 150 application protocol. 152 2. Terminology 154 This document inherits security terminology from [RFC5280]. The 155 terms "Source Domain", "Delegated Domain", "Derived Domain", and 156 "Reference Identifier" are used as defined in the "CertID" 157 specification [RFC6125]. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 [RFC2119]. 164 3. Obtaining Verification Materials 166 Server identity checking (see [RFC6125]) involves three different 167 aspects: 169 1. A proof of the POSH server's identity (in PKIX, this takes the 170 form of a PKIX end-entity certificate [RFC5280]). 172 2. Rules for checking the certificate (which vary by application 173 protocol, although [RFC6125] attempts to harmonize those rules). 175 3. The materials that a POSH client uses to verify the POSH server's 176 identity or check the POSH server's proof (in PKIX, this takes 177 the form of chaining the end-entity certificate back to a trusted 178 root and performing all validity checks as described in 179 [RFC5280], [RFC6125], and the relevant application protocol 180 specification). 182 When POSH is used, the first two aspects remain the same: the POSH 183 server proves it identity by presenting a PKIX certificate [RFC5280] 184 and the certificate is checked according to the rules defined in the 185 appropriate application protocol specification (such as [RFC6120] for 186 XMPP). However, the POSH client obtains the materials it will use to 187 verify the server's proof by retrieving a JSON document [RFC7159] 188 containing hashes of the PKIX certificate over HTTPS ([RFC7230] and 189 [RFC2818]) from a well-known URI [RFC5785] at the Source Domain. 190 (This means that the POSH client needs to verify the certificate of 191 the HTTPS service at the Source Domain in order to securely 192 "bootstrap" into the use of POSH; specifically, the rules of 194 [RFC2818] apply to this "bootstrapping" step to provide a secure 195 basis for all subsequent POSH processing.) 197 The process for retrieving a PKIX certificate over secure HTTP is as 198 follows. 200 1. The POSH client performs an HTTPS GET request at the Source 201 Domain to the path "/.well-known/posh.{servicedesc}.json". The 202 value of "{servicedesc}" is application-specific; see Section 8 203 of this document for more details. For example, if the 204 application protocol is some hypothetical "foo" service, then 205 "{servicedesc}" could be "foo"; thus if an application client 206 were to use POSH to verify an application server for the Source 207 Domain "bar.example.com", the HTTPS GET request would be as 208 follows: 210 GET /.well-known/posh.foo.json HTTP/1.1 211 Host: bar.example.com 213 2. The Source Domain HTTPS server responds in one of three ways: 215 * If it possesses PKIX certificate information for the requested 216 path, it responds as detailed in Section 3.1. 218 * If it has a reference to where the PKIX certificate 219 information can be obtained, it responds as detailed in 220 Section 3.2. 222 * If it does not have any PKIX certificate information or a 223 reference to such information for the requested path, it 224 responds with an HTTP client error status code (e.g., 404). 226 3.1. Source Domain Possesses PKIX Certificate Information 228 If the Source Domain HTTPS server possesses the certificate 229 information, it responds to the HTTPS GET request with a success 230 status code and the message body set to a JSON document [RFC7159]; 231 the document is a JSON object which MUST have the following: 233 o A "fingerprints" field whose value is a JSON array of fingerprint 234 descriptors. 236 o An "expires" field whose value is a JSON number specifying the 237 number of seconds after which the POSH client ought to consider 238 the key information to be stale (further explained under 239 Section 6). 241 Each included fingerprint descriptor is a JSON object, where each 242 member name is the textual name of a hash function (as listed in 243 [HASH-NAMES]) and its associated value is the base 64 encoded 244 fingerprint hash generated using the named hash function (where the 245 encoding adheres to the definition in Section 4 of [RFC4648] and 246 where the padding bits are set to zero). Each fingerprint descriptor 247 MUST possess at least one named hash function. 249 The fingerprint hash for a given hash algorithm is generated by 250 performing the named hash function over the DER encoding of the PKIX 251 X.509 certifiate; for example, a "sha-1" fingerprint is generated by 252 performing the SHA-1 hash function over the DER encoding of the PKIX 253 certificate. 255 The following example illustrates the usage described above. 257 Example Content Response 259 HTTP/1.1 200 OK 260 Content-Type: application/json 261 Content-Length: 134 263 { 264 "fingerprints": [ 265 { 266 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 267 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" 268 } 269 ], 270 "expires": 604800 271 } 273 The "expires" value is a hint regarding the expiration of the keying 274 materials. It MUST be a non-negative integer. If no "expires" field 275 is included or its value is equal to 0, a POSH client SHOULD consider 276 these verification materials invalid. See Section 6 for how to 277 reconcile this "expires" field with the reference's "expires" field. 279 3.2. Source Domain References PKIX Certificate 281 If the Source Domain HTTPS server has a reference to the certificate 282 information, it responds to the HTTPS GET request with a success 283 status code and message body set to a JSON document. The document is 284 a JSON object which MUST contain the following: 286 o A "url" field whose value is a JSON string specifying the HTTPS 287 URL where POSH clients can obtain the actual certificate 288 information. 290 o An "expires" field whose value is a JSON number specifying the 291 number of seconds after which the POSH client ought to consider 292 the delegation to be stale (further explained under Section 6). 294 Example Reference Response 296 HTTP/1.1 200 Ok 297 Content-Type: application/json 298 Content-Length: 79 300 { 301 "url":"https://hosting.example.net/.well-known/posh.foo.json", 302 "expires":86400 303 } 305 The client performs an HTTPS GET request for the URL specified in the 306 "url" field value. The HTTPS server for the URL to which the client 307 has been redirected responds to the request with a JSON document 308 containing fingerprints as described in Section 3.1. The content 309 retrieved from the "url" location MUST NOT itself be a reference 310 (i.e., containing a "url" field instead of a "fingerprints" field), 311 in order to prevent circular delegations. 313 Note: The JSON document returned by the Source Domain HTTPS server 314 MUST contain either a reference or a fingerprints document, but 315 MUST NOT contain both. 317 Note: See Section 9 for discussion about HTTPS redirects. 319 The "expires" value is a hint regarding the expiration of the Source 320 Domain's delegation of service to the Delegated Domain. It MUST be a 321 non-negative integer. If no "expires" field is included or its value 322 is equal to 0, a POSH client SHOULD consider the delegation invalid. 323 See Section 6 for guidelines about reconciling this "expires" field 324 with the "expires" field of the fingerprints document. 326 3.3. Performing Verification 328 The POSH client compares the PKIX information obtained from the POSH 329 server against each fingerprint descriptor object in the POSH 330 results, until a match is found using the hash functions that the 331 client suports, or until the collection of POSH verification 332 materials is exhausted. If none of the fingerprint descriptor 333 objects match the POSH server PKIX information, the POSH client 334 SHOULD reject the connection (however, the POSH client might still 335 accept the connection if other verification schemes are successful). 337 4. Secure Delegation 339 The delegation from the Source Domain to the Delegated Domain can be 340 considered secure if the credentials offered by the POSH server match 341 the verification materials possessed by the client, regardless of how 342 those materials are obtained. 344 5. Order of Operations 346 In order for the POSH client to perform verification of Reference 347 Identifiers without potentially compromising data, POSH processes 348 MUST be complete before any application-layer data is exchanged for 349 the Source Domain. In cases where the POSH client initiates an 350 application-layer connection, the client SHOULD perform all POSH 351 retrievals before initiating a connection (naturally this is not 352 possible in cases where the POSH client receives an application-layer 353 connection). For application protocols that use DNS SRV (including 354 queries for TLSA records in concert with SRV records as described in 355 [I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in 356 parallel with resolving the SRV records and the addresses of any 357 targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 358 [RFC6555]. 360 The following diagram illustrates the possession flow: 362 Client Domain Server 363 ------ ------ ------ 364 | | | 365 | Request POSH | | 366 |------------------------->| | 367 | | | 368 | Return POSH fingerprints | | 369 |<-------------------------| | 370 | | | 371 | Service TLS Handshake | 372 |<===================================================>| 373 | | | 374 | Service Data | 375 |<===================================================>| 376 | | | 378 Figure 1: Order of Events for Possession Flow 380 While the following diagram illustrates the reference flow: 382 Client Domain Server 383 ------ ------ ------ 384 | | | 385 | Request POSH | | 386 |------------------------->| | 387 | | | 388 | Return POSH url | | 389 |<-------------------------| | 390 | | | 391 | Request POSH | 392 |---------------------------------------------------->| 393 | | | 394 | Return POSH fingerprints | 395 |<----------------------------------------------------| 396 | | | 397 | Service TLS Handshake | 398 |<===================================================>| 399 | | | 400 | Service Data | 401 |<===================================================>| 402 | | | 404 Figure 2: Order of Events for Reference Flow 406 6. Caching Results 408 The POSH client MUST NOT cache results (reference or fingerprints) 409 indefinitely. If the Source Domain returns a reference, the POSH 410 client MUST use the lower of the two "expires" values when 411 determining how long to cache results (i.e., if the reference 412 "expires" value is lower than the fingerprints "expires" value, honor 413 the reference "expires" value). Once the POSH client considers the 414 results stale, it needs to perform the entire POSH process again 415 starting with the HTTPS GET request to the Source Domain. The POSH 416 client MAY use a lower value than any provided in the "expires" 417 field(s), or not cache results at all. 419 The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead 420 using the expiration hints provided in the POSH reference document or 421 fingerprints documents. To that end, the HTTPS servers for Source 422 Domains and Derived Domains SHOULD specify a 'Cache-Control' header 423 indicating a very short duration (e.g., max-age=60) or "no-cache" to 424 indicate that the response (redirect, reference, or content) is not 425 appropriate to cache at the HTTP layer. 427 7. Alternates and Roll-over 429 To indicate alternate PKIX certificates (such as when an existing 430 certificate will soon expire), the returned fingerprints document MAY 431 contain multiple fingerprint descriptors. The fingerprints SHOULD be 432 ordered with the most relevant certificate first as determined by the 433 application service operator (e.g., the renewed certificate), 434 followed by the next most relevant certificate (e.g., the certificate 435 soonest to expire). Here is an example: 437 { 438 "fingerprints": [ 439 { 440 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 441 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" 442 }, 443 { 444 "sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=", 445 "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" 446 } 447 ], 448 "expires": 806400 449 } 451 Rolling over from one hosting provider to another is best handled by 452 updating the relevant SRV records, not primarily by updating the POSH 453 files themselves. 455 8. IANA Considerations 457 This document registers a well-known URI [RFC5785] for protocols that 458 use POSH. The completed template follows. 460 URI suffix: posh. 462 Change controller: IETF 464 Specification document: [[ this document ]] 466 Related information: Because the "posh." string is merely a 467 prefix, protocols that use POSH need to register particular 468 URIs that are prefixed with the "posh." string. 470 Note that the registered URI is "posh." (with a trailing dot). This 471 is merely a prefix to be placed at the front of well-known URIs 472 [RFC5785] registered by protocols that use POSH, which themselves are 473 responsible for the relevant registrations with the IANA. The URIs 474 registered by such protocols SHOULD match the URI template [RFC6570] 475 path "/.well-known/posh.{servicedesc}.json"; that is, begin with 476 "posh." and end with ".json" (indicating a media type of application/ 477 json [RFC7159]). 479 For POSH-using protocols that rely on DNS SRV records [RFC2782], the 480 "{servicedesc}" part of the well-known URI SHOULD be 481 "{service}.{proto}", where the "{service}" is the DNS SRV "Service" 482 prepended by the underscore character "_" and the "{proto}" is the 483 DNS SRV "Proto" also prepended by the underscore character "_". As 484 an example, the well-known URI for XMPP server-to-server connections 485 would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers 486 a service name of "xmpp-server" and uses TCP as the underlying 487 transport protocol. 489 For other POSH-using protocols, the "{servicedesc}" part of the well- 490 known URI can be any unique string or identifier for the protocol, 491 which might be a service name registered with the IANA in accordance 492 with [RFC6335] or which might be an unregistered name. As an 493 example, the well-known URI for the mythical "foo" service could be 494 "posh.foo.json". 496 Note: As explained in [RFC5785], the IANA registration policy 497 [RFC5226] for well-known URIs is Specification Required. 499 9. Security Considerations 501 This document supplements but does not supersede the security 502 considerations provided in specifications for application protocols 503 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 504 Specifically, the security of requests and responses sent via HTTPS 505 depends on checking the identity of the HTTP server in accordance 506 with [RFC2818]. Additionally, the security of POSH can benefit from 507 other HTTP hardening protocols, such as HSTS [RFC6797] and key 508 pinning [I-D.ietf-websec-key-pinning], especially if the POSH client 509 shares some information with a common HTTPS implementation (e.g., 510 platform-default web browser). 512 Note well that POSH is used by a POSH client to obtain the public key 513 of a POSH server to which it might connect for a particular 514 application protocol such as IMAP or XMPP. POSH does not enable a 515 hosted domain to transfer private keys to a hosting service via 516 HTTPS. POSH also does not enable a POSH server to engage in 517 certificate enrollment with a certification authority via HTTPS, as 518 is done in Enrollment over Secure Transport [RFC7030]. 520 A web server at the Source Domain might redirect an HTTPS request to 521 another URL. The location provided in the redirect response MUST 522 specify an HTTPS URL. Source domains SHOULD use only temporary 523 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 524 (Temporary Redirect). Clients MAY treat any redirect as temporary, 525 ignoring the specific semantics for 301 (Moved Permanently) and 308 526 (Permanent Redirect) [RFC7238]. To protect against circular 527 references, clients MUST NOT follow an infinite number of redirects. 528 It is RECOMMENDED that clients follow no more than 10 redirects, 529 although applications or implementations can require that fewer 530 redirects be followed. 532 Hash function agility is an important quality to ensure secure 533 operations in the face of attacks against the fingerprints obtained 534 within verification materials. Because POSH verification materials 535 are relatively short-lived compared to long-lived credentials such as 536 PKIX end-entity certificates (at least as typically deployed), 537 entities that deploy POSH are advised to swap out POSH files if the 538 hash functions in use are found to be subject to realistic attacks. 540 10. References 542 10.1. Normative References 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 549 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 550 Encodings", RFC 4648, October 2006. 552 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 553 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 555 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 556 Housley, R., and W. Polk, "Internet X.509 Public Key 557 Infrastructure Certificate and Certificate Revocation List 558 (CRL) Profile", RFC 5280, May 2008. 560 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 561 Uniform Resource Identifiers (URIs)", RFC 5785, April 562 2010. 564 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 565 Verification of Domain-Based Application Service Identity 566 within Internet Public Key Infrastructure Using X.509 567 (PKIX) Certificates in the Context of Transport Layer 568 Security (TLS)", RFC 6125, March 2011. 570 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 571 Interchange Format", RFC 7159, March 2014. 573 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 574 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 575 2014. 577 10.2. Informative References 579 [I-D.ietf-dane-srv] 580 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 581 Based Authentication of Named Entities (DANE) TLSA Records 582 with SRV Records", draft-ietf-dane-srv-06 (work in 583 progress), June 2014. 585 [I-D.ietf-websec-key-pinning] 586 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 587 Extension for HTTP", draft-ietf-websec-key-pinning-14 588 (work in progress), June 2014. 590 [I-D.ietf-xmpp-dna] 591 Saint-Andre, P. and M. Miller, "Domain Name Associations 592 (DNA) in the Extensible Messaging and Presence Protocol 593 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 594 February 2014. 596 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 597 specifying the location of services (DNS SRV)", RFC 2782, 598 February 2000. 600 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 601 Rose, "DNS Security Introduction and Requirements", RFC 602 4033, March 2005. 604 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 605 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 606 May 2008. 608 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 609 Protocol (XMPP): Core", RFC 6120, March 2011. 611 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 612 Cheshire, "Internet Assigned Numbers Authority (IANA) 613 Procedures for the Management of the Service Name and 614 Transport Protocol Port Number Registry", BCP 165, RFC 615 6335, August 2011. 617 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 618 Dual-Stack Hosts", RFC 6555, April 2012. 620 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 621 and D. Orchard, "URI Template", RFC 6570, March 2012. 623 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 624 of Named Entities (DANE) Transport Layer Security (TLS) 625 Protocol: TLSA", RFC 6698, August 2012. 627 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 628 Transport Security (HSTS)", RFC 6797, November 2012. 630 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 631 Secure Transport", RFC 7030, October 2013. 633 [RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code 634 308 (Permanent Redirect)", RFC 7238, June 2014. 636 [HASH-NAMES] 637 "Hash Function Textual Names", 638 . 641 Appendix A. Acknowledgements 643 Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and 644 Tobias Markmann for their implementation feedback. Thanks also to 645 Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their 646 input on the specification. 648 Authors' Addresses 650 Matthew Miller 651 Cisco Systems, Inc. 652 1899 Wynkoop Street, Suite 600 653 Denver, CO 80202 654 USA 656 Email: mamille2@cisco.com 657 Peter Saint-Andre 658 &yet 660 Email: peter@andyet.com 661 URI: https://andyet.com/