[Operators] SSL certificates / private CAs / CACert issue

Dave Cridland 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. [1]  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 [2] 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
> results?
>
> 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?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20130322/0ffa8bdb/attachment.html>


More information about the Operators mailing list