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.
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. 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. Burton On Fri, 11 Dec 2020, 13:51 Ryan Sleevi, <r...@sleevi.com> wrote: > > > On Fri, Dec 11, 2020 at 5:51 AM Burton via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> The common name of the Let's Encrypt R3 intermediate certificate ( >> https://crt.sh/?id=3479778542) is in my opinion short and ambiguous. It >> doesn't have any information in common name that can identify the operator >> of the CA "Let's Encrypt" which can cause confusion who is running the CA. >> >> The intermediate certificate common name "R3" naming shouldn't be allowed. >> It's like the past root store naming that had ambiguous naming such as >> "Root CA". >> >> If such common name naming was adopted by other CAs it would terrible to >> manage certificate stores and cause chaos of confusion. >> >> Burton >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy > > > I see nothing wrong here, and believe it would benefit users if more CAs > adopted this. > > I’m honestly shocked that the benefits aren’t self-evident, although I > appreciate Let’s Encrypt having documented them as well. What possible > reason could you have for raising concern? I cannot see any fathomable > reason for wanting to, say, repeat the organization name within the CN, nor > is there any need whatsoever to have any “human readable” strings there in > the CN, as long as there is a unique string. > > 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. After all, we have > plenty of examples over the past 25 years where, for both roots and > intermediates, every bit of the DN becomes inaccurate over time (e.g. roots > are sold, companies rebrand, etc). > > So, while I understand the “I can’t look at the cert and tells who owns > it” argument, which I’m not sure if you’re making, but which is > demonstrably nonsense already, could you perhaps clarify more about why you > don’t like it? > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
