Closed Bug 640368 Opened 13 years ago Closed 12 years ago

Add StartCom Certification Authority G2 root certificate to NSS + EV enable

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: eddy_nigg, Assigned: kwilson)

References

Details

(Whiteboard: In FF16)

Attachments

(6 files, 3 obsolete files)

CA Details
----------

CA Name: StartCom Certification Authority
Website: www.startssl.com
StartCom operates the StartCom Certification Authority, serves its subscribers worldwide and is a commercial entity.

Audit Type: WebTrust
Auditor: Ernst & Young
Auditor Website: http://www.ey.com/
Audit Document URL(s): https://www.startssl.com/?app=26 (updated yearly and separate statement for this root will be submitted to this bug).

Certificate Details
-------------------

Certificate Name: StartCom Certification Authority G2

Currently StartCom operates intermediate CA certificates arranged in 4
different levels (classes) and certificate types (server, client, code).

Class 1 - Server + Email
Class 2 - Server + Email + Code
Class 3 - Server + Email + Code
Class 4 - Server (reserved Email + Code)

CA Certificate repository is at https://www.startssl.com/certs/

Certificate download URL: https://www.startssl.com/certs/ca-g2.pem
Version: 3
SHA1 Fingerprint: BB:25:A3:D8:49:30:0F:2E:87:9F:74:36:43:6D:12:94:4A:F5:5A:DA
Public key length in bits: 4096
Valid From (YYYY-MM-DD): 2010-01-01
Valid To (YYYY-MM-DD): 2039-12-31

CRL HTTP URL: According to CRL distribution points in intermediate and end-user
certificates (varies according to class level and certificates type).

CRL issuing frequency for subordinate end-entity certificates: CRLs are updated
at least every 12 hours or upon adding of a new entry, e.g. every time a
certificate is revoked. 

CRL issuing frequency for subordinate CA certificates: Every 12 month.
OCSP URL: According to AIA OCSP URI set in the certificates (varies according
to class level and certificates type).

Class (domain-validated, identity/organizationally-validated or EV): All 
Certificate Policy URL: https://www.startssl.com/?app=26
CPS URL: https://www.startssl.com/?app=26
Requested Trust Indicators (email and/or SSL and/or code signing): All
URL of example website using certificate subordinate to this root
(if applying for SSL): To be provided.
What is the relation between this request and the one in bug #602750?
The root of bug 602750 is a rollover/rehash of the existing root that is already included in NSS. This root is new, additional and unrelated to the one from bug 602750.
Status: NEW → ASSIGNED
Whiteboard: EV- information incomplete
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.
We will provide you with a test site prior to the public discussion.

Any intermediate and cross-signed CA root and its keys are under exclusive control of StartCom. We'll provide further information about such a cross-signed CA root as in bug 602750.

Regarding email and domain control validation for levels other than Class 1, the same resolution applies as in bug 602750. The policy isn't clear and we'll add this to our current addendum and eventually to the new policy.

The next audit report will be provided as soon as possible. We are on a yearly schedule and the report for 2010 should be available soon.
The items highlighted in green indicate where updates will be needed before
starting the public discussion.
This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Whiteboard: EV- information incomplete → EV - Information confirmed complete
Thank you, as always.
Attached file WebTrust EV Audit 2010
The original CA root had a minor defect in the validity fields which wouldn't have affected Mozilla software (NSS/PSM), however it wasn't correct according to RFC 5280:

The G2 StartCom CA root had a start date of "Fri Jan 01 01:00:00
2010" which resulted in:

      C-Sequence  (26)
         UTC Time  (11)
            "1001010100Z" (Fri Jan 01 01:00:00 2010)
         UTC Time  (11)
            "3912312359Z" (Sat Dec 31 23:59:00 2039)

However the seconds for example in "1001010100Z" were omitted. But according to RFC 5280

4.1.2.5.1.  UTCTime

   The universal time type, UTCTime, is a standard ASN.1 type intended
   for representation of dates and time.  UTCTime specifies the year
   through the two low-order digits and time is specified to the
   precision of one minute or one second.  UTCTime includes either Z
   (for Zulu, or Greenwich Mean Time) or a time differential.

   For the purposes of this profile, UTCTime values MUST be expressed in
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.

Therefore this CA root has been signed again with a slight change:

      C-Sequence  (30)
         UTC Time  (13)
            "100101010001Z" (Fri Jan 01 01:00:01 2010)
         UTC Time  (13)
            "391231235901Z" (Sat Dec 31 23:59:01 2039)

And obviously correct length of the validity fields. The re-signing has been witnessed by a representative of E&Y and we could probably get another confirmation of this as well. No new key was produced.
Attachment #518200 - Attachment is obsolete: true
Test site for this root: https://g2.startcom.org/

It chains to a cross-signed CA certificate of the original CA root that is already included with NSS - in order to check it, this one has to be removed first and the G2 root imported and trusted.
Attachment #520812 - Attachment is obsolete: true
(In reply to Eddy Nigg (StartCom) from comment #12)
> Test site for this root: https://g2.startcom.org/

The website cert does not appear to be EV 
(e.g. doesn't have Policy OID 1.3.6.1.4.1.23223.2)

Before I can create the PSM bug for EV-enablement, we will need a test website with an EV SSL cert, and have you confirm completion of 
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
However, I think we can proceed with public discussion even these aren't ready yet.
We will arrange that shortly - please note that StartCom has currently two EV OIDs and we'd prefer if Mozilla could support both or only the new one.

Relevant section from the StartCom CA Policy under "Certificate Profiles" -> "Naming conventions" -> "Extended Validation":

The special EV OIDs are 1.3.6.1.4.1.23223.2 and *1.3.6.1.4.1.23223.1.1.1*.
Do you want to have both EV Policy OIDs valid for both roots? Or the old EV OID for the "StartCom Certification Authority" root, and the new EV OID for the "StartCom Certification Authority G2" root?
If we can migrate the EV OID to 1.3.6.1.4.1.23223.1.1.1 for all roots, that would be great.
Attachment #581837 - Attachment is obsolete: true
I am now opening the first public discussion period for two requests from StartCom:

#602750 - Add Renewed StartCom root certificate
#640368 - Add StartCom Certification Authority G2 root certificate to NSS + EV enable

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 dev-security-policy@lists.mozilla.org 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 “StartCom Root Inclusion Request for Renewed and G2 Roots”

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

A representative of StartCom must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Information confirmed complete → EV - In public discussion
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/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 to include the “StartCom Certification Authority G2” root certificate, turn on all three trust-bits, and enable EV.

Section 4 [Technical]. I am not aware of instances where StartCom has 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]. StartCom appears to provide a service relevant to Mozilla users. It is a commercial corporation with customers 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.

CP/CPS: https://www.startssl.com/policy.pdf
CPS Addendum: https://www.startssl.com/policy-addendum-2010.pdf
EV CP: https://www.startssl.com/extended.pdf

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

* Email: According to the CP/CPS, Startcom verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate via an emailed challenge-response mechanism.

* SSL: According to the CP/CPS, StartCom verifies domain control by sending an electronic mail message with a verification code to one of the following administrative electronic mail accounts: webmaster@domain.com hostmaster@domain.com  postmaster@domain.com The subscriber has to return and submit the verification code as proof of ownership of the domain name.

* Code: According to the CP/CPS, Code Signing certificates may be issued under Class 2 or Class 3 verification procedures, which means that StartCom verifies the personal identity of the subscriber or organization representative, and confirms the identity of the subscriber and the organizational details with a third-party source.

EV Policy OID: 1.3.6.1.4.1.23223.1.1.1  
(11.3.6.1.4.1.23223.2 is an old OID that StartCom doesn’t need after this new OID is added. StartCom would like all of it’s roots changed to only the 1.3.6.1.4.1.23223.1.1.1 EV OID in PSM.)

Section 15 [Certificate Hierarchy]. 
StartCom root certificates are offline, and sign internally-operated sub-CAs. The Intermediate CA certificates are structured per class and per purpose: SSL/TLS Server Certificates, S/MIME Client Certificates, Object Code Signing Certificates. and Classes 1 through 3, Extended Validation. Each Intermediate CA issues an OCSP signer certificate for the OCSP responder service.

* Both CRL and OCSP are provided 
** CP/CPS: The corresponding Certificate Revocation Lists (CRL) of subscriber certificates are updated every 12 hours or every time a certificate is revoked, whichever comes first.
** CP/CPS: The OCSP responder provides results about the status of a certificate instantly. The current CRLs are reloaded at least every 60 minutes.

Sections 9-11 [Audit]. Annual audits are performed by Ernst & Young Israel according to the WebTrust CA and WebTrust EV criteria. The audit reports are available on StartCom’s website, so I have confirmed the authenticity of the audit reports by exchanging email with a representative of Ernst & Young.
https://www.startssl.com/ey-webtrust.pdf 
https://www.startssl.com/ey-webtrust-ev.pdf 

Based on this assessment I intend to approve this request to include the “StartCom Certification Authority G2” root certificate, turn on all three trust-bits, and enable EV.

Note that before I create the corresponding PSM bug, StartCom needs to provide a test website with an EV SSL cert chaining up to this root, and needs to confirm that the EV testing has been successfully completed.
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Whiteboard: EV - In public discussion → EV - Pending Approval
To the representatives of StartCom: 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 Mozilla I approve this request from StartCom to include the following root certificate in Mozilla:

* StartCom Certification Authority G2 (websites, email, code signing), enable EV

I will file the NSS bug for inclusion.

I will wait to file the PSM bug for EV enablement until after StartCom provides a test website with an EV SSL cert chaining up to this root, and confirms that the EV testing has been successfully completed.
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS, CA action to perform EV testing
Depends on: 751954
I have filed bug #751954 for the actual changes in NSS.
See Comment #21 regarding the PSM bug that will be needed for EV enablement.
The site https://g2.startcom.org/ is now with an EV certificate.
Depends on: 751960
I added the PSM change request for this root cert to bug #751960.
Whiteboard: EV - Approved - awaiting NSS, CA action to perform EV testing → EV - Approved - awaiting NSS and PSM
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - awaiting NSS and PSM → In FF16
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: