idnits 2.17.1 draft-ietf-xmpp-posh-00.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 4, 2014) is 3726 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) == Outdated reference: A later version (-41) exists of draft-ietf-jose-json-web-key-20 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** 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) == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-09 == 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) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 8, 2014 &yet 6 February 4, 2014 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-00 11 Abstract 13 Experience has shown that it is extremely difficult to deploy proper 14 PKIX certificates for TLS in multi-tenanted environments, since 15 certification authorities will not issue certificates for hosted 16 domains to hosting services, hosted domains do not want hosting 17 services to hold their private keys, and hosting services wish to 18 avoid liability for holding those keys. As a result, domains hosted 19 in multi-tenanted environments often deploy non-HTTP applications 20 such as email and instant messaging using certificates that identify 21 the hosting service, not the hosted domain. Such deployments force 22 end users and peer services to accept a certificate with an improper 23 identifier, resulting in obvious security implications. This 24 document defines two methods that make it easier to deploy 25 certificates for proper server identity checking in non-HTTP 26 application protocols. The first method enables the TLS client 27 associated with a user agent or peer application server to obtain the 28 end-entity certificate of a hosted domain over secure HTTP as an 29 alternative to standard PKIX techniques. The second method enables a 30 hosted domain to securely delegate a non-HTTP application to a 31 hosting service using redirects provided by HTTPS itself or by a 32 pointer in a file served over HTTPS at the hosted domain. While this 33 approach is developed for use in the Extensible Messaging and 34 Presence Protocol (XMPP) as a Domain Name Association prooftype, it 35 can be applied to any non-HTTP application protocol. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 8, 2014. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Obtaining Verification Materials . . . . . . . . . . . . . . 4 75 4.1. Source Domain Possesses PKIX Certificate . . . . . . . . 6 76 4.2. Source Domain References PKIX Certificate . . . . . . . . 7 77 4.3. Performing Verification . . . . . . . . . . . . . . . . . 8 78 5. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Order of Operations . . . . . . . . . . . . . . . . . . . . . 9 80 7. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 We start with a thought experiment. 94 Imagine that you work on the operations team of a hosting company 95 that provides the "foo" service (or email or instant messaging or 96 social networking service) for ten thousand different customer 97 organizations. Each customer wants their service to be identified by 98 the customer's domain name (e.g., foo.example.com), not the hosting 99 company's domain name (e.g., hosting.example.net). 101 In order to properly secure each customer's "foo" service via 102 Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX 103 certificates [RFC5280] containing identifiers such as 104 foo.example.com, as explained in the "CertID" specification 105 [RFC6125]. Unfortunately, you can't obtain such certificates 106 because: 108 o Certification authorities won't issue such certificates to you 109 because you work for the hosting company, not the customer 110 organization. 112 o Customers won't obtain such certificates and then give them (plus 113 the associated private keys) to you because their legal department 114 is worried about liability. 116 o You don't want to install such certificates (plus the associated 117 private keys) on your servers anyway because your legal department 118 is worried about liability, too. 120 Given your inability to deploy public keys / certificates containing 121 the right identifiers, your back-up approach was always to use a 122 certificate containing hosting.example.net as the identifier. 123 However, more and more customers and end users are complaining about 124 warning messages in user agents and the inherent security issues 125 involved with taking a "leap of faith" to accept the identity 126 mismatch between the source domain (foo.example.com) and the 127 delegated domain (hosting.example.net). 129 This situation is both insecure and unsustainable. You have 130 investigated the possibility of using DNS Security [RFC4033] and DNS- 131 Based Authentication of Named Entities (DANE) [RFC6698] to solve the 132 problem. However, your customers and your operations team have told 133 you that they will not be able to deploy DNSSEC and DANE for several 134 years at least. The product managers in your company are pushing you 135 to find a method that can be deployed more quickly to overcome the 136 lack of proper server identity checking for your hosted customers. 138 One possible approach is to ask each customer to provide the public 139 key / certificate for the "foo" service at a special HTTPS URI on 140 their website ("https://foo.example.com/.well-known/posh.foo.json" is 141 one possibility). This could be a public key that you generate for 142 the customer, but because the customer hosts it via HTTPS, any user 143 agent can find that public key and check it against the public key 144 you provide during TLS negotiation for the "foo" service (as one 145 added benefit, the customer never needs to hand you a private key). 146 Alternatively, the customer can redirect requests for that special 147 HTTPS URI to an HTTPS URI at your own website, thus making it 148 explicit that they have delegated the "foo" service to you. 150 The approach sketched out above, called POSH ("PKIX Over Secure 151 HTTP"), is explained in the remainder of this document. While this 152 approach is developed for use in the Extensible Messaging and 153 Presence Protocol (XMPP) as a prooftype for Domain Name Associations 154 (DNA) [XMPP-DNA], it can be applied to any non-HTTP application 155 protocol. 157 2. Discussion Venue 159 The discussion venue for this document is the posh@ietf.org mailing 160 list; visit https://www.ietf.org/mailman/listinfo/posh for 161 subscription information and discussion archives. 163 3. Terminology 165 This document inherits security terminology from [RFC5280]. The 166 terms "source domain", "derived domain", "reference identifier", and 167 "presented identifier" are used as defined in the "CertID" 168 specification [RFC6125]. 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in 173 [RFC2119]. 175 4. Obtaining Verification Materials 177 Server identity checking (see [RFC6125]) involves three different 178 aspects: 180 1. A proof of the TLS server's identity (in PKIX, this takes the 181 form of a PKIX 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 TLS client uses to verify the TLS server's 187 identity or check the TLS server's proof (in PKIX, this takes the 188 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 TLS 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 TLS client obtains the materials it will use to 198 verify the server's proof by retrieving a JSON Web Key (JWK) set 199 [JOSE-JWK] over HTTPS ([RFC2616] and [RFC2818]) from a well-known URI 200 [RFC5785]. 202 The process for retrieving a PKIX certificate over secure HTTP is as 203 follows. 205 1. The TLS client performs an HTTPS GET at the source domain to the 206 path "/.well-known/posh.{servicedesc}.json". The value of 207 "{servicedesc}" is application-specific; see Section 9 of this 208 document for more details. For example, if the application 209 protocol is some hypothetical "Foo" service, then "{servicedesc}" 210 could be "foo"; thus if a Foo client were to use POSH to verify a 211 Foo server for the domain "foo.example.com", the HTTPS GET 212 request would be as follows: 214 GET /.well-known/posh.foo.json HTTP/1.1 215 Host: foo.example.com 217 2. The source domain HTTPS server responds in one of three ways: 219 * If it possesses a PKIX certificate for the requested path, it 220 responds as detailed in Section 4.1. 222 * If it has a reference to where the PKIX certificate can be 223 obtained, it responds as detailed in Section 4.2. 225 * If it does not have any PKIX certificate for the requested 226 path, it responds with a client error status code (e.g., 404). 228 4.1. Source Domain Possesses PKIX Certificate 230 If the source domain HTTPS server possesses the certificate 231 information, it responds to the HTTPS GET with a success status code 232 and the message body set to a JSON Web Key (JWK) set [JOSE-JWK]. The 233 JWK set MUST contain at least one JWK object, and MUST contain an 234 "expires" field whose value is the number of seconds after which the 235 TLS client ought to consider the key information to be stale (further 236 explained under Section 7). 238 Each included JWK object MUST possess the following information: 240 o The "kty" field set to the appropriate key type used for TLS 241 connections (e.g., "RSA" for a certificate using an RSA key). 243 o The required public parameters for the key type (e.g., "n" and "e" 244 for a certificate using an RSA key). 246 o The "x5t" field set to the certificate thumbprint, as described in 247 section 3.6 of [JOSE-JWK]. 249 Each JWK object MUST NOT possess the private parameters for the key 250 type (e.g., "d", "p", "q" for a certificate using an RSA key). 252 Each JWK object MAY possess other parameters as desired by 253 application servers (e.g., the "x5c" field containing the entire 254 X.509 certificate chain, as per section 3.7 of [JOSE-JWK]). 256 The following example illustrates the usage described above. 258 Example Content Response 259 HTTP/1.1 200 OK 260 Content-Type: application/jwk-set+json 261 Content-Length: 2785 263 { 264 "keys": [ 265 { 266 "kty":"RSA", 267 "kid":"c8fb8b80-1193-11e3-b2b1-835742119fe8", 268 "n":"ANxwssdcU3LbODErec3owrwUhlzjtuskAn8rAcBMRPImn5xA 269 JRX-1T5g2D7MTozWWFk4TlpgzAR5slvM0tc35qAI9I0Cqk4Z 270 LChQrYsWuY7alTrnNXdusHUYc6Eq89DZaH2knTcp57wAXzJP 271 IG_tpBi5F7ck9LVRvRjybix0HJ7i4YrL-GeLuSgrjO4-GDcX 272 Ip8oV0FMKZH-NoMfUITlWYl_JcX1D0WUAiuAnvWtD4Kh_qMJ 273 U6FZuupZGHqPdc3vrXtp27LWgxzxjFa9qnOU6y53vCCJXLLI 274 5sy2fCwEDzLJqh2T6UItIzjrSUZMIsK8r2pXkroI0uYuNn3W 275 y-jAzK8", 276 "e":"AQAB", 277 "x5t":"UpjRI_A3afKE8_AIeTZ5o1dECTY" 278 } 279 ], 280 "expires": 604800 281 } 283 The "expires" value is a hint regarding the expiration of the keying 284 materials. If no "expires" field is included, a TLS client SHOULD 285 consider these verification materials invalid. See Section 7 for how 286 to reconcile this "expires" field with the reference's "expires" 287 field. 289 4.2. Source Domain References PKIX Certificate 291 If the source domain HTTPS server has a reference to the certificate 292 information, it responds to the HTTPS GET with a JSON document. The 293 document MUST contain a "url" field whose value is the HTTPS URL 294 where TLS clients can obtain the actual JWK set, and MUST contain an 295 "expires" field whose value is the number of seconds after which the 296 TLS client ought to consider the delegation to be stale (further 297 explained under Section 7). 299 Example Reference Response 300 HTTP/1.1 200 Ok 301 Content-Type: application/json 302 Content-Length: 78 304 { 305 "url":"https://hosting.example.net/.well-known/posh.foo.json", 306 "expires":86400 307 } 309 The client performs an HTTPS GET for the URL specified in the "url" 310 field value. The HTTPS server for the URI to which the client has 311 been redirected responds to the request with a JWK set. The content 312 retrieved from the "url" location MUST NOT itself be a reference 313 (i.e., containing a "url" fields instead of a "keys" field), in order 314 to prevent circular delegations. 316 Note: The JSON document returned by the source domain HTTPS server 317 MUST contain either a reference or a JWK-set, but MUST NOT contain 318 both. 320 Note: See Section 10 for discussion about HTTPS redirects. 322 The "expires" value is a hint regarding the expiration of the source 323 domain's delegation of service to the delegated domain. If no 324 "expires" field is included, a TLS client SHOULD consider the 325 delegation invalid. See Section 7 for guidelines about reconciling 326 this "expires" field with the JWK-set's "expires" field. 328 4.3. Performing Verification 330 The TLS client compares the PKIX information obtained from the TLS 331 server against each JWK object in the POSH results, until a match is 332 found or the collection of POSH verification materials is exhausted. 333 If none of the JWK objects match the TLS server PKIX information, the 334 TLS client SHOULD reject the connection (the TLS client might still 335 accept the connection if other verification schemes are successful). 337 The TLS client SHOULD compare the fingerprint of the PKIX certificate 338 from the TLS server against the "x5t" field of the JWK object (note 339 the "x5t" field is the base64url encoding of the fingerprint). 341 The TLS client MAY verify the certificate chain provided in the "x5c" 342 field of the JWK object (if present), but it MUST NOT implicitly 343 consider the final certificate in the "x5c" field to be a trust 344 anchor itself; the TLS client only uses the end entity certificate 345 information for verification. 347 5. Secure Delegation 349 The delegation from the source domain to the delegated domain can be 350 considered secure if the certificate offered by the TLS server 351 matches the POSH certificate, regardless of how the POSH certificates 352 are obtained. 354 6. Order of Operations 356 In order for the TLS client to perform verification of reference 357 identifiers without potentially compromising data, POSH processes 358 MUST be complete before any application-level data is exchanged for 359 the source domain. The TLS client SHOULD perform all POSH retrievals 360 before opening any socket connections to the application protocol 361 server. For application protocols that use DNS SRV, the POSH 362 processes ideally ought to be done in parallel with resolving the SRV 363 records and the addresses of any targets, similar to the "happy 364 eyeballs" approach for IPv4 and IPv6 [RFC6555]. 366 The following diagram illustrates the possession flow: 368 Client Domain Server 369 ------ ------ ------ 370 | | | 371 | Request POSH | | 372 |--------------------->| | 373 | | | 374 | Return POSH keys | | 375 |<---------------------| | 376 | | | 377 | Service TLS Handshake | 378 |<===========================================>| 379 | | | 380 | Service Data | 381 |<===========================================>| 382 | | | 384 While the following diagram illustrates the reference flow: 386 Client Domain Server 387 ------ ------ ------ 388 | | | 389 | Request POSH | | 390 |--------------------->| | 391 | | | 392 | Return POSH url | | 393 |<---------------------| | 394 | | | 395 | Request POSH | 396 |-------------------------------------------->| 397 | | | 398 | Return POSH keys | 399 |<--------------------------------------------| 400 | | | 401 | Service TLS Handshake | 402 |<===========================================>| 403 | | | 404 | Service Data | 405 |<===========================================>| 406 | | | 408 7. Caching Results 410 The TLS client MUST NOT cache results (reference or JWK-set) 411 indefinitely. If the source domain returns a reference, the TLS 412 client MUST use the lower of the two "expires" values when 413 determining how long to cache results (i.e., if the reference 414 "expires" value is lower than the JWK-set "expires" value, honor the 415 reference "expires" value). Once the TLS client considers the 416 results stale, it SHOULD perform the entire POSH process again 417 starting with the HTTPS GET to the source domain. The TLS client MAY 418 use a lower value than any provided in the "expires" field(s), or not 419 cache results at all. 421 The TLS client SHOULD NOT rely on HTTP caching mechanisms, instead 422 using the expiration hints provided in the POSH reference or JWK-set 423 documents. To that end, the HTTPS servers for source and derived 424 domains SHOULD specify a 'Cache-Control' header indicating a very 425 short duration (e.g., max-age=60) or "no-cache" to indicate that the 426 response (redirect, reference, or content) is not appropriate to 427 cache at the HTTP level. 429 8. Alternates and Roll-over 431 To indicate alternate PKIX certificates (such as when an existing 432 certificate will soon expire), the returned JWK set MAY contain 433 multiple JWK objects. The JWK set SHOULD be ordered with the most 434 relevant certificate first as determined by the application service 435 operator (e.g., the renewed certificate), followed by the next most 436 relevant certificate (e.g., the certificate soonest to expire). Here 437 is an example: 439 { 440 "keys":[ 441 { 442 "kty": "RSA", 443 "kid": "cfc0ca70-1193-11e3-b2b1-835742119fe8", 444 "n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq 445 MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT 446 YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk 447 0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1 448 0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng 449 0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L 450 w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T 451 vYceNlE", 452 "e": "AQAB", 453 "x5t": "Ae0sLVtm78VT-mQXJQop-ENOM6o" 454 }, 455 { 456 "kty": "RSA", 457 "kid": "dbc28570-1193-11e3-b2b1-835742119fe8", 458 "n": "AM-ktWkQ8btj_HEdAA6kOpzJGgoHNZsJmxjh_PifpgAUfQeq 459 MO_YBR100IdJZRzJfULyhRwn9bikCq87WToxgPWOnd3sH3qT 460 YiAcIR5S6tBbsyp6WYmwM1yuC0vLCo6SoDzdK1SvkQKM3QWk 461 0GFNU4l4qXYAMxaSw83i6yv5DBVbST7E92vS6Gq_4pgI26l1 462 0JhybZuTEVPRUCG6pTKAXQpLxmjJ5oG9M91RP17nsuQeE7Ng 463 0Ap4BBn5hocojkfthwgbX4lqBMecpBAnky5jn6slmzS_rL-L 464 w-_8hUldaTPD9MHlHPrvcsRV5uw8wK5MB6QyfS6wF4b0Kj2T 465 vYceNlE", 466 "e": "AQAB", 467 "x5t": "lYZC2n9TBpOaUsBclEIacQTKToA" 468 } 469 ] 470 } 472 9. IANA Considerations 474 This document registers a well-known URI [RFC5785] for protocols that 475 use POSH. The completed template follows. 477 URI suffix: posh. 479 Change controller: IETF 481 Specification document: [[ this document ]] 483 Related information: Because the "posh." string is merely a 484 prefix, protocols that use POSH need to register particular 485 URIs that are prefixed with the "posh." string. 487 Note that the registered URI is "posh." (with a trailing dot). This 488 is merely a prefix to be placed at the front of well-known URIs 489 [RFC5785] registered by protocols that use POSH, which themselves are 490 responsible for the relevant registrations with the IANA. The URIs 491 registered by such protocols SHOULD match the URI template [RFC6570] 492 path "/.well-known/posh.{servicedesc}.json"; that is, begin with 493 "posh." and end with ".json" (indicating a media type of application/ 494 json [RFC4627] or application/jwk-set+json [JOSE-JWK]). 496 For POSH-using protocols that rely on DNS SRV records [RFC2782], the 497 "{servicedesc}" part of the well-known URI SHOULD be 498 "{service}.{proto}", where the "{service}" is the DNS SRV "Service" 499 prepended by the underscore character "_" and the "{proto}" is the 500 DNS SRV "Proto" also prepended by the underscore character "_". As 501 an example, the well-known URI for XMPP server-to-server connections 502 would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers 503 a service name of "xmpp-server" and uses TCP as the underlying 504 transport protocol. 506 For other POSH-using protocols, the "{servicedesc}" part of the well- 507 known URI can be any unique string or identifier for the protocol, 508 which might be a service name registered with the IANA in accordance 509 with [RFC6335] or which might be an unregistered name. As an 510 example, the well-known URI for the mythical "Foo" service could be 511 "posh.foo.json". 513 Note: As explained in [RFC5785], the IANA registration policy 514 [RFC5226] for well-known URIs is Specification Required. 516 10. Security Considerations 517 This document supplements but does not supersede the security 518 considerations provided in specifications for application protocols 519 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 520 Specifically, the security of requests and responses sent via HTTPS 521 depends on checking the identity of the HTTP server in accordance 522 with [RFC2818]. Additionally, the security of POSH can benefit from 523 other HTTP hardening protocols, such as HSTS [RFC6797] and key 524 pinning [KEYPIN], especially if the TLS client shares some 525 information with a common HTTPS implementation (e.g., platform- 526 default web browser). 528 Note well that POSH is used by a TLS client to obtain the public key 529 of a TLS server to which it might connect for a particular 530 application protocol such as IMAP or XMPP. POSH does not enable a 531 hosted domain to transfer private keys to a hosting service via 532 HTTPS. POSH also does not enable a TLS server to engage in 533 certificate enrollment with a certification authority via HTTPS, as 534 is done in Enrollment over Secure Transport [RFC7030]. 536 A web server at the source domain might redirect an HTTPS request to 537 another URL. The location provided in the redirect response MUST 538 specify an HTTPS URL. Source domains SHOULD use only temporary 539 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 540 (Temporary Redirect). Clients MAY treat any redirect as temporary, 541 ignoring the specific semantics for 301 (Moved Permanently) and 308 542 (Permanent Redirect) [HTTP-STATUS-308]. To protect against circular 543 references, clients MUST NOT follow an infinite number of redirects. 544 It is RECOMMENDED that clients follow no more than 10 redirects, 545 although applications or implementations can require that fewer 546 redirects be followed. 548 11. References 550 11.1. Normative References 552 [JOSE-JWK] 553 Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web- 554 key-20 (work in progress), January 2014. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 560 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 561 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 563 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 565 [RFC4627] Crockford, D., "The application/json Media Type for 566 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 568 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 569 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 571 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 572 Housley, R., and W. Polk, "Internet X.509 Public Key 573 Infrastructure Certificate and Certificate Revocation List 574 (CRL) Profile", RFC 5280, May 2008. 576 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 577 Uniform Resource Identifiers (URIs)", RFC 5785, April 578 2010. 580 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 581 Verification of Domain-Based Application Service Identity 582 within Internet Public Key Infrastructure Using X.509 583 (PKIX) Certificates in the Context of Transport Layer 584 Security (TLS)", RFC 6125, March 2011. 586 11.2. Informative References 588 [HTTP-STATUS-308] 589 Reschke, J., "The Hypertext Transfer Protocol (HTTP) 590 Status Code 308 (Permanent Redirect)", draft-reschke-http- 591 status-308-07 (work in progress), March 2012. 593 [KEYPIN] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 594 Extension for HTTP", draft-ietf-websec-key-pinning-09 595 (work in progress), November 2013. 597 [XMPP-DNA] 598 Saint-Andre, P. and M. Miller, "Domain Name Associations 599 (DNA) in the Extensible Messaging and Presence Protocol 600 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 601 February 2014. 603 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 604 specifying the location of services (DNS SRV)", RFC 2782, 605 February 2000. 607 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 608 Rose, "DNS Security Introduction and Requirements", RFC 609 4033, May 2005. 611 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 612 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 613 May 2008. 615 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 616 Protocol (XMPP): Core", RFC 6120, March 2011. 618 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 619 Cheshire, "Internet Assigned Numbers Authority (IANA) 620 Procedures for the Management of the Service Name and 621 Transport Protocol Port Number Registry", BCP 165, RFC 622 6335, August 2011. 624 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 625 Dual-Stack Hosts", RFC 6555, April 2012. 627 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 628 and D. Orchard, "URI Template", RFC 6570, March 2012. 630 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 631 of Named Entities (DANE) Transport Layer Security (TLS) 632 Protocol: TLSA", RFC 6698, August 2012. 634 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTPS Strict 635 Transport Security (HSTS)", RFC 6797, November 2012. 637 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 638 Secure Transport", RFC 7030, October 2013. 640 Appendix A. Acknowledgements 642 Many thanks to Philipp Hancke, Joe Hildebrand, and Tobias Markmann 643 for their implementation feedback. Thanks also to Dave Cridland, 644 Chris Newton, Max Pritikin, and Joe Salowey for their input on the 645 specification. 647 Authors' Addresses 649 Matthew Miller 650 Cisco Systems, Inc. 651 1899 Wynkoop Street, Suite 600 652 Denver, CO 80202 653 USA 655 Email: mamille2@cisco.com 656 Peter Saint-Andre 657 &yet 659 Email: ietf@stpeter.im