Re: Intermediate common name ambiguous naming
On Sun, Dec 20, 2020 at 9:54 AM Matthew Thompson via dev-security-policy 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. Each browser shows something different to describe the CA. Using the site https://www.city.kameyama.mie.jp/ as an example: Chrome shows the common name of the issuer of the end-entity certificate in the tooltip. Safari does not show anything until you go for "Show Certificate" after clicking the lock. Firefox shows the organization name of the issuer of the end-entity certificate in the tooltip. I don't have IE handy, but it used to show the "friendly name" of the root, which is from the Microsoft certificate database and is not in the certificate at all. I think some other browser used to show the organization name of the root, but I can't remember which. There just isn't consistency. If you want UI consistency as a CA, you have to duplicate info in various attributes. When I was setting up a PKI hierarchy a few years ago, I chose to make the organization and common name the same for all the CAs that were not root CAs. The roots all have unique common names because that was a requirement from Microsoft. You can see the result here: https://crt.sh/?CAName=%25Amazon%25 To the point at the beginning of this thread, all these subordinates have the exact same common name. No one has ever complained, to my knowledge. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediate common name ambiguous naming
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
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
> > > >
Re: Intermediate common name ambiguous naming
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 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, wrote:
> >
> >> On Fri, Dec 11, 2020 at 11:34 AM Burton 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
Re: Intermediate common name ambiguous naming
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 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, wrote:
>
>> On Fri, Dec 11, 2020 at 11:34 AM Burton 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
Re: Intermediate common name ambiguous naming
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, wrote:
> On Fri, Dec 11, 2020 at 11:34 AM Burton 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
Re: Intermediate common name ambiguous naming
On Fri, Dec 11, 2020 at 11:34 AM Burton 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
Re: Intermediate common name ambiguous naming
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, 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
Re: Intermediate common name ambiguous naming
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
Re: Intermediate common name ambiguous naming
Hi, On Fri, 11 Dec 2020 10:51:44 + Burton via dev-security-policy 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". I am somewhat "guilty" of that because I proposed to Let's Encrypt [1] to try to shorten strings in the intermediate in order to make it smaller (it is transmitted very often, so small savings matter). The rationale in the discussion for the R3 common name was that the organizationName already contains "Let's Encrypt" and is required, thus putting the CA name into the CN is redundant. I guess this comes down to the question whether you expect the common name on its own to be meaningful in intermediate certs or if you consider the whole subject. If you manage your CA store by always showing the whole subject this problem does not exist. I feel this makes sense, if an organizationName is required anyway then there shouldn't be a need. And given that certs are transmitted very often and the info in the subject is read rarely (it is after all just informational and has little technical meaning except for identifying the cert) I feel there shouldn't be rules that make this info needlessly long. [1] https://community.letsencrypt.org/t/lets-encrypt-new-hierarchy-plans/125517/18 -- Hanno Böck https://hboeck.de/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
