GlobalSign Root CA - R6 Inclusion Request

[Wayne Thayer]

This request is for inclusion of the GlobalSign Root CA - R6 as documented
in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1390803
This is an RSA-4096 / SHA-384 root that GlobalSign states “…will replace
older, expiring roots that have smaller key sizes in the future.”

* BR Self-Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8941595

* Summary of Information Gathered and Verified:
https://bug1390803.bmoattachments.org/attachment.cgi?id=8962928

* Root Certificate Download URL:
http://secure.globalsign.com/cacert/root-r6.crt

CP/CPS:
** CP:
https://downloads.globalsign.com/acton/attachment/2674/f-0b47/1/-/-/-/-/GlobalSign_CP_v5.8.pdf
** CPS:
https://downloads.globalsign.com/acton/attachment/2674/f-0b46/1/-/-/-/-/GlobalSign_CA_CPS_v8_8_RELEASED.pdf

* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.
** EV Policy OID: 2.23.140.1.1

Test Websites:
** https://valid.r6.roots.globalsign.com/
** https://revoked.r6.roots.globalsign.com/
** https://expired.r6.roots.globalsign.com/

* CRL URL: http://crl.globalsign.com/root-r6.crl

* OCSP URL: http://ocsp2.globalsign.com/rootr6

Audit: Annual audits are performed by BDO and Ernst & Young according to
the WebTrust for CA, BR, and EV audit criteria.
* WebTrust: https://cert.webtrust.org/SealFile?seal=2287&file=pdf

* BR:
** April 1, 2016 - March 31, 2016:
https://bug1390803.bmoattachments.org/attachment.cgi?id=8980269 (EY - clean)
** April 1, 2016 - March 31, 2017:
https://downloads.globalsign.com/acton/attachment/2674/f-08b8/1/-/-/-/-/GlobalSign-WTBR-Indp-Accountant-Report-and-Mgmt-Assertion-FINAL-2017.pdf
(BDO - qualified)
** April 1, 2017 - September 18, 2017:
https://downloads.globalsign.com/acton/attachment/2674/f-0960/1/-/-/-/-/GlobalSign-WTEY-Indp-Assurance-Report-FINAL-2017.pdf
(EY - clean)

* EV: https://cert.webtrust.org/SealFile?seal=2288&file=pdf (BDO - clean)

I’ve reviewed the CP and CPS, BR Self Assessment, and related information
for the GlobalSign Root CA - R6 inclusion request that is being tracked in
this bug and have the following comments:

==Good==
* While this root was created in 2014, it does not appear to have been used
beyond issuing test certificates.
* The CP and CPS state “GlobalSign CA expressly forbids the use of chaining
services for MITM (Man in the Middle) SSL/TLS deep packet inspection.“
* I found GlobalSign’s CP and CPS well structured and easy to understand
(despite the fact that some sections, such as 3.2.2.4 and 3.2.2.5 fail to
align with the BRs).
* CPS section 3.2.8 documents email address validation methods in
compliance with the new 2.6 version of the Mozilla root store policy

==Meh==
* The 2016-2017 BR audit contains two qualifications. One is described as
follows:

Management discovered a bug that allowed orders that are re-issued with
modified domains within the Subject Alternative Name field of the
certificate to not include the Key Usage (KU) or Extended Key Usage (EKU)
extensions. This occurred between August 29 , 2016 and September 19, 2016.
Management noted 68 Certificates were affected, 4 of these are extended
validation certificates and 64 are organization validation certificates.
Management was not able to revoke all certificates within 24 hours, due to
customer requirements.

GlobalSign disclosed this problem at the time [1]. The other qualification
in the report is related to data backups. GlobalSign had another BR audit
conducted later in 2017, resulting in a clean report.
* GlobalSign was the subject of 4 misissuance bugs in 2017, as follows. All
have been resolved and this root was not involved in any of them.
** Bug 1353833 - GlobalSign: Incapsula issued a certificate for
non-existing domain (testslsslfeb20.me)
** Bug 1390997 - GlobalSign: Non-BR-Compliant Certificate Issuance -
metadata-only subject fields
** Bug 1393555 - GlobalSign: Non-BR-Compliant Certificate Issuance --
double-dots in dnsName
** Bug 1393557 - GlobalSign: Non-BR-Compliant Certificate Issuance -- RSA
key smaller than 2048 bits
* Minor CP and CPS issues were identified, noted in the bug, and fixed by
GlobalSign in the current versions.
* CPS section 3.2.7 indicates that GlobalSign uses “any other method” for
IP address validation. GlobalSign responded as follows In the bug: The only
“any other method” GlobalSign uses is email/phone verification via IANA
(ARIN RIPE, APNIC, LACNIC, AFRINIC) IP whois information.
* CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be
deprecated method 1 for domain validation. GlobalSign responded as follows
in the bug: We still use Method 1 in some cases, and are working to put new
processes in place to fully disable Method 1 by August.
* Earlier this year, there was a discussion related to forward-dating the
notBefore date in a certificate [2] that is valid for 3 years. This was
determined not to be a policy violation.

==Bad==
* CA generation of SSL key pairs is a Forbidden Practice [3]. Sections
6.2.10 of the CP and CPS state “As of March 1, 2018, GlobalSign does not
generate private keys for SSL certificates.“ In the submission of this
root, they stated "GlobalSign currently distributes private keys in PKCS#12
Files according to our CP/CPS 6.2. We are phasing out this practice, and
will cease distributing private keys for SSL certificates in this fashion
by the end of March 2018."

This begins the 3-week comment period for this request [4].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

- Wayne

[1] https://cabforum.org/pipermail/public/2016-October/008511.html
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/kkHWPJAi-Tg/nrZX7CIABAAJ
[3]
https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
[4] https://wiki.mozilla.org/CA/Application_Process