Re: [saag] [lamps] subordinate vs intermediate certification authority

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Feb 8, 2021 at 12:44 PM Viktor Dukhovni <[e-mail]>
wrote:

> On Mon, Feb 08, 2021 at 11:48:57AM -0500, Ryan Sleevi wrote:
>
> > > Where it gets complex is when organizations have outsourced the CA
> > > function elsewhere.  It's meaningless to pin LetsEncrypt or GoDaddy.
> > > It might be meaningful to pin a Subordinate CA signed by some public
> > > CA though.
> >
> > No one, anywhere, should ever pin to a CA that they don’t directly
> control,
> > and even then, they still shouldn’t :)
> >
> > Pinning is just a poor-man’s attempt at a server controlling the client’s
> > trust anchors, and thus inevitably runs into issues, since client policy
> is
> > inherently _client_ policy. Especially important is never pinning to a
> > so-called “public” CA, precisely because their very existence is
> predicated
> > on client policy that is intentionally not controlled/controllable by
> > servers.
>
> With DANE-TA(2), the server is *asserting* the trust-anchor that's
> relevant for validation of its certificate.  It is not a pin as such.
> The real trust-anchor is the DNSKEY RRset that ultimately signs the
> chain leading to validated TLSA records.
>

Using DNS to anchor WebPKI certs is like trying to nail oak posts to jello.

All you have is a chain of trust up to the ICANN yacht club root of trust.
You don't own a DNS name, you rent it. And companies that charge $250,000
to apply to register a name have shown themselves to be untrustworthy.


Clients that implement DANE-TA(2) support will use whatever appears in
> the TLSA record, so there's no assumption of client policy.  (Indeed
> less assumption of client policy than with WebPKI, where one must
> tacitly assume that the CA one has elected to issue one's certs is
> trusted by the relevant clients).
>

And ten years after DANE started, those widely deployed clients would be?


That said, a few operators have on some occasion been too sloppy to
> ensure that the actual certificate they deploy matches the trust anchor
> listed in their own TLSA records.  This is entirely a server-side issue:
> operational negligence, unrelated to client policy.
>

No, it is a protocol failure. There are no incompetent users, only
incompetent service providers. There are no incompetent administrators,
only incompetent protocol architects.

The sine qua non for all security policy is to automate the management of
the services so that the policy advertisements are always up to date.

On Mon, Feb 08, 2021 at 12:13:36PM -0500, Phillip Hallam-Baker wrote:
>
> > > No one, anywhere, should ever pin to a CA that they don’t directly
> > > control, and even then, they still shouldn’t :)
> >
> > Almost agree. Should not pin to a PKIX CA.
>
> Perhaps this is the short version of what I tried to spell out in more
> detail.
>

DNSSEC is simply the WebPKI with a minimum of two trusted parties per path
(ICANN + TLD registry). Oh and a heck of a lot more registries.

If people want to pin keys to a name, the only way to do that in a
practical way is to make the naming system and PKI co-extensive. That is
not a feature that can be added to DNSSEC or to PKIX.