[Operators] SSL certificates / private CAs / CACert issue
dave at cridland.net
Fri Mar 22 10:16:05 UTC 2013
On Thu, Mar 21, 2013 at 11:57 PM, Phil Pennock <
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" comes
> from; is that the JID domain, thus phil at im.example.com, and so there has
> to be an HTTP server at the zone apex which can be configured with XMPP
> policy content, or is that derived from 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 root
> 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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Operators