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
