Ryan,
Please could you expand a little more on this?
"*Ideally, users would most benefit from simply having a random value in
the DN (no details, period) for both roots *and* intermediates, as this
metadata both can and should be addressed by CCADB"*
Burton
On Fri, 11 Dec 2020, 16:49 Ryan Sleevi, <r...@sleevi.com> wrote:
> 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
