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-----