825954 - Add GlobalSign's ECC Roots to Mozilla's root store

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Steve Roylance]

Attachment: Root R4 and R5 in Base64 CER and DER format

Bug 783536 was stopped as the previous ECC roots had a Null when decoded.  New roots have been created which do not have the issue.

General Information Section:-

1 Name - GlobalSign NV/SA
2 WebSite URL - https://www.globalsign.com
3 Organization Type - GlobalSign is a Privately owned Organization, issuing certificates to the Public
4 Primary Market/customerbase - GlobalSign provides Businesses and Individuals with SSL,SMIME and code signing certificates as we have done for well over a decade.
5 Impact to Mozilla Users - In the event of a security issue with RSA or a need to move to ECC for speed or compatibility reasons GlobalSign would like to move to products based around our 2012 ECC roots (We already have 3 2048 bit RSA roots embedded).  Embedding these new roots prior to any known issues offers mozilla users a better experience in the future should any issues happen requiring GlobalSign's current global customer base to update their certificates.
6 CA Contact Information. - 

United States & Canada
GMO GlobalSign Inc
Two International Drive
Suite 330, Portsmouth
New Hampshire 03801
Toll Free: 1-877-SSLGLOBAL
Fax: [phone]
Lila Kee - [e-mail]

EMEA
GMO GlobalSign Ltd
Springfield House
Sandling Road, Maidstone, Kent
ME14 2LP, United Kingdom
Tel: [phone]
Fax: [phone]
Steve Roylance - [e-mail]

Japan and APAC
Cerulean Tower 10F
26-1 Sakuragaokacho, Shibuya-ku,
Tokyo 150-8512, Japan
Tel: [phone]
Fax:[phone]
Atsushi Inaba - [e-mail]

Technical Details about each root.

Root 1 of 2
1 Friendly Name - GlobalSign ECC Root CA - R4
2 Certificate Issuer Field - CN = GlobalSign, O = GlobalSign, OU = GlobalSign ECC Root CA - R4 which follows the format of our Root R2 and R3 which are already embedded into Mozilla's program, adding ECC to the OU description
3 Certificate Summary - 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. The root is based on Elliptic Curve Cryptography.
4 Root Certificate URL - https://secure.globalsign.net/cacert/Root-R4.crt
5 Fingerprints - 
   SHA1(DER) = 6969562e4080f424a1e7199f14baf3ee58ab6abb
   SHA1(BASE64) = 05af56e52dd5ca596d46c2a67f2007822c1dec32
   SHA256(DER) = bec94911c2955676db6c0a550986d76e3ba005667c442c9762b4fbb773de228c
6 Valid from - ‎13 ‎November ‎2012 00:00:00
7 Valid to - 19 January 2038 03:14:07
8 Certificate Version - 3
9 Certificate Signature Algorithm - SHA256
10 Signing Key parameters - NIST Curve P-256
11 Test Web Site URL - https://2038r4.globalsign.com
12 n/a
13 Certificate Revocation List - http://crl.globalsign.com/root-r4.crl is issued from the Root and it follows the CABForum needs.  Production certificates will be issued via an intermediate with CRLs every 3 hours as per GlobalSign's other products.
14 OCSP - OCSP will be supported as these roots must be marked for EV support.  The test certificate does not currently have an OCSP responder.  As with CRLs the OCSP responders will be CABForum compliant as they are for Production products.  It will be uneconomic to create a full OCSP service just for the purpose of testing as GlobalSign already provides EV compliant certificates and is familiar with the Mozilla needs.
15 Requested Trust Bits - Please enable for all (SSL/TLS and CodeSigning as per Root R1,R2 and R3)
16 SSL Validation Type - As no plans are yet available for this root it is unknown if DV/OV/EV will be necessary, however as an assumption, all three types need to be allowed.
17 GlobalSign's EV Policy OID is 1.3.6.1.4.1.4146.1.1

Root 2 of 2
1 Friendly Name - GlobalSign ECC Root CA - R5
2 Certificate Issuer Field - CN = GlobalSign, O = GlobalSign, OU = GlobalSign ECC Root CA - R5 which follows the format of our Root R2 and R3 which are already embedded into Mozilla's program.
3 Certificate Summary - 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. The root is based on Elliptic Curve Cryptography.
4 Root Certificate URL - https://secure.globalsign.net/cacert/Root-R5.crt
5 Fingerprints - 
  SHA1(DER) = 1f24c630cda418ef2069ffad4fdd5f463a1b69aa
  SHA1(BASE64) = eda599483181712ff6141f6f246f91c6391e7a5b
  SHA256(DER) = 179fbc148a3dd00fd24ea13458cc43bfa7f59c8182d783a513f6ebec100c8924
6 Valid from - 13 ‎November ‎2012 00:00:00
7 Valid to - 19 January 2038 03:14:07
8 Certificate Version - 3
9 Certificate Signature Algorithm - SHA384
10 Signing Key parameters - NIST Curve P-384
11 Test Web Site URL - https://2038r5.globalsign.com
12 n/a
13 Certificate Revocation List - http://crl.globalsign.com/root-r5.crl is issued from the Root and it follows the CABForum needs.  Production certificates will be issued via an intermediate with CRLs issued every 3 hours as per GlobalSign's other products.
14 OCSP - OCSP will be supported as these roots must be marked for EV support.  the test certificate does not currently have an OCSP responder.  As with CRLs the OCSP responders will be CABForum compliant as they are for Production products.  It will be uneconomic to create a full OCSP service just for the purpose of testing as GlobalSign already provides EV compliant certificates and is familiar with the Mozilla needs.
15 Requested Trust Bits - Please enable for all (SSL/TLS and CodeSigning as per Root R1,R2 and R3)
16 SSL Validation Type - As no plans are yet available for this root it is unknown if DV/OV/EV will be necessary, however as an assumption, all three types need to be allowed.
17 GlobalSign's EV Policy OID is 1.3.6.1.4.1.4146.1.1

CA Hierarchy - No plans have been made for this root regarding specific products or services.  In a worst case scenario where RSA is deemed insecure then ECC products will need to replace all current products.   It is unlikely that this root will be used to sign 3rd parties as the ubiquity will not be sufficient for several years.

Verification Policies and Practices
1) All GlobalSign's documentation is in English and is here:-
GlobalSign Certificate Policy (CP)
Current version - v4.3 - July 17th 2012 (This will be updated in early january to cover the new ECC roots) https://www.globalsign.com/repository/GlobalSign_CP_v4.3.pdf
Previous version - v4.2 - June 7th 2012 https://www.globalsign.com/repository/GlobalSign_CP_v4.2.pdf
GlobalSign CA Certification Practice Statement (CPS)
Current version - v7.3 - July 17th 2012 https://www.globalsign.com/repository/GlobalSign_CA_CPS_v7.3.pdf
Previous version - v7.2 - June 7th 2012 https://www.globalsign.com/repository/GlobalSign_CA_CPS_v7.2.pdf
Subscriber Agreements
Subscriber Agreement - Digital Certificates and Services - Version 2.3  - https://www.globalsign.com/repository/globalsign-subscriber-agreement-digital-certificates-and-services.pdf
Relying Party Agreement
Relying Party Agreement v1.2 https://www.globalsign.com/repository/GlobalSign_Relying_Party_Agreement_v1.2.pdf
2) Audits - GlobalSign's latest WebTrust seal for 2011/2012 does not include these roots, as the report cannot be re-issued with new serial numbers. The roots have been issued under the same security world as witnessed by the auditors and therefore will be entered into the report in June 2013.   The current report is here:- https://cert.webtrust.org/ViewSeal?id=1314 
The report from E&Y is here:- https://cert.webtrust.org/SealFile?seal=1314&file=pdf 

3) SSL Verification Procedures are covered in our CPS -
The domain verification section is at the top of page 27 in section 3.2.2
We confirm that we have automatic blocks in place for high value brands and domains.
For OV vetting details are at the bottom of page 26 again section 3.2.2
In order to understand our processes as a whole then section 3.2 must be reviewed
EV practices are provided in the CABForum EV guidelines and are not therefore duplicated into the GlobalSign CPS.  Section 3.2.2.3 makes this statement.  

4) Email Address Verification Procedures
Section 3.2.3 relates to e-mail products.  Control must be demonstrated by applicants.

5) Code Signing Verification Procedures
As with other products, code signing is covered in section 3.2.

6) Multi Factor Authentication.
GlobalSign uses multi factor authentication systems for it's own internal processes.  GlobalSign's end customers are provided with an account that is locked to a specific domain/e-mail address that will have been verified prior to any initial issuance of a certificate.  Re-issuance (Re-Key within the operating period of an issued certificate) is covered in the CPS with authentication into the account via a user name and password.  Re-new is currently not supported.  Full validation is necessary.

7) Network Security
GlobalSign was unfortunately the target of an attack in September 2011.  GlobalSign took the threat seriously and closed our issuance services to be sure we could protect our customers and their relying parties.  We continued business on the basis of regular internal audits, checking issuance of high profile domains and IDS.   We also hired a respected CTO to help bolster the management team and our revocation services which are now one of the best performing services in the industry.

CA Recommended Practices
1.9 We do not currently include the sentence "Domain_owned_by_a_Natural_Person".  We will look at this in more detail.
1.12 We are reviewing all our SubCA customers and either moving them on to a Domain and Directory Constrained issuing CA or an issuance model whereby GlobalSign issues certificates on their behalf.  The majority of partners will finish the migration in Q1 2013 and suspend services in late 2013 or early 2014 when currently live certificates expire or are replaced.

Mozilla Potentially Problematic Practices

1) Long-lived DV certificates - GlobalSign meets the needs of the Base requirements on Certificate duration.
2) Wildcard DV SSL certificates - GlobalSign currently issues Wildcard DV certificates.  We currently do not share the same concern as mozilla on this point and therefore do not plan to deprecate this product type.
3) Email Address Prefixes for DV Certs - GlobalSign meets the needs of the Base requirements for e-mail challenges
4) Delegation of Domain / Email validation to third parties - GlobalSign does it's own verification for all products.  This includes managed services for SSL and SMIME on behalf of enterprise clients. (Section 3.2.3.4 of our CPS discusses this in detail)
5) Issuing end entity certificates directly from roots - GlobalSign does not issue from it's roots unless a test is needed such as these ECC test certificates.
6) Allowing external entities to operate subordinate CAs - GlobalSign's program for external entities (RootSign) has been in operation for 10+ years and as highlighted by the responses above, the program is migrating to a new policy of Name Constraints or 3rd party audit under the title Trusted Root.
7) Distributing generated private keys in PKCS#12 files - GlobalSign provides pfx files to customers.  We created and reviewed the process with our auditors in 2007 (Deloitte) and again when we moved to E&Y in 2008.  GlobalSign's solution for SSL is known as AutoCSR and is covered in our CPS in section 6.1.2 on page 45.
8) Certificates referencing hostnames or private IP addresses - GlobalSign provides OV certificates which may include Internal IP address and/or hostnames.  Section 3.2.4 covers these non verifiable items.  Our application systems prevent applicants from using Internal IP addresses and Hostnames within DV certificates.
Issuing SSL Certificates for Internal Domains - GlobalSign provides OV certificates which may include Internal domains.  Section 3.2.4 covers these non verifiable items.  Our application systems prevent applicants from using Internal domains within DV certificates.
9) OCSP Responses signed by a certificate under a different root - Not applicable as we use the same keys for OCSP and CRL as for the issuance of the certificate. 
10) CRL with critical CIDP Extension - Not applicable as we use full CRLs
11) Generic names for CAs - Our Roots are names as GlobalSign.   GlobalSign is a global brand and has presence in >10 countries so we choose to use the global brand name.
12) Lack of Communication With End Users - GlobalSign tries to be responsive to users and relying parties.  This offers a crowd sourcing capability that helps to identify problems.  i.e. this issue is not applicable.

Kind Regards

Steve Roylance
Business Development Director and member of the Policy Authority.

Comment 1

[Kathleen Wilson]

I apologize for the delay in my response. My work on root inclusion requests was postponed for a while.

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 3

[Steve Roylance]

Hi Kathleen.

Thanks for the feedback and questions.  Here are our answers

OCSP support for Extended Validation.   We are already compliant for released products based on our other roots, so would appreciate it if our new roots could also be marked for EV.  There is no plan yet to release a product range for ECC, therefore no need for EV, however in an emergency situation on RSA we could create all the necessary services but if past versions of Firefox do not support EV that would be a problem for customers. The service we would create for testing would not be a production service so in effect would not be an effective test by Mozilla anyway. I would understand if we were a new entrant to the root store however we were a founder of CABForum and have 15+ years of issuance.  Thanks for some feedback on this point. 

1) IDN - We do not support IDN and therefore do not need to comment in the CPS yet.  Once we bring forward support we'll follow the best practices you recommend.
2) SAN Support.  I'll ask the Policy Authority to address the language here.  The FQDN is "always" placed into the SAN.  It's a www version which may also be included and this should be the language in the CPS.  Thanks for highlighting it's not clearly written.
3) Indeed, we do not issue SSL certificates to individuals.  We may issue to a sole trader if we can positively authenticate them and their business name.

I hope that helps.

Comment 4

[Kathleen Wilson]

Mozilla's current practice regarding root inclusions (even for renewed roots) is:

1) OCSP required as per BRs if websites trust bit is to be enabled. Please update this bug when this is ready.

2) EV treatment will not be provided until after the EV testing (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version) has been completed by the CA. The root may be included and the approval process for EV treatment completed, but we will not create the PSM bug to actually do the EV-enablement until after the testing has been completed successfully.

Comment 5

[Steve Roylance]

Apologies that this took so long to set up, however both test web sites with OCSP services meeting BR needs are ready for the Mozilla team to check.  Both certificates are marked for EV with respondents operational.

ECC Root R4 is on https://2038r4.globalsign.com
ECC Root R5 is on https://2038r5.globalsign.com

I would appreciate the team pushing these through the remainder of the process.

Our updated WebTrust statements and seals are usually available by the end of July so we are still operational under last years seals for WebTrust, Baseline Requirements and EV.

Many thanks

Steve

Comment 6

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 7

[Kathleen Wilson]

This request has been added to the queue for public discussion. 
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 8

[Kathleen Wilson]

Attachment: test_ev_roots-Root-R4.txt

Comment 9

[Kathleen Wilson]

Attachment: test_ev_roots-Root-R5.txt

Comment 10

[GlobalSign]

Hi Everyone.   

GlobalSign has been awarded our WebTrust seals for 2014.  They are viewable on these links so this should allow the root inclusion to progress ahead.  It may mean an update to the CA information document, so I'll let Kathleen progress, however it seems she may be away at the moment.

WebTrust for CA: https://cert.webtrust.org/ViewSeal?id=1690
WebTrust for EV: https://cert.webtrust.org/ViewSeal?id=1691
SSL Baseline Requirements: https://cert.webtrust.org/ViewSeal?id=1688

Thanks

Steve

Comment 11

[Kathleen Wilson]

I am now opening the first public discussion period for this request from GlobalSign to include the “GlobalSign ECC Root CA - R4” and “GlobalSign ECC Root CA - R5” root certificates, and turn on all three trust bits and enable EV treatment for both roots.

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.

The discussion thread is called “GlobalSign Request to Include ECC Roots”.

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

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

Comment 12

[Kathleen Wilson]

Removing the dependency on Bug #1048045, because "(From March 2013 onwards), ... the necessary corrective actions have been made and moving forward the CA is compliant."
This is in line with Mozilla's expectations regarding BR compliance, 
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

Comment 13

[Steve Roylance]

GlobalSign has reviewed and amended both the CP and CPS to cover the requirements around Domain Validation.  In discussions was saw that Domain Control Validation is not specifically called out in the default RFC mapping so we moved details to a new section "3.2.7 Authentication of Domain Name".   Previously we had incorporated inside section "3.2.2 Authentication of Organization Identity" which doesn't seem to be the right location for authentication of domain ownership for Domain Validation certificates.   We've therefore also reworded 3.2.2.   These will be published shortly and I will respond the the mailing list once that happens, however here is the wording form the revised Section 3.2.2 and new 3.2.7.

3.2.2 Authentication of Organization Identity
=============================================
GlobalSign CA maintains internal policies and procedures which are reviewed regularly in order to comply with the requirements of the various root programs that GlobalSign CA is a member of, as well as the Baseline Requirements, the EV Guidelines and EV Code Signing Guidelines. These policy and procedure documents are under the control of Policy Authority 6 (subordinate to the main Policy Authority in section 1.5.1) fulfilling the criteria of Principle 6 of the WebTrust 2.0. The method by which GlobalSign verifies the organization identity is generally consistent across all product types, however alternative methods, in line with accepted alternatives, may be used where authentication is not possible through the more commonly used QGIS method highlighted below.
GlobalSign CA CPS (Certification Practice Statement) 27 of 62
Version: 7.8
GlobalSign CA Certification Practice Statement
For all Certificates that include an organization identity, Applicants are required to indicate the organization’s name and registered or trading address. For all Certificates, the legal existence, legal name, assumed name, legal form and requested address of the organization are verified using one of the following:-
• A government agency (QGIS) in the jurisdiction of the Applicant, or a superior governing governmental agency if the Applicant claims they are a government agency themselves.
• A third party database that is periodically updated and has been evaluated by GlobalSign CA to determine that it is reasonably accurate and reliable; or
• An attestation letter confirming that Subject Identity Information is correct written by an accountant, a lawyer, a government official, a judge, or other reliable third party customarily relied upon for such information.
• A Qualified Governmental Tax Information Source
Except for Extended Validation (which does not allow this method for verification of the address), GlobalSign CA may verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that has been determined by GlobalSign CA to be reasonably accurate and reliable.
The authority of the Applicant to request a Certificate on behalf of the organization is verified in accordance with Section 3.2.5 below.

3.2.7 Authentication of Domain Name
===================================
For all SSL/TLS Certificates, authentication of the Applicant’s (or the Applicant’s parent company’s, subsidiary company’s or Affiliate’s, collectively referred to as “Applicant’s” for the purposes of this section) ownership or control of all requested Domain Name(s) is done using one of the following methods:
• Using GlobalSign’s OneClickSSL protocol whereby the Applicant is required to demonstrate control of a Domain Name by installing a non publicly trusted test Certificate of GlobalSign CA’s specification. GlobalSign CA then makes a connection to the test Certificate over https to verify the use of the Private/Public Key Pair on the domain(s) being authenticated. Publicly trusted Certificates will be delivered to the Applicant based on the same Public/Private Key Pair;
• By uploading specific metadata to a defined page on the domain;
• By uploading specific metadata to the DNS text record of the domain;
• By direct confirmation with the contact listed by the Domain Name Registrar in the WHOIS record or provided to GlobalSign CA by the Domain Name Registrar directly;
• By successfully replying to a challenge response email sent to one or more of the following email addresses:
o [e-mail], postmaster@domain, [e-mail], [e-mail], hostmaster@domain, or
o any email address listed as a contact field of the WHOIS record, or
o any address previously used for the successful validation of the control of the domain subject to the re-verification requirements of Section 3.3.1; or
• By receiving a reliable communication from the Domain Name Registrar stating that the Registrant gives the Applicant permission to use the Domain Name.
GlobalSign CA CPS (Certification Practice Statement) 31 of 62
Version: 7.8
GlobalSign CA Certification Practice Statement
To reduce the risk of compromise of the WHOIS information, GlobalSign only uses the WHOIS records linked to on the IANA root database and the WHOIS records provided by ICANN approved registrars.
The following information on the WHOIS records can be used:
• Name;
• Telephone number;
• Fax number;
• Address;
• Email address.
This information is taken from the following fields (where applicable):
• Registrar;
• Registrant, holder, domain owner or similar;
• Technical contact;
• Administrative contact.

Comment 14

[Steve Roylance]

I just noticed that "Cut and Paste" from my digitally signed PDF version captured the page number and title so here's the clean version of the text.

3.2.2 Authentication of Organization Identity
=============================================
GlobalSign CA maintains internal policies and procedures which are reviewed regularly in order to comply with the requirements of the various root programs that GlobalSign CA is a member of, as well as the Baseline Requirements, the EV Guidelines and EV Code Signing Guidelines. These policy and procedure documents are under the control of Policy Authority 6 (subordinate to the main Policy Authority in section 1.5.1) fulfilling the criteria of Principle 6 of the WebTrust 2.0. The method by which GlobalSign verifies the organization identity is generally consistent across all product types, however alternative methods, in line with accepted alternatives, may be used where authentication is not possible through the more commonly used QGIS method highlighted below.

For all Certificates that include an organization identity, Applicants are required to indicate the organization’s name and registered or trading address. For all Certificates, the legal existence, legal name, assumed name, legal form and requested address of the organization are verified using one of the following:-
• A government agency (QGIS) in the jurisdiction of the Applicant, or a superior governing governmental agency if the Applicant claims they are a government agency themselves.
• A third party database that is periodically updated and has been evaluated by GlobalSign CA to determine that it is reasonably accurate and reliable; or
• An attestation letter confirming that Subject Identity Information is correct written by an accountant, a lawyer, a government official, a judge, or other reliable third party customarily relied upon for such information.
• A Qualified Governmental Tax Information Source
Except for Extended Validation (which does not allow this method for verification of the address), GlobalSign CA may verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that has been determined by GlobalSign CA to be reasonably accurate and reliable.
The authority of the Applicant to request a Certificate on behalf of the organization is verified in accordance with Section 3.2.5 below.

3.2.7 Authentication of Domain Name
===================================
For all SSL/TLS Certificates, authentication of the Applicant’s (or the Applicant’s parent company’s, subsidiary company’s or Affiliate’s, collectively referred to as “Applicant’s” for the purposes of this section) ownership or control of all requested Domain Name(s) is done using one of the following methods:
• Using GlobalSign’s OneClickSSL protocol whereby the Applicant is required to demonstrate control of a Domain Name by installing a non publicly trusted test Certificate of GlobalSign CA’s specification. GlobalSign CA then makes a connection to the test Certificate over https to verify the use of the Private/Public Key Pair on the domain(s) being authenticated. Publicly trusted Certificates will be delivered to the Applicant based on the same Public/Private Key Pair;
• By uploading specific metadata to a defined page on the domain;
• By uploading specific metadata to the DNS text record of the domain;
• By direct confirmation with the contact listed by the Domain Name Registrar in the WHOIS record or provided to GlobalSign CA by the Domain Name Registrar directly;
• By successfully replying to a challenge response email sent to one or more of the following email addresses:
o [e-mail], postmaster@domain, [e-mail], [e-mail], hostmaster@domain, or
o any email address listed as a contact field of the WHOIS record, or
o any address previously used for the successful validation of the control of the domain subject to the re-verification requirements of Section 3.3.1; or
• By receiving a reliable communication from the Domain Name Registrar stating that the Registrant gives the Applicant permission to use the Domain Name.

To reduce the risk of compromise of the WHOIS information, GlobalSign only uses the WHOIS records linked to on the IANA root database and the WHOIS records provided by ICANN approved registrars.
The following information on the WHOIS records can be used:
• Name;
• Telephone number;
• Fax number;
• Address;
• Email address.
This information is taken from the following fields (where applicable):
• Registrar;
• Registrant, holder, domain owner or similar;
• Technical contact;
• Administrative contact.

Comment 15

[Steve Roylance]

The revised CP is published here https://www.globalsign.com/repository/GlobalSign_CP_v4.8.pdf

The revised CPS is published here https://www.globalsign.com/repository/GlobalSign_CA_CPS_v7.8.pdf

Comment 16

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #11)
> I am now opening the first public discussion period for this request from
> GlobalSign to include the “GlobalSign ECC Root CA - R4” and “GlobalSign ECC
> Root CA - R5” root certificates, and turn on all three trust bits and enable
> EV treatment for both roots.

The public comment period for this request is now over. 

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

 http://www.mozilla.org/about/governance/policies/security-group/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 to include the “GlobalSign ECC Root CA - R4” and “GlobalSign ECC Root CA - R5” root certificates, and turn on all three trust bits and enable EV treatment for both roots.

Section 4 [Technical]. I am not aware of instances where GlobalSign has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Section 6 [Relevancy and Policy]. GlobalSign appears to provide a service relevant to Mozilla users: It is a privately owned organization, providing businesses and individuals with SSL, SMIME and code signing certificates.

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 provided in English.

Document Repository: https://www.globalsign.com/repository/
CP: https://www.globalsign.com/repository/GlobalSign_CP_v4.8.pdf
CPS: https://www.globalsign.com/repository/GlobalSign_CA_CPS_v7.8.pdf

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

* SSL: GlobalSign verifies the Applicant’s control of the domain name to be included in the certificate in accordance to the CA/Browser Forum Baseline Requirements and as described in section 3.2.7 of the CPS.

* Email: According to sections 3.2.3 and 3.2.5 of the CPS, GlobalSign uses a challenge response mechanism to verify that the Applicant has control over the email address to be listed within the Certificate.

* Code: GlobalSign verifies the legal existence of the organization requesting the certificate, and the identity and authority of the certificate subscriber, as documented in sections 3.2.2, 3.2.3, and 3.2.5 of the CPS.

Section 18 [Certificate Hierarchy]. 
These root certs are offline and will sign internally operated intermediate certificates.

* EV Policy OID: 1.3.6.1.4.1.4146.1.1
** EV treatment is requested for both root certs.

* OCSP
http://ocsp2.globalsign.com/ecadminca1sha2g2
http://ocsp2.globalsign.com/ecadminca2sha2g2

* Potentially Problematic Practices 
(http://wiki.mozilla.org/CA:Problematic_Practices)
** GlobalSign currently issues Wildcard DV certificates. 
CPS section 3.1.1: Wildcard SSL Certificates include a wildcard asterisk character. Before issuing a certificate with a wildcard character (*) GlobalSign CA follows best practices to determine if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix”. (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation.) and if it does, it will reject the request as the domain space must be owned or controlled by the subscriber. e.g. *.globalsign.com
** GlobalSign provides pfx files to customers.  
CPS section 6.1.2: GlobalSign CAs that create Private Keys on behalf of Subscribers (AutoCSR) do so only when sufficient security is maintained within the key generation process and any onward issuance process to the Subscriber. For SSL/TLS Certificates, this is achieved through the use of PCKS#12 (.pfx) files containing Private Keys and Certificates encrypted by a sixteen (16) digit password. The first eight (8) digits are system generated and provided to the Subscriber during the enrollment process and the Subscriber decides the remaining eight (8). For SMIME certificates, this is again achieved through the use of PCKS#12 (.pfx) files containing Private Keys and Certificates encrypted by an eight (8) digit Subscriber-selected password.
GlobalSign CA ensures the integrity of any Public/Private Keys and the randomness of the key material through a suitable RNG or PRNG. If GlobalSign CA detects or suspects that the Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then GlobalSign CA revokes all Certificates that include the Public Key corresponding to the communicated Private Key. GlobalSign CA does not archive Private Keys and ensures that any temporary location where a Private Key may have existed in any memory location during the generation process is purged.
** GlobalSign provides OV certificates, which may include Internal IP address and/or hostnames.  
CPS section 3.2.4: For OV SSL/TLS Certificates only, GlobalSign CA relies upon information provided by the Applicant to be included within the subjectAlternativeName such as internal or non-public DNS names, hostnames and RFC 1918 IP addresses. The Baseline Requirements define the time frame for an industry wide deadline at which time these objects may no longer be included within Certificates. Until such time these items are classified as non-verified Subscriber information as ownership cannot reasonably be validated.

Sections 11-14 [Audit].  
* Annual audits are performed by Ernst & Young according to the WebTrust criteria.
WebTrust for CA: https://cert.webtrust.org/ViewSeal?id=1690 
WebTrust for EV: https://cert.webtrust.org/ViewSeal?id=1691 
SSL Baseline Requirements: https://cert.webtrust.org/ViewSeal?id=1688

Based on this assessment I intend to approve this request to include the “GlobalSign ECC Root CA - R4” and “GlobalSign ECC Root CA - R5” root certificates, and turn on all three trust bits and enable EV treatment for both roots.

Comment 17

[Kathleen Wilson]

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

** “GlobalSign ECC Root CA - R4” (websites, email, code signing), enable EV
** “GlobalSign ECC Root CA - R5” (websites, email, code signing), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 18

[Kathleen Wilson]

I have filed bug #1069627 against NSS and bug #1069651 against PSM for the actual changes.