451298 - Enable EV and code signing for StartCom Root

Status: RESOLVED FIXED

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

Description

[Eddy Nigg (StartCom)]

I'm requesting hereby to enable the StartCom CA root which is already included in NNS for EV and code signing.

The StartCom CA root subject key ID is 4E:0B:EF:1A:A4:40:5B:A5:17:69:87:30:CA:34:68:43:D0:41:AE:F2

The StartCom CA root SHA1 fingerprint is 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F

The StartCom EV policy OID is 1.3.6.1.4.1.23223.2

The CP/CPS applying for EV is https://www.startssl.com/policy.pdf and https://www.startssl.com/extended.pdf

The CP/CPS applying for enabling object code signing is https://www.startssl.com/policy.pdf

Publication of the WebTrust and EV WebTrust audit statements will be supplied approximately end of October.

The StartCom Authority Certificates Repository is at https://www.startssl.com/certs/

Web sites for checking of EV are available at https://forum.startcom.org and https://blog.startcom.org

The StartCom PKI is structured by different Class levels (1 - 3, EV) and different purposes (SSL/TLS Server, Client S/MIME, Object Code) and every Class and purpose is handled by a different intermediate CA. Therefore an intermediate CA certificate is responsible for the signing if EV end-user server certificates. 

CRLs of subscriber certificates are updated at least every 12 hours or every time a certificate is revoked, whichever comes first. CRLs are published via Internet download. Each intermediate CA issues its own corresponding CRL for the certificates it issues. The CRL distribution points are included in the certificates. The CRL of root and intermediate CA certificates are updated once a year.

OCSP responder service is provided and the respective URL location of the service are included in the certificates. The current CRLs are reloaded at least every 60 minutes.

Comment 1

[Eddy Nigg (StartCom)]

Gosh...I misspelled NSS :-)

Comment 2

[Kathleen Wilson]

Accepting this bug so I can proceed with the information gathering and verification phase.

Comment 3

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the initial information gathering document which summarizes the information that has been gathered and verified. Within the document the information that is still needed is highlighted in yellow. Other than the pending audit documents, I’ll summarize the areas where more information or clarification is needed below.

1) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/, I look for text in the CP/CPS that demonstrates that reasonable measures are taken to verify information for end-entity certificates. 

a) I found that verification of email address and domain names is described for Class 1 in https://www.startssl.com/policy.pdf  in the section called “Certification Rules”.  It's not clear for Class 2, 3, and EV?

b) Can you point me to the part of Policy & Practices Statements document that addresses the following? The context for code signing needs to be clear.
“for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;”


2) I’m supposed to review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. Here are my comments. Please confirm/correct/clarify.

a) Long-Lived Domain-Validated SSL certs – Not applicable, the DV SSL certs are good for one year.

b) Wildcard DV SSL certs
Found in https://www.startssl.com/policy.pdf section called “Certification Rules”: “Wild card domain names like *.domain.com are only issued to Class 2 or higher validated subscribers. Likewise multiple domain names within the same certificate are not supported in the Class 1 settings.
Class 2 are OV, so this issue is not applicable.  Correct?

c) Issuing end entity certs directly from root rather than using an offline root and issuing certs through a subordinate CA – Not applicable, From https://www.startssl.com/policy.pdf: “The StartCom CA root is an off-line CA and shall be used only for the signing of Intermediate CA certificates and the relevant Certificate Revocation Lists.

d) Allowing external entities to operate subordinate CAs – Not applicable, All sub-CAs are operated in StartCom premises.

e) Distributing generated private keys in PKCS#12 files -- Not Found

f) Certificates referencing hostnames or private IP addresses -- It looks like IP addresses can be referenced, as per https://www.startssl.com/policy.pdf section called “Certification Rules”


Thanks,
Kathleen

Comment 4

[Eddy Nigg (StartCom)]

Thanks Kathleen,

I'll submit the audit statement the minute it's ready. Auditor is Ernst&Young. Hereby the clarifications you were seeking.

1.a) Each Class is addressed under the StartCom CA Policy -> Certification Rules -> Validations -> Class X. For example Class 2 -> Personal Identity addresses that the listed details are "correct without any reasonable doubt". StartCom implements cross-verification procedures by using third party sources and/or by the sending of a verification code via registered postal mail to the name and address as found in the submitted documents. Validation procedures for EV are performed according to the EV guidelines as published by the CA/Browser forum.

1.b) Under the StartCom CA Policy -> Certificate Profiles -> Naming conventions, each certificate Class and Type is listed. Object Code Signing is not applicable under Class 1 and not listed and not issued. The minimum validation level for Object Code Signing is Class 2 -> Identity Validation. Also note that no Class 1 Intermediate CA certificate exists for object code signing.

2.a) Correct. All EE certificates are issued for one year only, this applies also to Class 1 domain validated server certificates.

2.b) Correct. Wild cards and multiple domain names (SNI) require at least Class 2 validation. Class 2 is identity validated for individuals, organization validation is optional. However OV always implies prior IV validation of the subscriber (and therefore responsible person).

2.c) Correct.

2.d) Correct.

2.e) Correct.

2.f) Correct. The issuing of IP based certificates is maintained (for historical reasons) for the StartCom Intermediate CA Program and conditional. Currently StartCom does not issue certificates for IP addresses from this root but only for fully qualified domain names.

Comment 5

[Kathleen Wilson]

Thank you for the clarifications.

I've added an entry for this request to the pending list:
http://www.mozilla.org/projects/security/certs/pending/#StartCom

Thanks,
Kathleen

Comment 6

[Eddy Nigg (StartCom)]

Attachment: Independent Accountants Report - WebTrust for Certification Authorities

Comment 7

[Eddy Nigg (StartCom)]

Attachment: Independent Accountants Report - WebTrust Extended Validation

Comment 8

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 9

[Kathleen Wilson]

This concludes the Information Gathering and Verification phase of this request, as per
https://wiki.mozilla.org/CA:How_to_apply

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

Comment 10

[Kathleen Wilson]

I am now opening the first public discussion period for this request from StartCom to enable EV and add the Code Signing trust bit for the StartCom Certification Authority root certificate which is already included in NSS.

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 EV-Enablement Request”

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

Comment 11

[Eddy Nigg (StartCom)]

A site with a revoked EV certificate was requested during discussion. We've created https://bad.startcom.org/ for this purpose.

Comment 12

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA 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 StartCom’s request to enable the StartCom Certification Authority root CA certificate for EV and also to add the code signing trust bit. This root is already in the Mozilla root store.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by StartCom, 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]. StartCom appears to provide a service relevant to Mozilla users: It is a commercial corporation with customers worldwide.

The certificate policies for StartCom are published on their website and listed in the entry on the pending applications list. The main documents are the Certification Authority Policy and Practice Statements and the Certification Authority Extended Validation Certificates Policy Appendix. Both are provided in English.

https://www.startssl.com/policy.pdf
https://www.startssl.com/extended.pdf

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

* Email: StartCom verifies the ownership of the email address provided by the requester by sending an electronic mail message with a verification code to the email account in question. The subscriber has to return and submit the verification code as prove of ownership of the email account within a limited period sufficient enough to receive an electronic mail message.

* SSL: StartCom verifies the ownership of the domain name referenced in the certificate by using the whois service.

* Code: StartCom’s CPS describes reasonable measures to verify the identity and authorization of the certificate requester. The minimum validation level for Object Code Signing is Class 2 -> Identity Validation.

Section 8-10 [Audit]. Section 8-10 [Audit].  StartCom has been audited by Ernst & Young according to the WebTrust CA and the WebTrust EV criteria. Both audits are current. They were both attached to this bug, and I exchanged email directly with the auditor to confirm the authenticity of the reports.

Section 13 [Certificate Hierarchy].  The StartCom PKI is structured by different Class levels (1 - 3, EV) and different purposes (SSL/TLS Server, Client S/MIME, Object Code) and every Class and purpose is handled by a different intermediate CA. Therefore an intermediate CA certificate is responsible for signing EV server certificates. There are also two intermediate CAs (class 2 and class 3) that sign certificates for code signing. All of the intermediate CAs are operated at StartCom’s premise.

Other: The CRLs generated by StartCom have a validity period of 12 hours. OCSP is also provided.

Potentially problematic practices: 

StartCom is planning to address the following items that were noted during the public discussion. I do not believe that any of these should prevent Mozilla from proceeding with approving this request.
a) The intermediate EV certificate has an empty value in the issuerAltName extension. 
b) The CP/CPS doesn't list the Business Category field in the certificates profile for EV certificates. 
c) The "Extended Validation Certificates Policy Appendix" status is currently at version 0.9 and marked as "Draft". 

Based on this assessment I recommend that Mozilla approve the request to enable the StartCom Certification Authority for EV, and also to add the code signing trust bit.

Comment 13

[Eddy Nigg (StartCom)]

Thanks Kathleen for your excellent summary. The "Extended Validation Certificates Policy Appendix" mentioned under (c) which was pending has been finalized, approved and published today.

Comment 14

[Kaspar]

(In reply to comment #12)
> Here follows a summary of the assessment. If anyone sees any factual errors,
> please point them out.

> Other: The CRLs generated by StartCom have a validity period of 12 hours.

This is not correct. As of today, all CRLs available at the CDPs on crl.startssl.com and www.startssl.com have a "validity period" (time delta between thisUpdate and nextUpdate) of 48 hours.

Comment 15

[Eddy Nigg (StartCom)]

Kaspar is correct, I suspect that Kathleen meant to say that CRLs are updated every 12 hours (at least).

Comment 16

[Frank Hecker]

To Kathleen: Thank you for your work on this request.

To Eddy: Thank you for your cooperation and your patience.

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

I have reviewed the summary and recommendation in comment #12, and on behalf of
the Mozilla project I approve this request from StartCom to enable the StartCom Certification Authority for EV, and also to enable the code signing trust bit.

Kathleen, could you please do the following:

1. File the necessary bugs against NSS (for the object signing bit) and PSM (for the EV enablement).
2. Mark this bug as dependent on the PSM and NSS bugs.
3. When those bugs are complete, change the status of this bug to RESOLVED
FIXED.

Thanks in advance!

Comment 17

[Kathleen Wilson]

I have filed bug 490495 against NSS and bug 490492 against PSM for the actual changes.

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

I believe this bug was fixed by the checkin for 
Bug 493709 -  Combined EV enablement 
so I am resolving this bug as fixed.  
Please reopen it if it is not fixed.
I hope Kathleen doesn't mind me resolving these bugs.