602750 - Add Renewed StartCom root certificate

Status: RESOLVED FIXED

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

Description

[Eddy Nigg (StartCom)]

Attachment: Audit report of Certificate Rehashing Procedure (Witnessing according to EV guidelines)

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

CA Name: StartCom Certification Authority
Website: www.startssl.com
StartCom is the producer of a Linux operating systems and operates the StartCom Certification Authority since 2005. StartCom serves its subscribers worldwide and is a commercial entity.

Audit Type: WebTrust
Auditor: Ernst & Young (Israel)
Auditor Website: http://www.ey.com/
Audit Document URL(s): https://www.startssl.com/?app=26

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

Certificate Name: StartCom Certification Authority

This is a request to add a rehashed CA root with SHA256 hash which was originally included in bug 383722 .

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-sha2.pem
Version: 3
SHA1 Fingerprint: A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
Public key length in bits: 4096
Valid From (YYYY-MM-DD): 2006-09-17
Valid To (YYYY-MM-DD): 2036-09-17

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): https://www.startssl.com/

Comment 1

[Kathleen Wilson]

Accepting this bug.  I will start the Information Gathering and Verification
phase as per https://wiki.mozilla.org/CA:How_to_apply.

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
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

[Kathleen Wilson]

I sent email to a representative of Ernst & Young (Israel), and he responded and confirmed the authenticity of the three related audit reports:

WebTrust CA: https://www.startssl.com/ey-webtrust.pdf
WebTrust EV: https://www.startssl.com/ey-webtrust-ev.pdf
Witness of Key Ceremony for new EV root: 
https://bugzilla.mozilla.org/attachment.cgi?id=481737

Comment 4

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Please review the full document for accuracy.

The following items are still open (highlighted in yellow in the document):

1) Test Website: Do you have thoughts on how to test browsing to a website with an SSL cert chaining up to this new root? I’ve tried removing the trust bits from the builtin root, and I have this new root imported and trusted, but then I get an untrusted error when I try to browse to https://www.startssl.com/certs

2) Does or will this root have any subordinate CAs that are operated by external third parties?

3) List any other root CAs that have issued cross-signing certificates with this root CA.

4) It is not clear to me if the DV validation that is described for Class 1 certs must also be performed for Class 2, Class 3, and EV certs. If this is the case, then I think this should be made clear in the CP/CPS documents.

5) It is not clear to me if the email challenge-response mechanism that is described for Class 1 email address verification must also be performed for Class 2 and Class 3 certs. If this is the case, then I think this should be made clear in the CP/CPS documents.

Comment 5

[Eddy Nigg (StartCom)]

(In reply to comment #4)
> 1) Test Website: Do you have thoughts on how to test browsing to a website with
> an SSL cert chaining up to this new root? I’ve tried removing the trust bits
> from the builtin root, and I have this new root imported and trusted, but then
> I get an untrusted error when I try to browse to https://www.startssl.com/certs

I will provide you with a test site - the intermediate EV certificate requires currently the SHA1 root (it is the only intermediate CA affected by that). An updated version of the EV CA will be issued during the coming month. An updated SHA2 version of that certificate already exists, but isn't in use widely so far due to compatibility issues with devices and clients that don't support SHA2.

> 2) Does or will this root have any subordinate CAs that are operated by
> external third parties?

The StartCom CA policy operates all CA certificates, being it for "internal" use or being it for third parties. There are no CA certificates that are controlled by any third party.

> 3) List any other root CAs that have issued cross-signing certificates with
> this root CA.

There will be a third party cross-signed CA root and I'll publish this information prior to the public discussion. Also here the same rule applies and the CA keys and roots are exclusively controlled by StartCom. In the same manner, StartCom has overall responsibility, oversight and rights.

> 
> 4) It is not clear to me if the DV validation that is described for Class 1
> certs must also be performed for Class 2, Class 3, and EV certs. If this is the
> case, then I think this should be made clear in the CP/CPS documents.

Nice catch - each level implies the previous level's verification requirements. E.g. domain control validation is always performed for all levels. Depending on the level, it might be not the only verification performed in order to establish control over a domain (for example for EV).

In any case, the policy isn't clear and we'll add this to our current addendum and eventually to the new policy. The current addendum is at https://www.startssl.com/policy-addendum-2010.pdf

> 
> 5) It is not clear to me if the email challenge-response mechanism that is
> described for Class 1 email address verification must also be performed for
> Class 2 and Class 3 certs. If this is the case, then I think this should be
> made clear in the CP/CPS documents.

Same as above.

Comment 6

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

The items highlighted in green indicate where updates will be needed before starting the public discussion.

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

[Eddy Nigg (StartCom)]

Perfect.

Comment 9

[Kathleen Wilson]

(In reply to Eddy Nigg (StartCom) from comment #5)
> (In reply to comment #4)
> > 1) Test Website: Do you have thoughts on how to test browsing to a website with
> > an SSL cert chaining up to this new root? I’ve tried removing the trust bits
> > from the builtin root, and I have this new root imported and trusted, but then
> > I get an untrusted error when I try to browse to https://www.startssl.com/certs
> 
> I will provide you with a test site - the intermediate EV certificate
> requires currently the SHA1 root (it is the only intermediate CA affected by
> that). An updated version of the EV CA will be issued during the coming
> month. An updated SHA2 version of that certificate already exists, but isn't
> in use widely so far due to compatibility issues with devices and clients
> that don't support SHA2.
> 


Please provide the test website.


>> 3) List any other root CAs that have issued cross-signing certificates with
>> this root CA.
> 
> There will be a third party cross-signed CA root and I'll publish this
> information prior to the public discussion. Also here the same rule applies
> and the CA keys and roots are exclusively controlled by StartCom. In the
> same manner, StartCom has overall responsibility, oversight and rights.
> 

Please provide this information.

Also, please provide any other relevant information/updates regarding this root certificate that may be pertinent to the upcoming public discussion of this request.

Comment 10

[Eddy Nigg (StartCom)]

(In reply to Kathleen Wilson from comment #9) 
> Please provide the test website.

This should work seamless with any currently valid certificate - e.g. https://www.startssl.com/ 

> Also, please provide any other relevant information/updates regarding this
> root certificate that may be pertinent to the upcoming public discussion of
> this request.

Nothing has changed in this respect. All CA certificates that can issue certificates to end-users are controlled by StartCom - in fact ANY CA certificate in this PKI is controlled by us, being it sub or cross-signed. All end-user certificates must undergo a domain control validation for servers (at least), email control validation for client S/MIME and obviously a higher identity and/or organization validation for code signing.

Comment 11

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 12

[Kathleen Wilson]

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 [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 “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.

Comment 13

[Kathleen Wilson]

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 SHA-256 version of the “StartCom Certification Authority” root certificate that is currently included in NSS, 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: [e-mail] [e-mail]  [e-mail] 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 SHA-256 version of the “StartCom Certification Authority” root certificate that is currently included in NSS, turn on all three trust bits, and enable EV.

Comment 14

[Kathleen Wilson]

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 #13, and on behalf of Mozilla I approve this request from StartCom to include the following root certificate in Mozilla:

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

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

Comment 15

[Kathleen Wilson]

I have filed bug #751954 against NSS and bug #751960 against PSM for the actual changes.

Comment 16

[Eddy Nigg (StartCom)]

Thanks a bunch for your efforts!