Definitely seems better for this issue, more identifiable to the user and Firefox already does this for the padlock icon menu.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 20 December 2020 17:04, Matthew Thompson via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > It's not ideal that Google Chrome now states "The connection to this site is > using a valid, trusted server certificate issued by R3" (desktop) and "Google > Chrome verified that R3 issued this website's certificate" (mobile). But that > seems to be an issue the Chromium project could resolve by relying on "O" > instead of "CN". Maybe something for you to look into Ryan. > > Matt T > > On Saturday, 12 December 2020 at 09:00:40 UTC+8, Ryan Sleevi wrote: > > > 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, ry...@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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
