Re: [saag] subordinate vs intermediate certification authority

[Michael Richardson <[e-mail]>]

Viktor Dukhovni <[e-mail]> wrote:
    > On Sat, Feb 06, 2021 at 03:59:37PM -0500, Michael Richardson wrote:

    >> The issue comes up with pinning as it relates to ownership.  It's not
    >> a problem if every organization that can own Things has it's own
    >> private CA.  Pinning that CA works great.  Pinning some other EE is
    >> very much more specific, but also, may be too ephemeral.
    >>
    >> 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.

    > Are you trying to get at generalising the issue described at:

    >     http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html

Hi, that's a very interesting read, and I also haven't seen the diagram at:
   https://letsencrypt.org/certificates/#intermediate-certificates

I also really like the rounded box with the wave bottom to represent a certificate.
I've been looking for a good icon for certificates, it seems for years :-)

    > (where I track sloppy SMTP server operators who've pinned the now
    > retired Let's Encrypt "X3" CA, and have failed to keep up with the
    > times)?

As I understand your page, this is case where example.com is declaring via
DANE-TA what their intended CA is.  Because of the way that LE is changing
their PKI structure, the declared pin point is no longer the "DST Root CA X3",
but now R3/E1/R4/E1.

But, why would they pin that, rather than X1/X2?
Ah, I guess because X1/X2 also sign CAs other than LetsEncrypt.
So this is where the issue is similar.

The difference is that the pinning is not being declared by the serving entity,
but rather by the client entity.  (Mostly, this is not TOFU, btw)

    > The number of MX hosts with such TLSA RRs is falling as they eventually
    > notice (or the issue is brought to their attention).  And, fortunately,
    > with DANE TLSA RRs published in their DNS zone, they can update the pin
    > on their end, without having to ask the world to update some local
    > copy.

Yes, it makes sense to do it this way here.

    > There is a tiny population of SMTP operators who've attempted to
    > publish TLSA RRs that pin the EE public key of a provider's SMTP server
    > they don't control.  That's a mistake, and they eventually figure this
    > out and drop unmaintainable TLSA RRs for servers they don't control.

An analogy, perhaps imperfect, to email operations would be an MUA
which was attempting to pin the key of their IMAPS/SMTP-submit server.
For a provider to which they believe they have a relationship with, in the
sense that their provider owns their mailbox.
This analogy could go further, and perhaps it should continue in DANISH.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide