3 weeks have passed and no comments have been made on this inclusion request. Meanwhile, I have requested and received additional information from GlobalSign confirming that this root certificate has been included in their BR audits back to its creation [1], in compliance with section 7.1 of version 2.6 of the Mozilla Root Store Policy.
I intend to approve this request. I am now closing this discussion. Any further follow-up should be added directly to the bug [2]. - Wayne [1] https://bugzilla.mozilla.org/attachment.cgi?id=8992927 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1390803 On Mon, Jul 16, 2018 at 2:28 PM Wayne Thayer <[email protected]> wrote: > Reminder: this request will complete the 3-week minimum discussion period > on Thursday. If you have any comments on this request, please post them > before July 19th. > > On Thu, Jun 28, 2018 at 12:16 PM Wayne Thayer <[email protected]> wrote: > >> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
