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

[Viktor Dukhovni <[e-mail]>]

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.

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

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.

One can criticise choosing to publish TLSA RRs that "pin" one's own
issuer CA as a potentially fragile configuration, and indeed I rather
recommend DANE-EE(3) instead, and this is what most DANE users use.

Thus, use of DANE-TA(2) is not a potential conflict with client policy,
and with care, e.g. by delaying new EE cert deployment when the issuer
CA keys change, until new TLSA RRs have been published for a few TTLs,
one can use DANE-TA(2) safely even with a third-party issuing CA (most
typically Let's Encrypt these days).  However, I don't recommend this
except perhaps as a fallback, just in case the DANE-EE(3) rollover is
botched.

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.

-- 
    Viktor.