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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy