idnits 2.17.00 (12 Aug 2021) /tmp/idnits16802/draft-ietf-xmpp-posh-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (February 23, 2015) is 2643 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) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: draft-ietf-dane-srv has been published as RFC 7673 == Outdated reference: draft-ietf-websec-key-pinning has been published as RFC 7469 == Outdated reference: draft-ietf-xmpp-dna has been published as RFC 7712 -- 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: 4 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: August 27, 2015 &yet 6 February 23, 2015 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-04 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 August 27, 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 . . . . . . . . 7 65 3.3. Performing Verification . . . . . . . . . . . . . . . . . 8 66 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10 70 8. Guidelines for Protocols that Use POSH . . . . . . . . . . . 11 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 11.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 We begin with a thought experiment. 83 Imagine that you work on the operations team of a hosting company 84 that provides the "SPICE" service (or email or instant messaging or 85 social networking service) for ten thousand different customer 86 organizations. Each customer wants their service to be identified by 87 the customer's domain name (e.g., bar.example.com), not the hosting 88 company's domain name (e.g., hosting.example.net). 90 In order to properly secure each customer's "SPICE" service via 91 Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX 92 certificates [RFC5280] containing identifiers such as 93 bar.example.com, as explained in the "CertID" specification 94 [RFC6125]. Unfortunately, you can't obtain such certificates 95 because: 97 o Certification authorities won't issue such certificates to you 98 because you work for the hosting company, not the customer 99 organization. 101 o Customers won't obtain such certificates and then give them (plus 102 the associated private keys) to you because their legal department 103 is worried about liability. 105 o You don't want to install such certificates (plus the associated 106 private keys) on your servers anyway because your legal department 107 is worried about liability, too. 109 o Even if your legal department is happy, this still means managing 110 one certificate for each customer across the infrastructure, 111 contributing to a large administrative load. 113 Given your inability to deploy public keys / certificates containing 114 the right identifiers, your back-up approach has always been to use a 115 certificate containing hosting.example.net as the identifier. 116 However, more and more customers and end users are complaining about 117 warning messages in user agents and the inherent security issues 118 involved with taking a "leap of faith" to accept the identity 119 mismatch between what [RFC6125] calls the Source Domain 120 (bar.example.com) and the Delegated Domain (hosting.example.net). 122 This situation is both insecure and unsustainable. You have 123 investigated the possibility of using DNS Security [RFC4033] and DNS- 124 Based Authentication of Named Entities (DANE) [RFC6698] to solve the 125 problem. However, your customers and your operations team have told 126 you that it will be several years before they will be able to deploy 127 DNSSEC and DANE for all of your customers (because of tooling 128 updates, slow deployment of DNSSEC at some top-level domains, etc.). 129 The product managers in your company are pushing you to find a method 130 that can be deployed more quickly to overcome the lack of proper 131 server identity checking for your hosted customers. 133 One possible approach that your team has investigated is to ask each 134 customer to provide the public key / certificate for the "SPICE" 135 service at a special HTTPS URL on their website 136 ("https://bar.example.com/.well-known/posh.spice.json" is one 137 possibility). This could be a public key that you generate for the 138 customer, but because the customer hosts it via HTTPS, any user agent 139 can find that public key and check it against the public key you 140 provide during TLS negotiation for the "SPICE" service (as one added 141 benefit, the customer never needs to hand you a private key). 142 Alternatively, the customer can redirect requests for that special 143 HTTPS URL to an HTTPS URL at your own website, thus making it 144 explicit that they have delegated the "SPICE" service to you. 146 The approach sketched out above, called POSH ("PKIX Over Secure 147 HTTP"), is explained in the remainder of this document. While this 148 approach was developed for use in the Extensible Messaging and 149 Presence Protocol (XMPP) as a prooftype for Domain Name Associations 150 (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP 151 application protocol. 153 2. Terminology 155 This document inherits security terminology from [RFC5280]. The 156 terms "Source Domain", "Delegated Domain", "Derived Domain", and 157 "Reference Identifier" are used as defined in the "CertID" 158 specification [RFC6125]. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 [RFC2119]. 165 Additionally, this document uses the following terms: 167 POSH client: The client utilizing the application service (e.g., an 168 XMPP client). It relies on the protocol defined herein to verify 169 the POSH server's identity. 171 POSH server: The server hosting the application service (e.g., an 172 XMPP server). It expects clients to rely on the protocol defined 173 herein to verify its identity. 175 3. Obtaining Verification Materials 177 Server identity checking (see [RFC6125]) involves three different 178 aspects: 180 1. A proof of the POSH server's identity (in PKIX, this takes the 181 form of a PKIX end-entity certificate [RFC5280]). 183 2. Rules for checking the certificate (which vary by application 184 protocol, although [RFC6125] attempts to harmonize those rules). 186 3. The materials that a POSH client uses to verify the POSH server's 187 identity or check the POSH server's proof (in PKIX, this takes 188 the form of chaining the end-entity certificate back to a trusted 189 root and performing all validity checks as described in 190 [RFC5280], [RFC6125], and the relevant application protocol 191 specification). 193 When POSH is used, the first two aspects remain the same: the POSH 194 server proves it identity by presenting a PKIX certificate [RFC5280] 195 and the certificate is checked according to the rules defined in the 196 appropriate application protocol specification (such as [RFC6120] for 197 XMPP). However, the POSH client obtains the materials it will use to 198 verify the server's proof by retrieving a JSON document [RFC7159] 199 containing hashes of the PKIX certificate over HTTPS ([RFC7230] and 200 [RFC2818]) from a well-known URI [RFC5785] at the Source Domain. 201 (This means that the POSH client needs to verify the certificate of 202 the HTTPS service at the Source Domain in order to securely 203 "bootstrap" into the use of POSH; specifically, the rules of 204 [RFC2818] apply to this "bootstrapping" step to provide a secure 205 basis for all subsequent POSH processing.) 207 The process for retrieving a PKIX certificate over secure HTTP is as 208 follows. 210 1. The POSH client performs an HTTPS GET request at the Source 211 Domain to the path "/.well-known/posh.{servicedesc}.json". The 212 value of "{servicedesc}" is application-specific; see Section 9 213 of this document for more details. For example, if the 214 application protocol is some hypothetical "SPICE" service, then 215 "{servicedesc}" could be "spice"; thus if an application client 216 were to use POSH to verify an application server for the Source 217 Domain "bar.example.com", the HTTPS GET request would be as 218 follows: 220 GET /.well-known/posh.spice.json HTTP/1.1 221 Host: bar.example.com 223 2. The Source Domain HTTPS server responds in one of three ways: 225 * If it possesses PKIX certificate information for the requested 226 path, it responds as detailed in Section 3.1. 228 * If it has a reference to where the PKIX certificate 229 information can be obtained, it responds as detailed in 230 Section 3.2. 232 * If it does not have any PKIX certificate information or a 233 reference to such information for the requested path, it 234 responds with an HTTP client error status code (e.g., 404). 236 3.1. Source Domain Possesses PKIX Certificate Information 238 If the Source Domain HTTPS server possesses the certificate 239 information, it responds to the HTTPS GET request with a success 240 status code and the message body set to a JSON document [RFC7159]; 241 the document is a JSON object which MUST have the following: 243 o A "fingerprints" field whose value is a JSON array of fingerprint 244 descriptors. 246 o An "expires" field whose value is a JSON number specifying the 247 number of seconds after which the POSH client ought to consider 248 the key information to be stale (further explained under 249 Section 6). 251 The JSON document returned MUST NOT contain a "url" field as 252 described in Section 3.2. 254 Each included fingerprint descriptor is a JSON object, where each 255 member name is the textual name of a hash function (as listed in 256 [HASH-NAMES]) and its associated value is the base 64 encoded 257 fingerprint hash generated using the named hash function (where the 258 encoding adheres to the definition in Section 4 of [RFC4648] and 259 where the padding bits are set to zero). Each fingerprint descriptor 260 MUST possess at least one named hash function. 262 The fingerprint hash for a given hash algorithm is generated by 263 performing the named hash function over the DER encoding of the PKIX 264 X.509 certifiate; for example, a "sha-1" fingerprint is generated by 265 performing the SHA-1 hash function over the DER encoding of the PKIX 266 certificate. 268 The following example illustrates the usage described above. 270 Example Content Response 272 HTTP/1.1 200 OK 273 Content-Type: application/json 274 Content-Length: 134 276 { 277 "fingerprints": [ 278 { 279 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 280 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" 281 } 282 ], 283 "expires": 604800 284 } 285 The "expires" value is a hint regarding the expiration of the keying 286 materials. It MUST be a non-negative integer. If no "expires" field 287 is included or its value is equal to 0, a POSH client SHOULD consider 288 these verification materials invalid. See Section 6 for how to 289 reconcile this "expires" field with the reference's "expires" field. 291 3.2. Source Domain References PKIX Certificate 293 If the Source Domain HTTPS server has a reference to the certificate 294 information, it responds to the HTTPS GET request with a success 295 status code and message body set to a JSON document. The document is 296 a JSON object which MUST contain the following: 298 o A "url" field whose value is a JSON string specifying the HTTPS 299 URL where POSH clients can obtain the actual certificate 300 information. 302 o An "expires" field whose value is a JSON number specifying the 303 number of seconds after which the POSH client ought to consider 304 the delegation to be stale (further explained under Section 6). 306 Example Reference Response 308 HTTP/1.1 200 Ok 309 Content-Type: application/json 310 Content-Length: 79 312 { 313 "url":"https://hosting.example.net/.well-known/posh.spice.json", 314 "expires":86400 315 } 317 The client performs an HTTPS GET request for the URL specified in the 318 "url" field value. The HTTPS server for the URL to which the client 319 has been redirected responds to the request with a JSON document 320 containing fingerprints as described in Section 3.1. The content 321 retrieved from the "url" location MUST NOT itself be a reference 322 (i.e., containing a "url" field instead of a "fingerprints" field), 323 in order to prevent circular delegations. 325 Note: See Section 10 for discussion about HTTPS redirects. 327 The "expires" value is a hint regarding the expiration of the Source 328 Domain's delegation of service to the Delegated Domain. It MUST be a 329 non-negative integer. If no "expires" field is included or its value 330 is equal to 0, a POSH client SHOULD consider the delegation invalid. 331 See Section 6 for guidelines about reconciling this "expires" field 332 with the "expires" field of the fingerprints document. 334 3.3. Performing Verification 336 The POSH client compares the PKIX information obtained from the POSH 337 server against each fingerprint descriptor object in the POSH 338 results, until a match is found using the hash functions that the 339 client suports, or until the collection of POSH verification 340 materials is exhausted. If none of the fingerprint descriptor 341 objects match the POSH server PKIX information, the POSH client 342 SHOULD reject the connection (however, the POSH client might still 343 accept the connection if other verification schemes are successful). 345 4. Secure Delegation 347 The delegation from the Source Domain to the Delegated Domain can be 348 considered secure if the credentials offered by the POSH server match 349 the verification materials possessed by the client, regardless of how 350 those materials are obtained. 352 5. Order of Operations 354 In order for the POSH client to perform verification of Reference 355 Identifiers without potentially compromising data, POSH processes 356 MUST be complete before any application-layer data is exchanged for 357 the Source Domain. In cases where the POSH client initiates an 358 application-layer connection, the client SHOULD perform all POSH 359 retrievals before initiating a connection (naturally this is not 360 possible in cases where the POSH client receives an application-layer 361 connection). For application protocols that use DNS SRV (including 362 queries for TLSA records in concert with SRV records as described in 363 [I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in 364 parallel with resolving the SRV records and the addresses of any 365 targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 366 [RFC6555]. 368 The following diagram illustrates the possession flow: 370 Client Domain Server 371 ------ ------ ------ 372 | | | 373 | Request POSH | | 374 |------------------------->| | 375 | | | 376 | Return POSH fingerprints | | 377 |<-------------------------| | 378 | | | 379 | Service TLS Handshake | 380 |<===================================================>| 381 | | | 382 | Service Data | 383 |<===================================================>| 384 | | | 386 Figure 1: Order of Events for Possession Flow 388 While the following diagram illustrates the reference flow: 390 Client Domain Server 391 ------ ------ ------ 392 | | | 393 | Request POSH | | 394 |------------------------->| | 395 | | | 396 | Return POSH url | | 397 |<-------------------------| | 398 | | | 399 | Request POSH | 400 |---------------------------------------------------->| 401 | | | 402 | Return POSH fingerprints | 403 |<----------------------------------------------------| 404 | | | 405 | Service TLS Handshake | 406 |<===================================================>| 407 | | | 408 | Service Data | 409 |<===================================================>| 410 | | | 412 Figure 2: Order of Events for Reference Flow 414 6. Caching Results 416 The POSH client MUST NOT cache results (reference or fingerprints) 417 indefinitely. If the Source Domain returns a reference, the POSH 418 client MUST use the lower of the two "expires" values when 419 determining how long to cache results (i.e., if the reference 420 "expires" value is lower than the fingerprints "expires" value, honor 421 the reference "expires" value). Once the POSH client considers the 422 results stale, it needs to perform the entire POSH process again 423 starting with the HTTPS GET request to the Source Domain. The POSH 424 client MAY use a lower value than any provided in the "expires" 425 field(s), or not cache results at all. 427 The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead 428 using the expiration hints provided in the POSH reference document or 429 fingerprints documents. To that end, the HTTPS servers for Source 430 Domains and Derived Domains SHOULD specify a 'Cache-Control' header 431 indicating a very short duration (e.g., max-age=60) or "no-cache" to 432 indicate that the response (redirect, reference, or content) is not 433 appropriate to cache at the HTTP layer. 435 7. Alternates and Roll-over 437 To indicate alternate PKIX certificates (such as when an existing 438 certificate will soon expire), the returned fingerprints document MAY 439 contain multiple fingerprint descriptors. The fingerprints SHOULD be 440 ordered with the most relevant certificate first as determined by the 441 application service operator (e.g., the renewed certificate), 442 followed by the next most relevant certificate (e.g., the certificate 443 soonest to expire). Here is an example: 445 { 446 "fingerprints": [ 447 { 448 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 449 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" 450 }, 451 { 452 "sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=", 453 "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" 454 } 455 ], 456 "expires": 806400 457 } 459 Rolling over from one hosting provider to another is best handled by 460 updating the relevant SRV records, not primarily by updating the POSH 461 files themselves. 463 8. Guidelines for Protocols that Use POSH 465 Protocols that use POSH will need to register well-known URIs wth the 466 IANA in accordance with [RFC5785] (the IANA registration policy 467 [RFC5226] for well-known URIs is Specification Required). 469 For the sake of consistency, it would be best if the URIs registered 470 by such protocols match the URI template [RFC6570] path "/.well- 471 known/posh.{servicedesc}.json"; that is, begin with "posh." and end 472 with ".json" (indicating a media type of application/json [RFC7159]). 474 For POSH-using protocols that rely on DNS SRV records [RFC2782], it 475 would be best if the "{servicedesc}" part of the well-known URI is 476 "{service}.{proto}", where the "{service}" is the DNS SRV "Service" 477 prepended by the underscore character "_" and the "{proto}" is the 478 DNS SRV "Proto" also prepended by the underscore character "_". As 479 an example, the well-known URI for XMPP server-to-server connections 480 would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers 481 a service name of "xmpp-server" and uses TCP as the underlying 482 transport protocol. 484 For other POSH-using protocols, the "{servicedesc}" part of the well- 485 known URI can be any unique string or identifier for the protocol, 486 which might be a service name registered with the IANA in accordance 487 with [RFC6335] or which might be an unregistered name. As an 488 example, the well-known URI for a hypothetical "SPICE" application 489 could be "posh.spice.json". 491 9. IANA Considerations 493 This document requests no actions of IANA. [Note to RFC Editor: 494 please remove this section before publication.] 496 10. Security Considerations 498 This document supplements but does not supersede the security 499 considerations provided in specifications for application protocols 500 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 501 Specifically, the security of requests and responses sent via HTTPS 502 depends on checking the identity of the HTTP server in accordance 503 with [RFC2818]. Additionally, the security of POSH can benefit from 504 other HTTP hardening protocols, such as HSTS [RFC6797] and key 505 pinning [I-D.ietf-websec-key-pinning], especially if the POSH client 506 shares some information with a common HTTPS implementation (e.g., 507 platform-default web browser). 509 Note well that POSH is used by a POSH client to obtain the public key 510 of a POSH server to which it might connect for a particular 511 application protocol such as IMAP or XMPP. POSH does not enable a 512 hosted domain to transfer private keys to a hosting service via 513 HTTPS. POSH also does not enable a POSH server to engage in 514 certificate enrollment with a certification authority via HTTPS, as 515 is done in Enrollment over Secure Transport [RFC7030]. 517 A web server at the Source Domain might redirect an HTTPS request to 518 another URL. The location provided in the redirect response MUST 519 specify an HTTPS URL. Source domains SHOULD use only temporary 520 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 521 (Temporary Redirect). Clients MAY treat any redirect as temporary, 522 ignoring the specific semantics for 301 (Moved Permanently) and 308 523 (Permanent Redirect) [RFC7238]. To protect against circular 524 references, it is RECOMMENDED that POSH clients follow no more than 525 10 redirects, although applications or implementations can require 526 that fewer redirects be followed. 528 Hash function agility is an important quality to ensure secure 529 operations in the face of attacks against the fingerprints obtained 530 within verification materials. Because POSH verification materials 531 are relatively short-lived compared to long-lived credentials such as 532 PKIX end-entity certificates (at least as typically deployed), 533 entities that deploy POSH are advised to swap out POSH files if the 534 hash functions in use are found to be subject to realistic attacks. 536 11. References 538 11.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 545 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 546 Encodings", RFC 4648, October 2006. 548 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 549 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 551 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 552 Housley, R., and W. Polk, "Internet X.509 Public Key 553 Infrastructure Certificate and Certificate Revocation List 554 (CRL) Profile", RFC 5280, May 2008. 556 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 557 Uniform Resource Identifiers (URIs)", RFC 5785, April 558 2010. 560 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 561 Verification of Domain-Based Application Service Identity 562 within Internet Public Key Infrastructure Using X.509 563 (PKIX) Certificates in the Context of Transport Layer 564 Security (TLS)", RFC 6125, March 2011. 566 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 567 Interchange Format", RFC 7159, March 2014. 569 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 570 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 571 2014. 573 11.2. Informative References 575 [I-D.ietf-dane-srv] 576 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 577 Based Authentication of Named Entities (DANE) TLSA Records 578 with SRV Records", draft-ietf-dane-srv-11 (work in 579 progress), February 2015. 581 [I-D.ietf-websec-key-pinning] 582 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 583 Extension for HTTP", draft-ietf-websec-key-pinning-21 584 (work in progress), October 2014. 586 [I-D.ietf-xmpp-dna] 587 Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 588 Associations (DNA) in the Extensible Messaging and 589 Presence Protocol (XMPP)", draft-ietf-xmpp-dna-09 (work in 590 progress), February 2015. 592 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 593 specifying the location of services (DNS SRV)", RFC 2782, 594 February 2000. 596 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 597 Rose, "DNS Security Introduction and Requirements", RFC 598 4033, March 2005. 600 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 601 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 602 May 2008. 604 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 605 Protocol (XMPP): Core", RFC 6120, March 2011. 607 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 608 Cheshire, "Internet Assigned Numbers Authority (IANA) 609 Procedures for the Management of the Service Name and 610 Transport Protocol Port Number Registry", BCP 165, RFC 611 6335, August 2011. 613 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 614 Dual-Stack Hosts", RFC 6555, April 2012. 616 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 617 and D. Orchard, "URI Template", RFC 6570, March 2012. 619 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 620 of Named Entities (DANE) Transport Layer Security (TLS) 621 Protocol: TLSA", RFC 6698, August 2012. 623 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 624 Transport Security (HSTS)", RFC 6797, November 2012. 626 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 627 Secure Transport", RFC 7030, October 2013. 629 [RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code 630 308 (Permanent Redirect)", RFC 7238, June 2014. 632 [HASH-NAMES] 633 "Hash Function Textual Names", 634 . 637 Appendix A. Acknowledgements 639 Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and 640 Tobias Markmann for their implementation feedback. Thanks also to 641 Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their 642 input on the specification. 644 Authors' Addresses 646 Matthew Miller 647 Cisco Systems, Inc. 648 1899 Wynkoop Street, Suite 600 649 Denver, CO 80202 650 USA 652 Email: mamille2@cisco.com 653 Peter Saint-Andre 654 &yet 656 Email: peter@andyet.com 657 URI: https://andyet.com/