Re: I-D Action: draft-ietf-xmpp-posh-02.txt
⌘ Matt Miller <[email protected]> Fri, 10 Oct 2014 16:19:00 -0600
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This revision adds more constraints around the value of the "ttl" fields, which was brought to the editors' attention off-list. The previous revision only vaguely said the "ttl" was a number. It now states the "ttl" is a JSON number that MUST be non-negative integer. - -- - - m&m Matt Miller < [email protected] > Cisco Systems, Inc. On 10/10/14, 4:09 PM, [email protected] wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Extensible Messaging > and Presence Protocol Working Group of the IETF. > > Title : PKIX over Secure HTTP (POSH) Authors : > Matthew Miller Peter Saint-Andre Filename : > draft-ietf-xmpp-posh-02.txt Pages : 14 Date : > 2014-10-10 > > Abstract: Experience has shown that it is extremely difficult to > deploy proper PKIX certificates for TLS in multi-tenanted > environments, since certification authorities will not issue > certificates for hosted domains to hosting services, hosted domains > do not want hosting services to hold their private keys, and > hosting services wish to avoid liability for holding those keys. > As a result, domains hosted in multi-tenanted environments often > deploy non-HTTP applications such as email and instant messaging > using certificates that identify the hosting service, not the > hosted domain. Such deployments force end users and peer services > to accept a certificate with an improper identifier, resulting in > obvious security implications. This document defines two methods > that make it easier to deploy certificates for proper server > identity checking in non-HTTP application protocols. The first > method enables the TLS client associated with a user agent or peer > application server to obtain the end-entity certificate of a hosted > domain over secure HTTP as an alternative to standard PKIX > techniques. The second method enables a hosted domain to securely > delegate a non-HTTP application to a hosting service using > redirects provided by HTTPS itself or by a pointer in a file served > over HTTPS at the hosted domain. While this approach was developed > for use in the Extensible Messaging and Presence Protocol (XMPP) as > a Domain Name Association prooftype, it can be applied to any > non-HTTP application protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-posh-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-posh-02 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ xmpp mailing list > [email protected] https://www.ietf.org/mailman/listinfo/xmpp > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUOFtUAAoJEDWi+S0W7cO1lzcH/0btZ9aCGIWFSy0kgMBAqk76 CYNuN3reOypnDUCULfSilcs1KypKbNfGjVI6UFdKYBmJg9+Z9p34YbobKZk7tooD KNAW+YLtTYGz9cnGse88z9I/kgErqqu0D2vvb64fqvp963lVNGlaOFruB3mrbAOO iZKYQwgnusNi63FN8Z7HVfiRgFxM9k6Pet4BrFRR+WcLuglVlJUshtVcOHTAfrKU UjcFQ+oaresFEHthuLZMH4DxbHuuO3sofKm9juxMC7N35RkXXkgrzTGcxNsrGLsA iOfAby43uqPj6tk3bMG8VDcRbTm3GMu+UcARaPjAjAf9USfsDrP+YVGdTogp+cM= =//3z -----END PGP SIGNATURE-----