507360 - Add GlobalSign's SHA256 Root CA to Mozilla's trusted root list

Status: RESOLVED FIXED

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

Description

[Steve Roylance]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: 

GlobalSign would like to add the following SHA256 root to the NSS store

The root is primarily suitable for Server and Client Authentication, Secure e-mail, Code Signing and Timestamping, however the root itself is marked for all issuance policies and therefore can also be used for OCSP, Encrypting File System, IP Sec (Tunnel, User) and CA Encryption Certificate purposes.  All legal documents are located in the repository.  http://www.globalsign.com/repository/index.cfm.

The root should also be marked for EV.

Key extensions 
•	basicConstraints: CA: true
•	keyUsage: keyCertSign, cRLSign
Certificate File Information
GlobalSign Root CA – R3 (2029) DER.cer
Signature Algorithum
sha256WithRSAEncryption
Subject DN
CN = GlobalSign
O = GlobalSign
OU = GlobalSign Root CA – R3
Serial Number
‎‎04 00 00 00 00 01 21 58 53 08 A2
Subject KeyID
8f f0 4b 7f a8 2e 45 24 ae 4d 50 fa 63 9a 8b de e2 dd 1b bc
Validity time
Valid from 	: 18th March 2009 10:00:00
Valid to 	: 18th March 2029 10:00:00
Fingerprints
SHA1 	= D6 9B 56 11 48 F0 1C 77 C5 45 78 C1 09 26 DF 5B 85 69 76 AD
MD5 	= C5 DF B8 49 CA 05 13 55 EE 2D BA 1A C3 3E B0 28
URI to online CRL repository 
http://crl.globalsign.net/Root-r3.crl  (Not yet published)
URI to online location of the root 
http://secure.globalsign.net/cacert/Root-R3.crt 


Reproducible: Always

Comment 1

[Kathleen Wilson]

I am starting the information gathering and verification phase for this request, as described in
https://wiki.mozilla.org/CA:How_to_apply

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attaching the initial information gathering document which summarizes the information that has been gathered and verified.  Please review for accuracy and completeness.  Please also provide the information that is still needed as per the sections highlighted in yellow.

Comment 3

[Steve Roylance]

Hi Kathleen,

Here's my feedback concerning the information document.

1) Test Web Site.   We do not have a test web site yet, as we plan to keep this root certificate in a secure location for the next 18 months. (i.e. until handsets catch up to desktops and offer the ability to use SHA256), however we do need this seeding into browsers, both for ubiquity, but also as a security precaution such that if we do need to switch to a SHA256 root then we can do quickly.

2) CRLs are not yet produced, however they would follow the GlobalSign Policy of 6 months for a Root.  We never issue directly from the root.

3) OCSP will be provided on an 'as needed' basis.  So any certificate hierarchy that requires OCSP will have it.  The root itself will be used to sign OCSP responder certificates again every 6 months as with (2) above.   OCSP responses for EV end entity certificates will be compliant with CABForum guidelines.

4) Hierarchy.  The plan for this root will be very similar to the current product range.  i.e. specific separate intermediate issuing CAs for each product type.  (Especially EV)

5) External CA.  There may well be an opportunity to sign an external CA in the future.  If this does happen then the rules we follow today will apply.

6) We have no plans to cross sign another CA with this root.

7) Yes our audits have been completed.
https://cert.webtrust.org/ViewSeal?id=930  - AlphaSSL  (A GlobalSign brand)
https://cert.webtrust.org/ViewSeal?id=928  - WebTrust for CA
https://cert.webtrust.org/ViewSeal?id=929  - EV WebTrust for CA

Many thanks

Steve

Comment 4

[Kathleen Wilson]

Hi Steve,

Thank you for the information.

Based on prior requests, I believe that the following two items will be considered show stoppers for getting into the discussion and approval phases:

1) The new audits for WebTrust CA and WebTrust EV state that they are
…for the root CAs: “GlobalSign Root CA”, GlobalSign Root CA – R2” and “GlobalSign CA for Adobe”…
This request is for inclusion and EV-enablement of “GlobalSign Root CA – R3”.

2) A website (can be a test site) needs to be provided whose EV-SSL cert chains up to the root for which EV-enablement is being requested.

As such, I think this request should be put on hold until your audits are done next year, and those audits include this new root.

In regards to:
“seeding into browsers, both for ubiquity, but also as a security precaution such that if we do need to switch to a SHA256 root then we can do quickly.”

I haven’t seen this approach accepted in Mozilla. It may be worthwhile for you to start a discussion about it in mozilla.dev.security.policy so it gets considered.

Comment 5

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Comment 6

[Steve Roylance]

Attachment: GlobalSign's Certificate Policy Document - Digitally Signed

Revision 3.3 to 3.4 adds the SHA256 based R3 root under GlobalSign's WebTrust approved certificate hierarchy.

Comment 7

[Steve Roylance]

Attachment: GlobalSign's CPS - Digitally signed

Revision 6.4 to 6.5 adds support for SHA256 as a cryptographic technology in GlobalSign's WebTrust approved product range.

Comment 8

[Steve Roylance]

Hi Kathleen,  Sorry about the delay in the SHA256 web site.   We have a great deal of processes to put in place to be able to create a new product and hence the delay.   You can now test on https://2029.globalsign.com
Please note that this does not have OCSP responders, so you need to validate EV 'going' green with CRL logic.   Any questions please let me know and happy christmas ;-)

Comment 9

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 10

[Kathleen Wilson]

Thanks for providing the test web site.

This request is still in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 11

[Kathleen Wilson]

I am re-reviewing this request in preparation for the upcoming public discussion.

I had noted that the next audits would include this root. Are those audits in progress?

Comment 12

[Steve Roylance]

Hi Kathleen, 

Yes, the first meeting for 2010 was arranged for last week.   In reality the audit will continue through April and into May.   Due to timing we usually only receive the audit report and seals at the end of June, however I hope that it's not necessary to have the audit finalised to continue.  It is 100% in scope as we have alreday released a test certificate.  https://2029.globalsign.com

Comment 13

[Kathleen Wilson]

Thanks for the info. I hope to start the public discussion for this request within the next couple of weeks.  I'll post an update here in this bug when I start the discussion.

Comment 14

[Kathleen Wilson]

I am now opening the first public discussion period for this request from GlobalSign to add the “GlobalSign Root CA - R3” root certificate.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “GlobalSign Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of the CA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 15

[Kathleen Wilson]

The public discussion for this request is now closed. This request from GlobalSign is to add the “GlobalSign Root CA - R3” root certificate, and to enable all three trust bits. The request is to also enable EV. 

The discussion resulted in the following action items.

ACTION GlobalSign: Update GlobalSign's CP/CPS to more clearly explain the checks and balances that are in place for SubCAs.  This should include the requirements, nature of the audits, frequency and enforcement mechanism.  GlobalSign to post links to the updated CP/CPS in this bug, indicating how the CP/CPS have been modified to more clearly explain the checks and balances that are in place for their subCAs.

ACTION GlobalSign: Update GlobalSign's CP/CPS to address concerns about being compelled by third parties to inappropriately issue an intermediate or end-entity certificate. Post the links to the updated CP/CPS in this bug. Current recommendation from the discussions appears to be to provide information about which regulatory and legal framework/jurisdiction GlobalSign is primarily beholden to; and add a statement that GlobalSign will duly verify that an order from a government or other such organization is lawful before executing the order. 

I will start a second round of discussion after GlobalSign updates this bug with links to their modified policy documentation.

Comment 16

[Johan Sys]

Attachment: GlobalSign CPS 6.7 - added Compelled Attacks

Section 11.16 Compelled Attacks

Comment 17

[Johan Sys]

Attachment: GlobalSign CP 3.5 - SubCA Check and Balances

Section 10. Application of CP to TrustedRoot

Comment 18

[Johan Sys]

Hi Kathleen,

I have uploaded the updated CP and CPS addressing the actions points :

'ACTION GlobalSign: Update GlobalSign's CP/CPS to more clearly explain the
checks and balances that are in place for SubCAs.  This should include the
requirements, nature of the audits, frequency and enforcement mechanism. 
GlobalSign to post links to the updated CP/CPS in this bug, indicating how the
CP/CPS have been modified to more clearly explain the checks and balances that
are in place for their subCAs.'

This is addressed in Section 10 of the Certificate Policy and  small updates across the document.


'ACTION GlobalSign: Update GlobalSign's CP/CPS to address concerns about being
compelled by third parties to inappropriately issue an intermediate or
end-entity certificate. Post the links to the updated CP/CPS in this bug.
Current recommendation from the discussions appears to be to provide
information about which regulatory and legal framework/jurisdiction GlobalSign
is primarily beholden to; and add a statement that GlobalSign will duly verify
that an order from a government or other such organization is lawful before
executing the order.' 

This is addressed in section 11.16 of the Certificate Policy and 9.16 of the CPS.

All the best,  Johan

Comment 19

[Kathleen Wilson]

I am now opening the second public discussion period for this request from
GlobalSign to add the “GlobalSign Root CA - R3” root certificate.

For a description of the public discussion phase, see
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the
corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “GlobalSign Root Inclusion Request Round 2”

Please actively review, respond, and contribute to the discussion.

A representative of the CA must promptly respond directly in the discussion
thread to all questions that are posted.

Comment 20

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate Policy at

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

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request from GlobalSign to add the SHA256 “GlobalSign Root CA - R3” root certificate, and to enable all three trust bits. The request is to also enable EV.

Section 4 [Technical]. I am 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. The main documents of interest are the CP and CPS, which are in English.

** http://www.globalsign.com/repository/GlobalSign_CA_CP_v3.5.pdf
** http://www.globalsign.com/repository/GlobalSign_CPS_v6.7.pdf

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

* Email: 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. (CPS sections 1.3 to 1.7)

* SSL: GlobalSign verifies domain ownership/control as specified in the CPS in sections 1.8 (OrganizationSSL), 1.9 (DomainSSL), 1.10 (ExtendedSSL), and 3.3.2 (Documents used for subscriber registration).

* Code: GlobalSign verifies that the entity submitting the certificate signing request is the same entity referenced in the certificate. (CPS section 1.11)

* EV Policy OID: 1.3.6.1.4.1.4146.1.1
** Section 1.10 of GlobalSign’s CPS provides information about the steps taken to verify the identity of the certificate applicant and the organization using public records, as well as the ownership/control of the domain name. 

Section 13 [Certificate Hierarchy]. 
* This is a SHA256 version of the GlobalSign SHA1 root that is already included in NSS (approved in bug 406794).
* The plan for the hierarchy under this new root is to have internally-operated intermediate issuing CAs for each product type, including EV.
** In the future, it is possible that this root will sign externally operated sub-CAs. If this does happen then the rules followed today will apply. Subordinate CA requirements are described in the CPS, including following CPS and audits. (CPS section 1.10.7.3, CP section 10).
** There are no plans to cross sign another CA with this root.

Other: 

** GlobalSign issues CRLs (on a 3-hour schedule) and also plans to stand up an OCSP responder for this root when the root becomes active.
** For the EV root already in NSS the OCSP responder URL is: http://evssl-ocsp.globalsign.com/responder
** OCSP will be provided on an 'as needed' basis. So any certificate hierarchy that requires OCSP will have it. The root itself will be used to sign OCSP responder certificates. OCSP responses for EV end entity certificates will be compliant with CABForum guidelines.

** DV certs are valid for one to five years. (CPS section 1.9.1)
** GlobalSign uses designated Registration Authorities. (CP section 2.3.2)
** GlobalSign provides the option for generating the private key. (CPS section 1.9.6)
** IP addresses may be incorporated as a Subject Alternative Name extension. (CPS section 1.9.4)

Section 8-10 [Audit]. 
GlobalSign is audited annually by Ernst & Young. The 2010 audits are posted on the cert.webtrust.org website. 
** WebTrust CA: https://cert.webtrust.org/SealFile?seal=928&file=pdf
** WebTrust EV: https://cert.webtrust.org/SealFile?seal=929&file=pdf

Based on this assessment I intend to approve this request to add the “GlobalSign Root CA - R3” root certificate, enable all three trust bits, and enable EV.

Comment 21

[Kathleen Wilson]

To the representatives of GlobalSign: Thank you for your cooperation and your
patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #20, and on behalf of the Mozilla project I
approve this request from GlobalSign to include the following root certificate in Mozilla:

* GlobalSign Root CA - R3 (web sites, code signing, email), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.

Comment 22

[Kathleen Wilson]

I have filed bug 582375 against NSS and bug 582381 against PSM for the actual changes.

Comment 23

[Daniel Veditz [:dveditz]]

(In reply to comment #20)
> * SSL: GlobalSign verifies domain ownership/control as specified in the CPS in
> sections 1.8 (OrganizationSSL), 1.9 (DomainSSL), 1.10 (ExtendedSSL), and 3.3.2
> (Documents used for subscriber registration).

Section 1.10.5(2) says they will ensure "Applicant's exclusive control of the domain name and applicable Subject Alternative Name domains to be included in certificate".

How did they verify that for 192.168.100.1 in the cert they issued to https://mail.designboard.com/ ? I'm pretty sure I've got control of the 192.168.100.1 I can see from here, which makes the Applicant's control sound less than "exclusive".

Comment 24

[Kai Engert [:KaiE:]]

(In reply to comment #23)
> How did they verify that for 192.168.100.1 in the cert they issued to
> https://mail.designboard.com/ ? I'm pretty sure I've got control of the
> 192.168.100.1 I can see from here, which makes the Applicant's control sound
> less than "exclusive".

I've filed bug 586414 to track/investigate this incident.

Comment 25

[Kathleen Wilson]

I have confirmed that the following root cert is a Builtin Object Token in Firefox 3.6.12. 

CN: GlobalSign
SHA1: D6:9B:56:11:48:F0:1C:77:C5:45:78:C1:09:26:DF:5B:85:69:76:AD 

In bug 582381 the change has been checked-in to enable EV in the PSM.