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

RESOLVED WONTFIX

Status

NSS
CA Certificate Root Program
RESOLVED WONTFIX
5 years ago
8 months ago

People

(Reporter: Steve Roylance, Assigned: Kathleen Wilson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.56.5 (KHTML, like Gecko) Version/5.1.6 Safari/534.56.5

Steps to reproduce:

I'd like to embed GlobalSign ECC Roots so I'm opening this bug and will add additional information as required by the checklist.
(Reporter)

Comment 1

5 years ago
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 down 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: 603-570-7059
Lila Kee - lila.kee@globalsign.com

EMEA
GMO GlobalSign Ltd
Springfield House
Sandling Road, Maidstone, Kent
ME14 2LP, United Kingdom
Tel: +44 1622 766766
Fax: +44 1622 662255
Steve Roylance - steve.roylance@globalsign.com

Japan and APAC
Cerulean Tower 10F
26-1 Sakuragaokacho, Shibuya-ku,
Tokyo 150-8512, Japan
Tel: +81-03-5728-1551
Fax:+81-03-5728-1552
Atsushi Inaba - atsushi.inaba@globalsign.co.jp

Technical Details about each root.

Root 1 of 2
1 Friendly Name - GlobalSign Root CA - R4
2 Certificate Issuer Field - CN = GlobalSign, O = GlobalSign, OU = GlobalSign Root CA - R4 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-R4.crt
5 SHA1 Fingerprint - 
   SHA1(DER) = 34 ad 20 0a 5c 22 d8 ba f8 b1 a8 bb ee 73 ca 60 91 0c a7 a1
   SHA1(BASE64) = cd 08 cf 0a a9 8b b2 b0 72 8d 39 57 f0 c6 68 b9 4a 1c 49 2b
6 Valid from - 15 February 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 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 Root CA - R5
2 Certificate Issuer Field - CN = GlobalSign, O = GlobalSign, OU = GlobalSign 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 SHA1 Fingerprint - 
  SHA1(DER) = 4e a7 48 d6 bb 8e 9a 3b 23 73 56 84 d5 cf c8 f8 1e 0b 9b 7d
  SHA1(BASE64) = 1e 63 30 d9 6b f1 34 ae 38 cc 51 a5 14 e5 6b 77 55 ad 51 5d
6 Valid from - 15 February 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 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 many 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 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 which includes these roots 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 Constrained issuing CA or an issuance model whereby GlobalSign issues certificates on their behalf.  The majority of partners will finish the migration in 2012 and suspend services in late 2013 and 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
(Reporter)

Comment 2

5 years ago
Dear all.

many thanks to Rick Andrews from Symantec.  Their engineering team reviewed our ECC roots in this submission and offline highlighted a potential flaw with encoded null values.  Whilst this should not be an issue for RFC 5758 we prefer prudence over speed and therefore withdraw this application.   When we have recreated the Roots we will re submit.

We thank Rick and his team for their diligence and look forward to a bright future where CAs and Browsers all continue to work together to increase the security and trust for everyone and this starts with making sure the roots are technically correct.

Kind Regards  Steve
(Assignee)

Comment 3

5 years ago
(In reply to Steve Roylance from comment #2)
> we prefer prudence over speed and therefore withdraw this application.  
> When we have recreated the Roots we will re submit.

Please file a new bug when ready.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Comment 4

5 years ago
(In reply to Steve Roylance from comment #2)
> many thanks to Rick Andrews from Symantec.  Their engineering team reviewed
> our ECC roots in this submission and offline highlighted a potential flaw
> with encoded null values.  Whilst this should not be an issue for RFC 5758

I'm curious as to why you think that "this should not be an issue for RFC 5758"... clearly it's a mandatory requirement to not encode any parameters for the ECDSA signature algorithm identifiers. From section 3.2:

   When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384, or
   ecdsa-with-SHA512 algorithm identifier appears in the algorithm field
   as an AlgorithmIdentifier, the encoding MUST omit the parameters
   field.  That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
   component, the OID ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-
   SHA384, or ecdsa-with-SHA512.

But "GlobalSign Root CA - R4" has:

    SEQUENCE {
      OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
        (ANSI X9.62 ECDSA algorithm with SHA256)
      NULL
      }

and "GlobalSign Root CA - R5":

    SEQUENCE {
      OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
        (ANSI X9.62 ECDSA algorithm with SHA384)
      NULL
      }

Not respecting absolute requirements of a specification (see the definition of MUST and SHALL in RFC 2119) hardly looks like "not being an issue"...

The end-entity certs for the test sites 2038r4.globalsign.com and 2038r5.globalsign.com suffer from the same problem, BTW.
(Reporter)

Comment 5

5 years ago
Hi Kaspar,

I should have been more careful on my choice of words in that sentence.    Browsers accepted the certificates even though they were non compliant and hence why we missed that doing the initial internal testing. 

My sentence should have been:-  Whilst this has not been an issue for browsers supporting RFC 5758 we prefer prudence over speed and therefore withdraw this application.

ie we agree fully that they should respect 5758 which is why we are going to re cut them.  Sorry for not being clear.   I was in a rush to pull them from all programs they had been submitted to.

Updated

8 months ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.