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: Summary of Camerfirma's Compliance Issues
Hi Ben, Ryan, Burton and all: Camerfirma will present its claims based on a description of the problems found by associating the references to the specific bugs. After making a complete analysis of the bugs as presented by Ben, always considering that bugs are the main source of truth, we see that the explanations offered by Camerfirma could generally be better developed. We hope to make up for these deficiencies with this report. We have included a list of issues that we consider to be fully addressed in the Appendix I: State of the fixed issues. We will classify the issues in different categories: • SUBCA SUPERVISION • REVOCATION DELAYS • TECHNICAL ISSUES AND AUTOMATISMS 1.- SUBCA SUPERVISION MULTICERT, INFOCERT, INTESA SANPAOLO. Issue H: Non-compliant OCSP Responders by Third-Party Subordinates (Dec. 2017) Issue R: Failure to disclose unconstrained sub-CA (DigitalSign) (2018) Issue T: Failure to disclose unconstrained sub-CA (MULTICERT) (2018 - 2020) Issue X: MULTICERT Misissuance (2018 - 2019) Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020) Issue BB: Failure to revoke underscores (2019) Issue DD: Infocert Misissuance (2017 - 2020) Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019) Issue RR: Failure to disclose unconstrained Sub-CA (Intesa Sanpaolo and Infocert) (2018 - 2020) Issue TT: Certificate with Incorrect OrganizationName (Nov. 2020) In addition to the following requirement stated in the Mozilla policy and just in place • Requirement of pointing in time audit (PIT) and report (at the beginning of each new CA) • Requirement of the annual audits and report (from the creation of each Intermediate CA) We are currently carrying out additional controls on the activities of the organizations that manage intermediate CAs with different implementation time frames: • Adoption of a centralised LINTS (the same one used by Camerfirma) by all intermediate CAs before issuing certificates. (March 2019 Multicert and April 2019 Infocert e Intesa SanPaolo) • Contractual reinforcement of Camerfirma's rights with regards to the activities carried out by Intermediate CAs and their obligation to a periodic communication. (October 2019). • Contractual rights and tools for Camerfirma to insource, when deemed appropriate, intermediate CAs operational activities in order to be able to apply all needed (and already implemented for Camerfirma CAs) controls and to force certificate revocation in a timely manner. Planned changes: • Stop the issuance of certificates. (January 2021) • Implementation of Intermediate CA PIT. (January 2021) • Audit by Camerfirma of 100% of the active certificates issued (Task carry out during January 2021) • Change in the audit process. We are currently requesting the audit report to be issued by a recognised auditor. The new process will require the audit to be carried out by an auditor selected by Camerfirma. (All new audits from January 2021) • Technical environment set-up and procedural definition to be able to insource the management of operational activities of intermediate CAs by the first half of 2021 3.-REVOCATION DELAYS Issue D: Duplicate subjectAlternativeNames and incorrect Subject fields (April 2017) Issue J: Invalid DNS names within certificates (August 2017) Issue L: Invalid subjectAlternativeName within certificates (July 2017) Issue N: Improper issuance and failure to revoke intranet certificates (2015 - 2017) Issue X: MULTICERT Misissuance (2018 - 2019) Issue Z: Intesa Sanpaolo Misissuance (2017 - 2020) Issue BB: Failure to revoke underscores (2019) Issue PP: Failure to disclose unconstrained Sub-CA (Government of Andorra) (2013 - 2019) Issue DD: Infocert Misissuance (2017 - 2020) Issue LL: Invalid authorityKeyIdentifier (2003 - 2020) Issue NN: Incorrect OCSP Delegated Responder Certificate (2013 - 2020) We face the problem when the customers ask more time to complete certificates substitution in their own applications. Controls already in place: • All our External Intermediate CAs and clients have accepted new general terms and condition allowing Camerfirma to revoke all the problematic certificates without their permission if necessary (October 2019). There are not so many problems in reissuing some hundreds of certificates in a couple of days, the problem is awaiting critical customers activities (for example Intesa Sanpaolo one of the largest banks in Europe) before being able to revoke the misissued certificates. • We have developed and started using a massive revocation and substitution tool to be more effective in that process. (June 2020). After implementing all those measures, we have noticed that they were not enough to comply with the required deadlines, and we are
