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