[Operators] SSL certificates / private CAs / CACert issue

[Phil Pennock]

On 2013-03-22 at 10:16 +0000, Dave Cridland wrote:
> That's interesting; I wonder how prevalent ISPs within those communities
> are which can handle DNSSEC.

I use Joker for registrations; they're a CORE member, which seems to
imply that any CORE registrar can handle DNSSEC, if they so choose: they
have the backing infrastructure, it's all down to them.

When I was at an ISP, we were a CORE member for a variety of good
reasons, both technological and financial.  That was in NL.

So any limitations are down to the ISP in question and their structure.

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

Thanks, I needed that smile.

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

Yes: it's "letting XMPP hosting be delegated (thus the NAPTR aspect of
things)" -- NAPTR style delegation, but using existing trust paths for
HTTPS to the redirector, instead of needing DNSSEC to secure the NAPTR.

So it's what I thought.  Valuable, but perhaps overstated to date and a
draft specification could do with actually explicitly laying out the
use-case and what it buys you.


On 2013-03-22 at 09:00 -0500, Jesse Thompson wrote:
> 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.

How strange.  I have DNSSEC/DANE actually deployed, to my server, since
yesterday.  I've had the DANE cert in place a little longer, this was
just adding a couple of CNAMEs to DNS.  So the publishing part is in
place.

It was only CNAMEs, because I already had the TLSA cert in DNS, for use
with other protocols.

The path-to-anchor verification can be done trivially, with a validating
resolver.  I use unbound, for various reasons, but Bind can be
configured to be validating too.

So what's left, for *both* options, is adding code to manage getting the
trust anchor, in a secure way, to the validation for the target
connection within the connection client program.

-Phil