Re: GlobalSign Root CA - R6 Inclusion Request

[Wayne Thayer]

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 <wth...@mozilla.com> 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
>

[Wayne Thayer]

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