406794 - Refresh the GlobalSign Root CA cert (will be EV)

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Steve Roylance]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Not Applicable

GlobalSign would like to refresh the current Root CA that we have within the NSS.   The refreshed root is exactly the same as the current Root, with the exception of the Serial Number and the Valid to date, which has been pushed up to 2028 from 2014.   The current GlobalSign Root CA is here:-
http://secure.globalsign.net/cacert/Root.crt

The new 'refreshed' Root is here:-
http://secure.globalsign.net/cacert/Root-R1.crt

A cryptographic comparison of the public keys will suffice here to highlight the new root is indeed a refreshed replacement.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Frank Hecker]

Steve, just to clarify: You don't want a simple refresh, you want a refresh (this cert replacing the old cert) followed by an upgrade of the new cert for EV use. Is this correct? (It seems to be based on your comments in bug 406796.) That's fine by me, but I just want to double-check this.

Comment 2

[Frank Hecker]

More double-checking:

1. The old GlobalSign Root CA cert expires on January 28, 2014, has serial number:

02 00 00 00 00 00 D6 78 B7 94 05

and has SHA-1 fingerprint:

2F 17 3F 7D E9 96 67 AF A5 7A F8 0A A2 D1 B1 2F AC 83 03 38

2. The refreshed GlobalSign Root CA cert expires on January 28, 2028, has serial number:

04 00 00 00 00 01 15 4B 5A C3 94

and has SHA-1 fingerprint:

B1 BC 96 8B D4 F4 9D 62 2A A8 9A 81 F2 15 01 52 A4 1D 82 9C

Both certs have the same public key:

DA 0E E6 99 8D CE A3 E3 4F 8A 7E FB F1 8B 83 25 6B EA 48 1F F1 2A B0 B9 95 11 04 BD F0 63 D1 E2 67 66 CF 1C DD CF 1B 48 2B EE 8D 89 8E 9A AF 29 80 65 AB E9 C7 2D 12 CB AB 1C 4C 70 07 A1 3D 0A 30 CD 15 8D 4F F8 DD D4 8C 50 15 1C EF 50 EE C4 2E F7 FC E9 52 F2 91 7D E0 6D D5 35 30 8E 5E 43 73 F2 41 E9 D5 6A E3 B2 89 3A 56 39 38 6F 06 3C 88 69 5B 2A 4D C5 A7 54 B8 6C 89 CC 9B F9 3C CA E5 FD 89 F5 12 3C 92 78 96 D6 DC 74 6E 93 44 61 D1 8D C7 46 B2 75 0E 86 E8 19 8A D5 6D 6C D5 78 16 95 A2 E9 C8 0A 38 EB F2 24 13 4F 73 54 93 13 85 3A 1B BC 1E 34 B5 8B 05 8C B9 77 8B B1 DB 1F 20 91 AB 09 53 6E 90 CE 7B 37 74 B9 70 47 91 22 51 63 16 79 AE B1 AE 41 26 08 C8 19 2B D1 46 AA 48 D6 64 2A D7 83 34 FF 2C 2A C1 6C 19 43 4A 07 85 E7 D3 7C F6 21 68 EF EA F2 52 9F 7F 93 90 CF

Steve, can you confirm I have this right?

Comment 3

[Steve Roylance]

Yes Frank.  That is correct.

Comment 4

[Frank Hecker]

(In reply to comment #3)
> Yes Frank.  That is correct.

Thanks for confirming this. Note that I'm marking this bug as blocking bug 406796, since the refresh needs to happen before the root is upgraded for EV.

Comment 5

[Steve Roylance]

Dear all.   As well as updating and refreshing the root cert we need to ensure the usage of the root is marked correctly.  Within the current versions of Firefox the root is marked only for SSL.  In fact the root can be used for all purposes possible.  i.e. SMIME/SSL/Code/Time stamping etc.  If there is a full list avaialable to which we can agree to each possible usage I'd apprecaite it.   Also it should be noted that this new rereshed root and our existing root (Serial Number 04 00 00 00 00 01 0f 86 26 e6 0d
Valid from 	: 15 December 2006 08:00:00
Valid to 	: 15 December 2021 08:00:00
Fingerprints
SHA1 	= 75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE 
MD5 	= 94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30) should also have the same usage critera marked.  

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I'm marking this as an EV bug, since the cert is to become an EV cert.
(Personally, I think this bug and bug 406796 should be combined)

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the information in this request is incomplete. 
The request is waiting for more information from the applicant.

Comment 8

[Frank Hecker]

Assigning this to Kathleen Wilson, who will gather more information as needed.

Comment 9

[Kathleen Wilson]

Hi Steve,

As per Frank’s note, I have been asked to gather and verify information for this request.  As such, I have the following questions.

1) What is the maximum CRL update frequency for end-entity certificates issued from this CA?

2) Is OCSP enabled?  If not, are you planning to enable OCSP for this root? Or are you waiting for
https://bugzilla.mozilla.org/show_bug.cgi?id=413997
to be fixed so this root can be EV-enabled without having OCSP?

3) Could you provide a hierarchy diagram for this root, and/or provide:
a) List of subordinate CAs operated internally. 
b) List subordinate CAs operated by third parties, if any. (not RA's, but were the CA is truly operated by the 3rd-party)
c) List any other root CAs that have issued cross-signing certificates for this root CA

4) Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root?

5) Has the WebTrust EV audit been completed? If yes, would you please provide the url to the audit report, or attach to this bug?

6) One of the things I’m supposed to do is to verify that the CP/CPS clearly state that the ownership of the domain name is checked for SSL, and that for email certs the email account associated with the email address in the cert is owned by the subscriber. I found the domain check for SSL, but could you please point me to the text regarding the ownership of the email address?

Thanks,
Kathleen

Comment 10

[Steve Roylance]

(1) We issue our CRL's every 3 hours.
(2) We will be implementing OCSP soon, but not yet, so yes in effect we are waiting for the OCSP bug to be fixed.
(3) The personal certificate subordinate CAs are all being changed to move to a 3 tier hierarcy in August/September.  At the moment we have a 4 certificate hierarcy for our product range with separate issuing CA's for PersonalSign Class 1,2,3 and ObjectSign.  We already have a 3 certificate hierarchy for our Server Certificates. DomainSSL, OrganizationSSL and EntendedSSL.  
(4) The root key material is the same as the previous root it replaces so https://www.globalsign.com will work.
(5) The WebTrust audit is due to be completed this week with a report being published on the 20th June.  The auditor has been changed from Deloitte to Ernst & Young.
(6) We instigated a change to the CPS to make it more obvious.  Version 6.1 will be published next week.  Both for http based and API based requests we do a challenge response to the e-mail.  The HTTP method dis not specifically state to date so this is what we changed, however the API method in section 1.5.2 specifically states:-
"Upon verification of identity, GlobalSign either directly or via the API issues the certificate or sends such certificate to the e-mail address from which the certificate application had originated."

Comment 11

[Steve Roylance]

To address other concerns raised.

Q1. Are there technical restrictions imposed on the subordinates? For example, are their CA certificates configured to not allow additional subordinates to be created? Are domain name constrains used to prevent them from issuing SSL certs outside of the enterprise domain(s)?

A1. Yes, with the exception of one extremely well known brand, all CA issuing certificates are signed such that they can only issue end entity certs and not create additional CAs.  As a CA is then run by an enterprise, domains are not technically restricted, however domains are contractually restricted.

Q2. How are the subordinates audited (if at all) for compliance with the T&C or other agreements? 

A2. GlobalSign audits periodically as part of our own brand protection program.  It also helps to ensure the lastest certificate end entity profile information is provided to our enterprise partners to improve interoperability of the certificates in the majority of systems/appliances.

I hope this addresses any concerns that the Mozilla community may have on how GlobalSign conducts its business.  We value our roots and they trust they indicate far too highly to allow certificates to be issued from them that do not meet our exacting standards for verification and validation. 

Comment 12

[Steve Roylance]

To answer the question

"List any other root CAs that have issued cross-signing certificates for this root CA"

GlobalSign is not cross signed by or with any other certification authorities.

Comment 13

[Kathleen Wilson]

Attachment: Summary of Info Gathered/Verified 6/12/2008

With the exception of the pending WT/EV audit, the info gathering/verification phase of this request is complete.

Comment 14

[Steve Roylance]

Kathleen.

The WebTrust audit by E&Y has been issued and is avaialble here:-

http://www.globalsign.com/repository/webtrust_for_ev_ssl.pdf

Thanks

Steve

Comment 15

[Steve Roylance]

Attachment: WebTrust EV Audit - GlobalSign

The WebTrust EV report is attached.

Comment 16

[Frank Hecker]

Attachment: GlobalSign information checklist (PDF format)

This is a PDF version of the latest informational document on GlobalSign, as collected and verified by Kathleen Wilson. Note that two additional pieces of information were received after creation of this document:

WebTrust EV report URL:
  http://www.globalsign.com/repository/webtrust_for_ev_ssl.pdf

OCSP URL:
  http://evssl-ocsp.globalsign.com/responder

Comment 17

[Frank Hecker]

I think we now have all the information we need to start the first public comment period for this request, so I'm formally declaring it open. Based on prior experience I'm going to fine-tune things a bit and set this first comment period at a week long, unless we need more time. So my tentative plan is to make a preliminary decision on these requests late next week.

Comment 18

[Frank Hecker]

Reassigning this bug to myself.

Comment 19

[Frank Hecker]

The first public comment period for this request is now over. I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at

  http://www.mozilla.org/projects/security/certs/policy/

On behalf of the Mozilla project, I apologise for any delay.

Here follows my assessment. If anyone sees any factual errors, please point them out.

Note that this assessment is specifically for the request to refresh the GlobalSign Root CA certificate already present in Mozilla (i.e., to replace the present certificate with a new certificate with a later expiry date). There is a separate request to upgrade the GlobalSign Root CA certificate for EV use; I'll address that request in my next comments on bug 406796, along with the request to upgrade the GlobalSign Root CA - R2 cert for EV use.

Also note that the GlobalSign Root CA certificate is a legacy root that has been present since before we adopted our current Mozilla policy. For that reason I'm going to include an review of GlobalSign's practices in relation to our policy.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by GlobalSign, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. GlobalSign appears to provide a service relevant to Mozilla users: It's a commercial CA offering certificates to the general public worldwide. Policies are documented in the documents published on their website and listed in the entry on the pending applications list. Of these the most relevant for present purposes is the CPS:

http://www.globalsign.com/repository/GlobalSign_CPS_v6.0.pdf

Section 7 [Validation]. GlobalSign appears to meet the minimum requirements for subscriber verification, as follows:

    * Email: For certificates with the E-mail Protection EKU (1.3.6.1.5.5.7.3.4), GlobalSign verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate, using an email-based challenge/response mechanism. (See the discussion of this point in the GlobalSign information checklist attached to this bug.) 

    * SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), GlobalSign verifies domain ownership/control by various mechanisms. (See, among others, sections 1.9 and 3.3.1.7 of the CPS.) 

    * Code: For certificates with the Code Signing EKU (1.3.6.1.5.5.7.3.3) 
GlobalSign verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (See sections 1.10 and 3.3.1.10 of the CPS.)

Section 8-10 [Audit]. GlobalSign has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Ernst & Young. The audit is current (covering the period up to March 31, 2008).

Section 13 [Certificate Hierarchy]. GlobalSign has multiple intermediate CAs under a single root. Different types of certificates (e.g., personal vs. SSL vs. object signing) and different classes of certificates (e.g., personal class 1 vs. class 2, DV SSL vs. OV vs. EV) are issued by different subordinates.

Other: GlobalSign issues CRLs (on a 3-hour schedule) and also plans to stand up an OCSP responder in future.

Potentially problematic practices: As noted in the information checklist document, the only potentially problematic practice associated with GlobalSign is authorization of third parties to operate subordinate CAs. As noted in the information checklist document, GlobalSign exercises contractual control and audit oversight over the practices of such subordinates.

Based on the information available to me I am minded to approve this request to add the new (refreshed) GlobalSign Root CA certificate. Before I issue my final decision, I'm opening up a second one-week period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1].

[1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable
newsreaders at:

  news://news.mozilla.org/mozilla.dev.tech.crypto

via email by subscribing to the associated mailing list:

  https://lists.mozilla.org/listinfo/dev-tech-crypto

and via the web at:

  http://groups.google.com/group/mozilla.dev.tech.crypto/topics

Comment 20

[Frank Hecker]

The second comment period is now over. Based on my evaluation and the comments received thus far, I am officially approving this specific request to refresh the GlobalSign Root CA certificate already present in Mozilla (i.e., to replace the present certificate with a new certificate with a later expiry date)., and have filed bug 446407 against NSS for the actual change.

Comment 21

[Frank Hecker]

Marking as RESOLVED FIXED. The new root is included in Firefox 3.0.2.