On Fri, Dec 11, 2020 at 11:34 AM Burton <j...@0.me.uk> wrote:
> The bits of information included in the CN field (company name, version,
> etc) created intermediate separation from the rest and the additional
> benefit of these bits of information included in the CN field in an
> intermediate was a person could locate with some accuracy at first glance
> the CA the intermediate belongs too and that can help in many different
> ways.
>
I don't think the benefits here are meaningful, which is where I think we
disagree, nor do I think the use case you're describing is a good trade-off.
Expecting the company name to be in the CN is, frankly, both unreasonable
and not required. The version is already there ("R3"), so I'm not sure why
you mention it, although it'd be totally valid for a CA to use a random
value there.
I don't think "in many different ways" is very useful to articulate the
harm you see.
> The problem with the Let's Encrypt R3 intermediate is that the CN field is
> both unique and not unique. It's unique CN in the sense of the name "R3"
> and also only Let's Encrypt uses that name in an intermediate. It's not an
> unique CN because it's not random enough and doesn't have any other
> information to separate the intermediate if another CA decided to issue an
> intermediate with the same CN name "R3". Also from a first glance
> prospective it's hard to determine the issuer in this format without
> looking inside the intermediate subject.
>
It would seem you're expecting the CN to be a DN. If that's the case, I
regret to inform you, you're wrong for expecting that and unreasonable for
asking for it :)
If another CA wants to use the name R3, I see no issues with that: it is
the Distinguished Name in totality that addresses it, and we've already got
the issue you're concerned about (two CAs use the name "R3") identified by
the O.
> If Let's Encrypt R3 intermediate CN was hypothetically "LE R3" naming that
> would be enough uniqueness other intermediates, very short naming and from
> a first glance prospective easier to determine the issuer.
>
> The main biggest problem point for me is the lack of uniqueness of the
> intermediate with the "R3" naming on it's own.
>
Right, there's absolutely nothing wrong with two CAs using the same CN for
an intermediate, in the same way there's nothing wrong with two CAs using
the same CN for a leaf certificate (i.e. two CAs issuing certificates to
the same server). For your use case, it's important to use the technology
correctly: which is to use the DistinguishedName here, at a minimum.
However, I'm also trying to highlight that using the Distinguished Name
here is itself problematic, and has been for years, so if you're changing
from "use CN", you should really be "use CCADB" rather than "use CN".
Arguments such as "easy, at a glance, in the certificate viewer", which I
can certainly understand is how some have historically looked at things, is
in practice an antiquated idea that doesn't line up with operational
practice. I don't disagree that, say, in the 80s, this is how the ITU
thought things would be, or that Netscape originally thought this is how it
would be, but in the 25 years since SSL, we know it's not how things are.
For example, in order to satisfy your use case, with the Web PKI, we would
need to require that every CA revoke every Root/Intermediate every time
they rebrand, or transfer/sell roots, to replace them with "proper" O
values. As we see from this list itself, it's not uncommon for CAs to do
that, I think we'd both agree it's not desirable to require security
updates every time a CA rebrands (nor would it be operationally viable),
and so the assumption of "look at the DN" is, logically, flawed.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
