Closed Bug 1390803 Opened 2 years ago Closed 10 months ago

Add "GlobalSign Root CA - R6" root certificate

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: koichi.sugimoto, Assigned: wayne)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.39, FF 63. EV-enabled in FF 64)

Attachments

(7 files, 2 obsolete files)

31.04 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
157.88 KB, application/pdf
Details
36.49 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
516.00 KB, application/pdf
Details
2.66 MB, application/pdf
Details
2.22 MB, application/pdf
Details
510.50 KB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce:

GlobalSign created an new root CA certificate with RSA4096 key.
The new root certificate can be downloaded via our repository: 
https://secure.globalsign.net/cacert/root-r6.crt

https://support.globalsign.com/customer/en/portal/articles/1426602-globalsign-root-certificates


Actual results:

The certificate is not included in NSS, Firefox, etc.



Expected results:

The root certificate should be included into NSS.
The target security services are:
SSL (including EV), Time stamping, S/MIME, Code signing etc.
Koichi, Please provide the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist
Assignee: kwilson → awu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - Need BR Self Assessment
Attached as part of GlobalSign Root R6 Certificate inclusion to Mozilla products.
I have just uploaded our company checklist according to Mozilla root inclusion policy process. Our BR Self-Assessment was recently submitted to/approved by Kathleen Wilson on 12/19/2017. Let me know if you have any questions!
(In reply to Julie Olson from comment #3)
> I have just uploaded our company checklist according to Mozilla root
> inclusion policy process. Our BR Self-Assessment was recently submitted
> to/approved by Kathleen Wilson on 12/19/2017. Let me know if you have any
> questions!

Oh, I thought the BR Self-Assessment that you emailed to me was in regards to the CA Communication.

Please also attach your BR Self-Assessment to this bug, as it is part of our root inclusion/update process.

Thanks.
GlobalSign BR Self-Assessment as part of Root R6 inclusion process
(In reply to Julie Olson from comment #5)
> Created attachment 8941595 [details]
> CA's BR Self Assessment_GlobalSign.xlsx
> 
> GlobalSign BR Self-Assessment as part of Root R6 inclusion process

Thanks! 

I will update this bug when I do the review as per step 2 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Note that it may take me a few weeks to get to this. I apologize in advance for the delay.
Assignee: awu → kwilson
Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - BR Self Assessment Provided
Hello Kathleen, I was hoping you could provide a status update on your review of our root inclusion request?

Thanks,
Julie.
(In reply to Julie Olson from comment #7)
> Hello Kathleen, I was hoping you could provide a status update on your
> review of our root inclusion request?
> 
> Thanks,
> Julie.

I'm currently 4 months behind on reviewing CA updates to this type of bug.
Hi Kathleen,

We realized we accidentally forgot to include one admin CA to the R6 hierarchy. I'm uploading an updated checklist with the correct hierarchy, plus updated POC details.

The CA is publicly disclosed in CCADB, and will be depreciated next month.
Attachment #8941556 - Attachment is obsolete: true
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - BR Self Assessment Provided → [ca-cps-review] - KW 2018-03-27
Our CP/CPS has been updated as of today, 4/3/2018. New URLs are:

CP: https://downloads.globalsign.com/acton/attachment/2674/f-0a61/1/-/-/-/-/GlobalSign_CP_v5_7_RELEASED.pdf
CPS: https://downloads.globalsign.com/acton/attachment/2674/f-0a60/1/-/-/-/-/GlobalSign_CA_CPS_v8_7_RELEASED.pdf

In addition, I'm uploading a new copy (v6) of our checklist, with updated URLs and section references to the new documents.
Attachment #8959151 - Attachment is obsolete: true
I've begun reviewing this request and have a few questions:
* can you provide a copy of GlobalSign's 2015-2016 BR audit statement listing this root?
* are GlobalSign's CAA issuer domains listed in the CP or CPS? If not, would you like to add them before this goes to public discussion? This is a requirement of BR section 2.2.
* the CPS change log for version 8.7 says that it now specifies that GlobalSign no longer generates keys for SSL certificates. Can you point me to the language that was added to the CPS?
* CPS section 3.3.1 references re-verification of re-key requests every 5 years rather than every 825 days. Do you want to fix this before this goes to public discussion?
Flags: needinfo?(julie.olson)
I've completed my initial review and have documented 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. “

==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 August29 , 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 was the subject of 3 misissuance bugs in 2017 [2], but all have been resolved.
CP and CPS section 3.3.1 references re-verification of re-key requests every 5 years rather than every 825 days.
The CP and CPS reference “IntranetSSL” certificates in multiple places, and section 3.2.4 of both documents references a BR sunset that has long since passed but in so doing implies that these certificates are still being issued. Suggest updating/clarifying this in the CPS.
CPS section 3.2.7 indicates that GlobalSign uses “any other method” for IP address validation. 
CPS section 3.2.7 indicates that GlobalSign still uses the soon-to-be deprecated methods 1 and 5 for domain validation.

==Bad==
Section 6.2.10 of the CP and CPS states “As of March 1, 2018, GlobalSign does not generate private keys for SSL certificates.“ Implying that prior to that date, GlobalSign did this in violation of Mozilla’s Forbidden Practice [3]


I will proceed with this request once a GlobalSign representative responds to my questions in comment #13.

[1] https://cabforum.org/pipermail/public/2016-October/008511.html
[2] https://wiki.mozilla.org/CA/Closed_Incidents
[3] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKCS.2312_Files
Hi Wayne,

I have answered all your questions in-line below; please let me know if you have any follow-up questions.

(In reply to Wayne Thayer [:wayne] from comment #13)
> I've begun reviewing this request and have a few questions:
> * can you provide a copy of GlobalSign's 2015-2016 BR audit statement
> listing this root?
Yes, I have attached it to this bug.

> * are GlobalSign's CAA issuer domains listed in the CP or CPS? If not, would
> you like to add them before this goes to public discussion? This is a
> requirement of BR section 2.2.
Please refer to Section 4.2.1: "GlobalSign validates each server FQDN in publicly trusted SSL certificates against the domain's CAA records. If a CAA record exists that does not list globalsign.com as an authorized CA, GlobalSign will not issue the certificate." GlobalSign's CAA issuer domain is "globalsign.com." We are in the final stages of publishing a new version of our CP/CPS and have made this more clear in the documentation. I will update the link to our new CP/CPS when it's published.

> * the CPS change log for version 8.7 says that it now specifies that
> GlobalSign no longer generates keys for SSL certificates. Can you point me
> to the language that was added to the CPS?
Please refer to Section 6.2.10: "As of March 1, 2018, GlobalSign does not generate private keys for SSL certificates." We are in the final stages of publishing a new version of our CP/CPS and have made this statement more clear in the documentation. I will update the link to our new CP/CPS when it's published.

> * CPS section 3.3.1 references re-verification of re-key requests every 5
> years rather than every 825 days. Do you want to fix this before this goes
> to public discussion?
Yes please! We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

(In reply to Wayne Thayer [:wayne] from comment #14)
> I've completed my initial review and have documented 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. “
> 
> ==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 August29 , 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 was the subject of 3 misissuance bugs in 2017 [2], but all have
> been resolved.
> CP and CPS section 3.3.1 references re-verification of re-key requests every
> 5 years rather than every 825 days.
See above; We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

> The CP and CPS reference “IntranetSSL” certificates in multiple places, and
> section 3.2.4 of both documents references a BR sunset that has long since
> passed but in so doing implies that these certificates are still being
> issued. Suggest updating/clarifying this in the CPS.
Noted. We are in the final stages of publishing a new version of our CP/CPS and have corrected this statement in the documentation. I will update the link to our new CP/CPS when it's published.

> CPS section 3.2.7 indicates that GlobalSign uses “any other method” for IP
> address validation. 
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 methods 1 and 5 for domain validation.
We do not use Method 5 any longer and have removing the method in the next CP/CPS version. We still use Method 1 in some cases, and are working to put new processes in place to fully disable Method 1 by August.
> 
> ==Bad==
> Section 6.2.10 of the CP and CPS states “As of March 1, 2018, GlobalSign
> does not generate private keys for SSL certificates.“ Implying that prior to
> that date, GlobalSign did this in violation of Mozilla’s Forbidden Practice
> [3]
As part of the Self assessment we identified this deficiency, and following a discussion on the MDSP list, we ended this practice for publicly trusted SSL/TLS certificates in March 2018.
> 
> 
> I will proceed with this request once a GlobalSign representative responds
> to my questions in comment #13.
> 
> [1] https://cabforum.org/pipermail/public/2016-October/008511.html
> [2] https://wiki.mozilla.org/CA/Closed_Incidents
> [3]
> https://wiki.mozilla.org/CA/
> Forbidden_or_Problematic_Practices#Distributing_Generated_Private_Keys_in_PKC
> S.2312_Files
Flags: needinfo?(julie.olson)
Whiteboard: [ca-cps-review] - KW 2018-03-27 → [ca-cps-review] - Pending CPS Updates 2018-05-24
Hi Wayne,

Attached is a copy of our updated CPS v8.8. It has changes that address the deficiencies/questions you identified during your previous review of v8.7.

We are ready to proceed with the next step of the root embedding process.
Attached file GlobalSign CP v5.8.PDF
Hi Wayne,

Attached is a copy of our updated CP v5.8. It has changes that address the deficiencies/questions you identified during your previous review of v5.7.

We are ready to proceed with the next step of the root embedding process.
Julie: can you provide a BR audit report for the April 1, 2015 - March 31, 2016 period?
Hi Wayne,

The requested audit report is attached to this bug, "16 - GlobalSign - WebTrust Baseline Requirements 2015-16"

Thanks,
Julie.
Public discussion has begun: https://groups.google.com/d/msg/mozilla.dev.security.policy/gMnbLOpggRw/X-jWH2SsBgAJ
Whiteboard: [ca-cps-review] - Pending CPS Updates 2018-05-24 → [ca-in-discussion] - ends no sooner than 19-July-2018
(In reply to Julie Olson from comment #20)
> Hi Wayne,
> 
> The requested audit report is attached to this bug, "16 - GlobalSign -
> WebTrust Baseline Requirements 2015-16"
> 
> Thanks,
> Julie.

Julie: Since this root was created in December 2014, I should have also asked for GlobalSign's 2014-2015 BR audit report. Can you attach a copy of that as well?
Flags: needinfo?(julie.olson)
Hi Wayne,

Attached is our audit report from 2014-2015. Let me know if you need anything else.
Flags: needinfo?(julie.olson)
This request has completed its 3-week public comment period with no comments received.

I have posted my intention to approve this root inclusion request (https://groups.google.com/d/msg/mozilla.dev.security.policy/xnzoZvZc4FM/RcqmOP4CCAAJ).

For reference, here is the information posted to begin the public comment period:

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."
Whiteboard: [ca-in-discussion] - ends no sooner than 19-July-2018 → [ca-pending-approval]
As per the summary in Comment #24, and on behalf of Mozilla I approve this request from GlobalSign to include the following root certificate:

** 'GlobalSign Root CA - R6' (Email, Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1478476
Depends on: 1478480
I have filed bug #1478476 against NSS and bug #1478480 against PSM for the actual changes.
Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - In NSS 3.39, FF 63 -- Pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
QA Contact: kwilson
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.39, FF 63 -- Pending PSM code changes → [ca-approved] - In NSS 3.39, FF 63. EV-enabled in FF 64
You need to log in before you can comment on or make changes to this bug.