Sure, is there a more specific question I could answer? I'm not really sure how to rephrase that, and CAs seem to understand it. [1]
[1] https://www.abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf On Fri, Dec 11, 2020 at 1:43 PM Burton <j...@0.me.uk> wrote: > 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
