Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson]

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for GlobalSign.

See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
(Steps 4 through 9).

GlobalSign has four (4) new roots to include in the root store. Two roots,
one RSA and another ECC, are to support server authentication (Bugzilla Bug
# 1570724 <https://bugzilla.mozilla.org/show_bug.cgi?id=1570724>) while two
other roots are for email authentication, RSA and ECC (Bugzilla Bug #
1637269 <https://bugzilla.mozilla.org/show_bug.cgi?id=1637269>).

Mozilla is considering approving GlobalSign’s request(s). This email begins
the 3-week comment period, after which, if no concerns are raised, we will
close the discussion and the request may proceed to the approval phase
(Step 10).

*A Summary of Information Gathered and Verified appears here in these two
CCADB cases:*

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000469

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000596

*Root Certificate Information:*

*GlobalSign Root R46 *

crt.sh -
https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

Download - https://secure.globalsign.com/cacert/rootr46.crt

*GlobalSign Root E46*

crt.sh -
https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

Download - https://secure.globalsign.com/cacert/roote46.crt

*GlobalSign Secure Mail Root R45 *

crt.sh -
https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974

Download - https://secure.globalsign.com/cacert/smimerootr45.crt

*GlobalSign Secure Mail Root E45 *

crt.sh -
https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19

Download - https://secure.globalsign.com/cacert/smimeroote45.crt


*CP/CPS:*

https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf

The current GlobalSign CPS is version 9.6, published 29-December-2020.

Repository location: https://www.globalsign.com/en/repository

*BR Self-Assessment* (Excel) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9082310

*Audits:* GlobalSign is audited annually in accordance with the WebTrust
criteria by Ernst & Young, Belgium, which found in June 2020 that
“throughout the period April 1, 2019 to March 31, 2020, GlobalSign
management’s assertion, as referred to above, is fairly stated, in all
material respects, in accordance with the WebTrust Principles and Criteria
for Certification Authorities - SSL Baseline with Network Security, Version
2.3.” The WebTrust audit noted the following 13 Bugzilla incidents, which
had been previously reported as of that audit date:

1 Misissuance of QWAC certificates.

2 Issue with an OCSP responder status.

3 Some SSL certificates with US country code and invalid State/Prov have
been issued.

4 ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report.

5 OCSP responders found to respond signed by the default CA when passed an
invalid issuer in request.

6 Wrong business category on 3 EV SSL certificates.

7 OCSP Responder returned invalid values for some precertificates.

8 Customer running an on-premise (technically-constrained) CA that chains
to a GlobalSign root, issued certificates without AIA extension.

9 Misissued 4 certificates with invalid CN.

10 Certificates with Subject Public Key Info lacking the explicit NULL
parameter.

11 Untimely revocation of TLS certificate after submission of private key
compromise.

12 Unable to revoke 2 noncompliant QWACs within 5 days.

13 Unable to revoke noncompliant ICA within 7 days



*Incident Reports / Mis-Issuances *

The following bugs/incidents remain open and are being worked on.

1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944>

Empty SingleExtension in OCSP responses
<https://bugzilla.mozilla.org/show_bug.cgi?id=1667944>

1651447 <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447>

Failure to revoke noncompliant ICA within 7 days
<https://bugzilla.mozilla.org/show_bug.cgi?id=1651447>

1591005 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005>

ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005>

1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=1649937>

Incorrect OCSP Delegated Responder Certificate
<https://bugzilla.mozilla.org/show_bug.cgi?id=1649937>

1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=1668007>

Invalid stateOrProvinceName value
<https://bugzilla.mozilla.org/show_bug.cgi?id=1668007>

1664328 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328>

SHA-256 hash algorithm used with ECC P-384 key
<https://bugzilla.mozilla.org/show_bug.cgi?id=1664328>

1575880 <https://bugzilla.mozilla.org/show_bug.cgi?id=1575880>

SSL Certificates with US country code and invalid State/Prov
<https://bugzilla.mozilla.org/show_bug.cgi?id=1575880>



No misissuances were found under these roots, and the CA certificates
passed technical tests.

Thus, this email begins a three-week public discussion period, which I’m
scheduling to close on or about Tuesday, 2-February-2021.



Sincerely yours,

Ben Wilson

Mozilla Root Program

[Ryan Sleevi]

Hey Ben,

I know discussion here has been quiet, but in light of other threads going
on, I actually want to say I'm very supportive of GlobalSign's plan here,
and surprised they didn't call more attention to it, because it's something
to be proud of.

As I understand it, and happy to be corrected if I've made a mistake here,
GlobalSign is actively working to transition their hierarchy to one that
reflects a modern, good practice implementation. That's something they
should be proud of, and something all CAs should take note of. In
particular, they're transitioning to single-purpose roots (e.g. all TLS,
all e-mail), in order to reduce the risk to relying parties from roots that
exist cross-purposes.

You're absolutely correct for calling out GlobalSign's past incidents, and
I don't want to appear to be suggesting that simply spinning up new roots
wipes the old slate clean, but this is a huge step in the right direction,
and does reflect good practice. I will disclose that GlobalSign reached
out, as have several other CAs (PKIoverheid, Sectigo, DigiCert), to invite
feedback in their design and discuss some of their challenges, and I think
that's also the kind of positive, proactive behavior worth encouraging.

Within the context of the incident reports, I do want to also acknowledge
that GlobalSign has consistently improved the quality of their reports. As
the OCSP issue shows, the level of detail and clarity in their
communications, and their providing artifacts, has been a huge help in
addressing and assuaging concerns. Rather than purely looking at the number
of incidents, and instead looking at how the incident reports are handled,
this is good progress. While some bugs did feel like they dragged out (e.g.
1575880), even then, GlobalSign was proactive in communicating both the
completion of past actions as well as next steps, with clear timetables.

GlobalSign has already proactively addressed some of the other things one
might expect from a "modern" CA - for example, supporting and enabling
automation for their customers, both "retail" and "managed CA/Enterprise"
(via AEG), and so I do see a positive trend in addressing some of the
systemic issues here.

That's not to say things are perfect: for example, the mixing of TLS
profiles (DV, OV, EV) in a single hierarchy means that there are still a
number of systemic risks which we've seen as patterns, both from GlobalSign
and other CAs, in terms of audit and audit scopes and proper validation of
information, but I do think this is trending closer to what would be good
for all CAs to think about.

The sooner we can get to sunsetting GlobalSign's legacy roots, the better,
and so I definitely think it would be encouraging to see them help migrate
customers sooner than waiting on natural expiration alone, just like I
think continuing to shorten lifetimes would be another very positive sign.
However, I understand and recognize there are complexities here that may
prevent that, but I didn't want folks to think this was "as good as it
gets" ;)

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ben Wilson]

This is a reminder that I will close discussion on this tomorrow.

[Ben Wilson]

On January 11, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store CA Application Process
<https://wiki.mozilla.org/CA/Application_Process>] for the
above-referenced GlobalSign
inclusion request.

*Summary of Discussion and Completion of Action Items [Steps 5-8]:*

Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
Root CA hierarchy with single-purpose roots. This will lead to less risk
due to fewer cross-dependencies from other uses of PKI. He also noted that
GlobalSign has improved the quality of its incident reporting and
remediation. I agree on both of these points.

While GlobalSign currently has six matters open in Bugzilla, none of these
should be a reason to delay approval of this inclusion request.

1591005 <https://bugzilla.mozilla.org/show_bug.cgi?id=1591005> – the
relevant issuing CAs have been revoked (nearly closed, waiting on a final
key destruction report)

1649937 <https://bugzilla.mozilla.org/show_bug.cgi?id=1649937> - Incorrect
OCSP Delegated Responder Certificate issue - GlobalSign ceased including
the OCSP signing EKU in any newly generated issuing CA (approximately 10
remaining issuing CAs affected by issue are on schedule to be revoked)

1651447 <https://bugzilla.mozilla.org/show_bug.cgi?id=1651447> – Delayed
CA revocation, per issue # 1649937 above (GlobalSign is switching over from
old to newer infrastructure, as described in this and other bugs)

1664328 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664328> - SHA-256
hash algorithm used with ECC P-384 key (almost closed, status update needed)

1667944 <https://bugzilla.mozilla.org/show_bug.cgi?id=1667944> – Empty
SingleExtension in OCSP responses (migration to new OCSP responders nearly
completed)

1668007 <https://bugzilla.mozilla.org/show_bug.cgi?id=1668007> – Country
name in stateOrProvinceName field (almost closed, status update needed)

This is notice that I am closing public discussion [Step 9] and that it is
Mozilla’s intent to approve GlobalSign's request for inclusion [Step 10].

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

[Ben Wilson]

All,
Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process, this
is notice of a "further question or concern" that has arisen concerning
GlobalSign's issuance of a 1024-bit RSA certificate. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
indicated that it will provide an incident report by next Tuesday,
9-Feb-2021.
Thanks,
Ben

[Ben Wilson]

All,
GlobalSign has provided a very detailed incident report in Bugzilla - see
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
There are a few remaining questions that still need to be answered, so this
email is just to keep you aware.
Hopefully later this week I'll be able to come back and see if people are
satisfied and whether we can proceed with the root inclusion request.
Sincerely,
Ben

[Nick Lamb]

On Tue, 9 Feb 2021 14:29:15 -0700

Ben Wilson via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> All,
> GlobalSign has provided a very detailed incident report in Bugzilla -
> see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> There are a few remaining questions that still need to be answered,
> so this email is just to keep you aware.
> Hopefully later this week I'll be able to come back and see if people
> are satisfied and whether we can proceed with the root inclusion
> request.

I have a question (if I should write it in Bugzilla instead please say
so it is unclear to me what the correct protocol is)

GlobalSign have provided a list of 112 other certificates which were
issued for the same reason, I examined some of them manually and
determined that they are in appearance unextraordinary (2048-bit RSA
keys for example) and so it's unsurprising we didn't notice they were
issued previously.

However, the list does not tell me when these certificates were ordered
or, if substantially different, when the email used to "validate" these
orders was sent.

As a result it's hard to be sure whether these certificates were issued
perhaps only a few weeks after they were ordered, which is a relatively
minor oversight, or, like the incident certificate, many years
afterwards. I'd like maybe a column of "order date" and "email sent
date" if the two can be different.

-

I also have noticed something that definitely isn't (just) for
GlobalSign. It seems to me that the current Ten Blessed Methods do not
tell issuers to prevent robots from "clicking" email links. We don't
need a CAPTCHA, just a "Yes I want this certificate" POST form ought to
be enough to defuse typical "anti-virus", "anti-malware" or automated
crawling/ cache building robots. Maybe I just missed where the BRs
tell you to prevent that, and hopefully even without prompting all
issuers using the email-based Blessed Methods have prevented this,


Nick.

[Ryan Sleevi]

On Thu, Feb 11, 2021 at 1:11 PM Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I have a question (if I should write it in Bugzilla instead please say
> so it is unclear to me what the correct protocol is)
>

While Mozilla Policy permits discussion in both, I will say it's
significantly easier when the discussion is on Bugzilla to ensure the
feedback is considered and promptly responded to. So if you want to
consider posing your questions there, that's really helpful for posterity.
If, for example, it became necessary to discuss a set of issues for a CA,
Bugzilla incident reports are going to be the primary source of the
incident report and discussion, and unless there's a clear link *on the
bug* to such mailing list discussion, it will no doubt be overlooked.

So I'd say feel free to ask your question there, which helps make sure it's
answered before the issue is closed.

> I also have noticed something that definitely isn't (just) for
> GlobalSign. It seems to me that the current Ten Blessed Methods do not
> tell issuers to prevent robots from "clicking" email links. We don't
> need a CAPTCHA, just a "Yes I want this certificate" POST form ought to
> be enough to defuse typical "anti-virus", "anti-malware" or automated
> crawling/ cache building robots. Maybe I just missed where the BRs
> tell you to prevent that, and hopefully even without prompting all
> issuers using the email-based Blessed Methods have prevented this,
>

Yes, this has been raised previously in the Forum by Peter Bowen (then at
Amazon), as part of the discussion and input with respect to the validation
methods. This is one of many outstanding items still for the Validation
Working Group of the CA/B Forum, as possible mitigations were also
discussed. In short, "capability URLs" (where the entire URL is, in effect,
the capability) are dangerous.

Note that there have been far more than "Ten Blessed Methods" since those
discussions, so perhaps it's clearer to just say 3.2.2.4.

[Arvid Vermote]

Hi Nick

We attached an updated version of the affected certificate overview to the
bug on February 10, which does contain the date of order and date of
issuance.

Thanks

Arvid

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: donderdag 11 februari 2021 19:12
> To: dev-secur...@lists.mozilla.org
> Cc: Ben Wilson <bwi...@mozilla.com>
> Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for
R46,
> E46, R45 and E45 Roots
>
> On Tue, 9 Feb 2021 14:29:15 -0700
> Ben Wilson via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
> > All,
> > GlobalSign has provided a very detailed incident report in Bugzilla -
> > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> > There are a few remaining questions that still need to be answered, so
> > this email is just to keep you aware.
> > Hopefully later this week I'll be able to come back and see if people
> > are satisfied and whether we can proceed with the root inclusion
> > request.
>

> I have a question (if I should write it in Bugzilla instead please say so
it is unclear
> to me what the correct protocol is)
>

> GlobalSign have provided a list of 112 other certificates which were
issued for the
> same reason, I examined some of them manually and determined that they are
in
> appearance unextraordinary (2048-bit RSA keys for example) and so it's
> unsurprising we didn't notice they were issued previously.
>
> However, the list does not tell me when these certificates were ordered
or, if
> substantially different, when the email used to "validate" these orders
was sent.
>
> As a result it's hard to be sure whether these certificates were issued
perhaps
> only a few weeks after they were ordered, which is a relatively minor
oversight,
> or, like the incident certificate, many years afterwards. I'd like maybe a
column of
> "order date" and "email sent date" if the two can be different.
>
> -
>

> I also have noticed something that definitely isn't (just) for GlobalSign.
It seems to
> me that the current Ten Blessed Methods do not tell issuers to prevent
robots
> from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want
this
> certificate" POST form ought to be enough to defuse typical "anti-virus",
"anti-
> malware" or automated crawling/ cache building robots. Maybe I just missed
> where the BRs tell you to prevent that, and hopefully even without
prompting all
> issuers using the email-based Blessed Methods have prevented this,
>
>

> Nick.

[Ben Wilson]

All,
On Monday, I'm going to recommend to Kathleen that we proceed with these
root inclusion requests of GlobalSign.
Please let us know if there are any concerns.
Thanks,
Ben

[Nick Lamb]

On Thu, 11 Feb 2021 15:12:46 -0500
Ryan Sleevi via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> So I'd say feel free to ask your question there, which helps make
> sure it's answered before the issue is closed.

Good point. In this case Arvid has clarified that in fact the ticket
now has an updated sheet which (I haven't examined it yet) should
satisfy my question so I shan't follow up there except in the event I
have further questions.

> This is one of many outstanding items still
> for the Validation Working Group of the CA/B Forum, as possible
> mitigations were also discussed. In short, "capability URLs" (where
> the entire URL is, in effect, the capability) are dangerous.

Good to know.

> Note that there have been far more than "Ten Blessed Methods" since
> those discussions, so perhaps it's clearer to just say 3.2.2.4.

Personally I just like the way "Ten Blessed Methods" sounds.

I wouldn't reliably recognise all Thirty Six Views of Mount Fuji,
everything except (what I'd call) Big Wave, and Watermill could be any
of dozens of imitators as far as this uneducated eye is concerned - and
of course there are actually ten more of them, but we still call it
"Thirty Six Views of Mount Fuji".

The addition (and deprecation) of methods is an expected and desirable
course for the Baseline Requirements, and I am watching even if I don't
comment on it.

However because everything is formatted according to RFC 3647 (which is
a good thing), section 3.2.2.4 doesn't carry the same implication as
"Ten Blessed Methods". BR 1.3.0 had a section 3.2.2.4 it's just that it
doesn't in fact set down which methods must be used, which is how we
got here in the first place.

But I'm not old enough just yet to be incapable of learning new tricks,
I've learned to call it a "blocklist" not a "blacklist" and I'm sure if
everybody really starts to refer only to "3.2.2.4" I'll get used to
that.

Nick.