[Operators] SSL certificates / private CAs / CACert issue
jesse.thompson at doit.wisc.edu
Fri Mar 22 14:00:38 UTC 2013
On Friday, March 22, 2013 5:16:05 AM, Dave Cridland wrote:
> On Thu, Mar 21, 2013 at 11:57 PM, Phil Pennock
> <xmpp-operators+phil at spodhuis.org
> <mailto:xmpp-operators+phil at spodhuis.org>> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> On 2013-03-21 at 07:45 -0700, Peter Saint-Andre wrote:
> > https://datatracker.ietf.org/doc/draft-miller-xmpp-posh-prooftype/
> """ however, these technologies
> are not yet widely deployed and might not be deployed in the near
> future for domains outside the most common top-level domains (e.g.,
> ".COM", ".NET", ".EDU").
> Of 272 TLDs, 85 have DS records.  ARPA is not germane, so that's
> 84/271. So while DNSSEC is not universal, it's certainly
> misleading to
> imply that it's rare outside of the traditional gTLDs. Eyeballing the
> list of TLDs with DNSSEC delegated through them  it looks to cover
> most nations with a strong Internet presence; notable by their absence
> are just IT, HU, CN and AU. And, perhaps ironically, PRO. ;)
> That's interesting; I wonder how prevalent ISPs within those
> communities are which can handle DNSSEC.
> Reading that draft, it's unclear to me where "im.example.com
> <http://im.example.com>" comes
> from; is that the JID domain, thus phil at im.example.com
> <mailto:phil at im.example.com>, and so there has
> to be an HTTP server at the zone apex which can be configured with
> policy content, or is that derived from phil at example.com
> <mailto:phil at example.com>, in which case
> how is the im label determined? What's the trust path to it?
> It says the source domain, which will be the JID domain as you put it.
> Though I'd argue that with POSH, it's less of a trust path, and more
> of a trust "if you nip through the broken fence then there's a hole in
> the hedge and you can cut across the field". It's a hack, but it's a
> hack that seems to be secure to my eyes, and is deployable now.
> I see the value in having an alternative to DNSSEC, and even having it
> around for the longer term, to be proof against mandated alternate
> anchors and inline resigning, for those stuck in countries where that
> can be mandated. I'm trying to figure out what is being gained here:
> something equivalent to DNS NAPTR but with PKIX validation of the
> After all, if I can have appropriate certs on a web-server, served
> up by
> domain, I can have the same on an XMPP server. The key seems to be to
> rely upon SNI support in web-servers without having to make sure XMPP
> servers can also do dynamic certificate selection, and also
> letting XMPP
> hosting be delegated (thus the NAPTR aspect of things) -- am I correct
> in my summarisation, or have I missed something?
> With POSH, you can host your domain on Google, and have them use their
> Google cert.
> You then take that cert - with no access to the private key - and host
> it on your webserver, secured by your cert (and private key).
> So this is a case where the hostee and hoster don't have to have any
> shared private key, and is also a case where even though you "can have
> appropriate certs on a web-server, served up by domain, " yet you
> cannot "have the same on an XMPP server".
> Does that shed any further light?
I like the concept of POSH to bridge the gap until DNSSEC is prevalent.
I'd advise keeping the focus on POSH for now, because it's something
that operators could actually deploy to production services today.
Are there any example implementations of XMPP-POSH yet?
Are there any other non-XMPP examples of POSH being used in the real
More information about the Operators