draft-ietf-xmpp-posh-01.txt   draft-ietf-xmpp-posh-02.txt 
XMPP Working Group M. Miller XMPP Working Group M. Miller
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track P. Saint-Andre Intended status: Standards Track P. Saint-Andre
Expires: December 21, 2014 &yet Expires: April 13, 2015 &yet
June 19, 2014 October 10, 2014
PKIX over Secure HTTP (POSH) PKIX over Secure HTTP (POSH)
draft-ietf-xmpp-posh-01 draft-ietf-xmpp-posh-02
Abstract Abstract
Experience has shown that it is extremely difficult to deploy proper Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments, since PKIX certificates for TLS in multi-tenanted environments, since
certification authorities will not issue certificates for hosted certification authorities will not issue certificates for hosted
domains to hosting services, hosted domains do not want hosting domains to hosting services, hosted domains do not want hosting
services to hold their private keys, and hosting services wish to services to hold their private keys, and hosting services wish to
avoid liability for holding those keys. As a result, domains hosted avoid liability for holding those keys. As a result, domains hosted
in multi-tenanted environments often deploy non-HTTP applications in multi-tenanted environments often deploy non-HTTP applications
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 21, 2014. This Internet-Draft will expire on April 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 44 skipping to change at page 5, line 44
reference to such information for the requested path, it reference to such information for the requested path, it
responds with an HTTP client error status code (e.g., 404). responds with an HTTP client error status code (e.g., 404).
3.1. Source Domain Possesses PKIX Certificate Information 3.1. Source Domain Possesses PKIX Certificate Information
If the source domain HTTPS server possesses the certificate If the source domain HTTPS server possesses the certificate
information, it responds to the HTTPS GET with a success status code information, it responds to the HTTPS GET with a success status code
and the message body set to a JSON document [RFC7159]; the document and the message body set to a JSON document [RFC7159]; the document
is a JSON object which MUST have the following: is a JSON object which MUST have the following:
o A "fingerprints" field whose value is an array of fingerprint o A "fingerprints" field whose value is a JSON array of fingerprint
descriptors. descriptors.
o An "expires" field whose value is the number of seconds after o An "expires" field whose value is a JSON number specifying the
which the TLS client ought to consider the key information to be number of seconds after which the TLS client ought to consider the
stale (further explained under Section 6). key information to be stale (further explained under Section 6).
Each included fingerprint descriptor is a JSON object, where each Each included fingerprint descriptor is a JSON object, where each
member name is the textual name of a hash function (as listed in member name is the textual name of a hash function (as listed in
[HASH-NAMES]) and its associated value is the base 64 encoded [HASH-NAMES]) and its associated value is the base 64 encoded
fingerprint hash generated using the named hash function (where the fingerprint hash generated using the named hash function (where the
encoding adheres to the definition in Section 4 of [RFC4648] and encoding adheres to the definition in Section 4 of [RFC4648] and
where the padding bits are set to zero). Each fingerprint descriptor where the padding bits are set to zero). Each fingerprint descriptor
MUST possess at least one named hash function. MUST possess at least one named hash function.
The fingerprint hash for a given hash algorithm is generated by The fingerprint hash for a given hash algorithm is generated by
skipping to change at page 6, line 38 skipping to change at page 6, line 38
"fingerprints": [ "fingerprints": [
{ {
"sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=",
"sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ="
} }
], ],
"expires": 604800 "expires": 604800
} }
The "expires" value is a hint regarding the expiration of the keying The "expires" value is a hint regarding the expiration of the keying
materials. If no "expires" field is included, a TLS client SHOULD materials. It MUST be a non-negative integer. If no "expires" field
consider these verification materials invalid. See Section 6 for how is included or its value is equal to 0, a TLS client SHOULD consider
to reconcile this "expires" field with the reference's "expires" these verification materials invalid. See Section 6 for how to
field. reconcile this "expires" field with the reference's "expires" field.
3.2. Source Domain References PKIX Certificate 3.2. Source Domain References PKIX Certificate
If the source domain HTTPS server has a reference to the certificate If the source domain HTTPS server has a reference to the certificate
information, it responds to the HTTPS GET with a success status code information, it responds to the HTTPS GET with a success status code
and message body set to a JSON document. The document is a JSON and message body set to a JSON document. The document is a JSON
object which MUST contain the following: object which MUST contain the following:
o A "url" field whose value is the HTTPS URL where TLS clients can o A "url" field whose value is a JSON string specifying the HTTPS
obtain the actual certificate information. URL where TLS clients can obtain the actual certificate
information.
o An "expires" field whose value is the number of seconds after o An "expires" field whose value is a JSON number specifying the
which the TLS client ought to consider the delegation to be stale number of seconds after which the TLS client ought to consider the
(further explained under Section 6). delegation to be stale (further explained under Section 6).
Example Reference Response Example Reference Response
HTTP/1.1 200 Ok HTTP/1.1 200 Ok
Content-Type: application/json Content-Type: application/json
Content-Length: 79 Content-Length: 79
{ {
"url":"https://hosting.example.net/.well-known/posh.foo.json", "url":"https://hosting.example.net/.well-known/posh.foo.json",
"expires":86400 "expires":86400
skipping to change at page 7, line 35 skipping to change at page 7, line 39
(i.e., containing a "url" field instead of a "fingerprints" field), (i.e., containing a "url" field instead of a "fingerprints" field),
in order to prevent circular delegations. in order to prevent circular delegations.
Note: The JSON document returned by the source domain HTTPS server Note: The JSON document returned by the source domain HTTPS server
MUST contain either a reference or a fingerprints document, but MUST contain either a reference or a fingerprints document, but
MUST NOT contain both. MUST NOT contain both.
Note: See Section 9 for discussion about HTTPS redirects. Note: See Section 9 for discussion about HTTPS redirects.
The "expires" value is a hint regarding the expiration of the source The "expires" value is a hint regarding the expiration of the source
domain's delegation of service to the delegated domain. If no domain's delegation of service to the delegated domain. It MUST be a
"expires" field is included, a TLS client SHOULD consider the non-negative integer. If no "expires" field is included or its value
delegation invalid. See Section 6 for guidelines about reconciling is equal to 0, a TLS client SHOULD consider the delegation invalid.
this "expires" field with the "expires" field of the fingerprints See Section 6 for guidelines about reconciling this "expires" field
document. with the "expires" field of the fingerprints document.
3.3. Performing Verification 3.3. Performing Verification
The TLS client compares the PKIX information obtained from the TLS The TLS client compares the PKIX information obtained from the TLS
server against each fingerprint descriptor object in the POSH server against each fingerprint descriptor object in the POSH
results, until a match is found or the collection of POSH results, until a match is found or the collection of POSH
verification materials is exhausted. If none of the fingerprint verification materials is exhausted. If none of the fingerprint
descriptor objects match the TLS server PKIX information, the TLS descriptor objects match the TLS server PKIX information, the TLS
client SHOULD reject the connection (however, the TLS client might client SHOULD reject the connection (however, the TLS client might
still accept the connection if other verification schemes are still accept the connection if other verification schemes are
skipping to change at page 14, line 19 skipping to change at page 14, line 19
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over
Secure Transport", RFC 7030, October 2013. Secure Transport", RFC 7030, October 2013.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code [RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code
308 (Permanent Redirect)", RFC 7238, June 2014. 308 (Permanent Redirect)", RFC 7238, June 2014.
[HASH-NAMES] [HASH-NAMES]
"Hash Function Textual Names", <http://www.iana.org/ "Hash Function Textual Names",
assignments/hash-function-text-names/ <http://www.iana.org/assignments/hash-function-text-names/
hash-function-text-names.xhtml>. hash-function-text-names.xhtml>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and
Tobias Markmann for their implementation feedback. Thanks also to Tobias Markmann for their implementation feedback. Thanks also to
Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their
input on the specification. input on the specification.
Authors' Addresses Authors' Addresses
 End of changes. 10 change blocks. 
24 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/