Additional StartCom CA root

RESOLVED FIXED

Status

NSS
CA Certificate Root Program
P1
enhancement
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: Eddy Nigg (StartCom), Assigned: gerv)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

Request for an additional CA certificate of the StartCom CA to be included in NSS module. This root certificate will be used by the StartCom CA at a future date, with the goal of replacing the current CA root certificate ( https://bugzilla.mozilla.org/show_bug.cgi?id=338552 ) eventually. Depending on the timing of software releases of Mozilla products (Firefox, Thunderbird) and other software vendors, including the phasing out of valid issued certificates of subscribers, the current StartCom CA root shall be removed from NSS. We will submit another request once this can be done safely (estimate 2-3 years from now).

The additional certificate supports a higher level of security (Key,Hash) and generally conform better to current and suggested future standards.

Thanks a lot!

Reproducible: Always
(Reporter)

Comment 1

12 years ago
Created attachment 247013 [details]
Additional StartCom CA Root Certificate

Updated

12 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think Frank Hecker must review this request before we can act on it.
I cannot find a request for this on Frank Hecker's list of requests,
so I am putting this request on his queue.  When Frank has approved
this request, he can file a separate bug against NSS, or reassign this
bug back to NSS.
Assignee: nobody → hecker
Severity: normal → enhancement
Component: Libraries → CA Certificates
Product: NSS → mozilla.org
QA Contact: libraries
Version: unspecified → other
QA Contact: ca-certificates
Priority: -- → P1
Hi Eddy,

There are a large number of outstanding CA requests, and it will take me some time to work through them. You can, should you wish, speed up the processing of your request by providing the following data in the following format. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

Some of the information may already be present in, or calculable from, data in this bug or other Mozilla-maintained documents. However, having it all in one place in a standard format for each request will save me a great deal of time, and help me to make everyone happier quicker. :-)

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

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy
Certificate URL (on CA website):
Version:
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL URL:
OCSP URL:
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):
(Reporter)

Comment 5

11 years ago
CA Name:		StartCom Certification Authority, StartCom Ltd.
Website:		http://www.startssl.com/, http://cert.startcom.org/
General nature:		Commercial
Geographical:		Worldwide
Subordinate CAs:	Currently 8
Audit Type:		AICPA/CICA
Auditor:		We! Consulting Group
Auditor Website:	http://www.we-can.co.il
Audit Document URL(s):	http://cert.startcom.org/audit.pdf

The StartCom CA has been added recently to the NSS certificate store. Please see http://hecker.org/mozilla/ca-certificate-list#startcom

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

Certificate Details: 	https://bugzilla.mozilla.org/attachment.cgi?id=247013
Class:			Single root CA certificate.
Certificate Policy:	http://cert.startcom.org/policy.pdf
			http://cert.startcom.org/intermediate.pdf
Trust Indicators:	Server SSL, Client S/MIME
			(Pending policy extension also Code)
Eddy: please can you provide:

- A URL on your website to a copy of the root cert, in a format suitable for importing into Firefox
- The name you wish the certificate to have in the root CA store (your current certificate is called "Free SSL Certification Authority")
- The URL of your OCSP responder, if any
- The type of validation you do (DV or OV or both)
- A URL to your Certificate Practice Statement

Thanks,

Gerv
(Reporter)

Comment 7

11 years ago
(In reply to comment #6)
> 
> - A URL on your website to a copy of the root cert, in a format suitable for
> importing into Firefox

It is located at http://cert.startcom.org/sfsca.crt, but I suggest that we'll prepare a patch like last time and ship it in a secure manner to Wan-The again.

> - The name you wish the certificate to have in the root CA store (your current
> certificate is called "Free SSL Certification Authority")

This should be the common name (CN) field, which has changed to "StartCom Certification Authority".

> - The URL of your OCSP responder, if any

OCSP responders are operated for subscriber certificates, but not the CA root.

There are X509v3 CRL Distribution Points for the CA root: 
- http://cert.startcom.org/sfsca-crl.crl
- http://crl.startcom.org/sfsca-crl.crl

> - The type of validation you do (DV or OV or both)

Various levels, from domain validated and up.

> - A URL to your Certificate Practice Statement

It is the same as the policy. The document serves as the StartCom CA policy and practices. Hope this helps!
> OCSP responders are operated for subscriber certificates, but not the CA root.

Great. Where? :-)

Gerv
(Reporter)

Comment 9

11 years ago
The OCSP service URL is embedded within the certificates. See also http://cert.startcom.org/?lang=en&app=110#ocsp 

Example of the relevant section of a certificate is typically:

Authority Information Access:
     OCSP - URI:http://ocsp.startcom.org/sub/class2/server/ca
     CA Issuers - URI:http://cert.startcom.org/sub.class2.server.ca.crt
I have gathered together all the information you have provided, and placed it in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/

Please confirm that the information for your CA is correct, and add a comment to this bug to that effect. Once you have done that, your application will turn "green" and be ready for consideration.

If your CA or certificate does not have a summary paragraph, please feel free to provide one. Note: these paragraphs are not supposed to be marketing statements :-)

Gerv
(Reporter)

Comment 11

11 years ago
I confirm to have review the information at  http://www.mozilla.org/projects/security/certs/pending/#id0x0a5e45a8 as correct. A summary paragraph is not needed. Thanks!
(Reporter)

Comment 12

11 years ago
This should have been "to have reviewed"...
I have begun this evaluation. Some questions:

Your audit is to WebTrust criteria, even if your auditor was not certified by WebTrust. The WebTrust criteria state that CAs must be re-audited every 12 months. Do you plan to get re-audited and, if so, when?

Your policy document 1.3 is dated 27th September 2006, and contains no updates to reflect the fact that you are issuing a new root - not even to the certificate hierarchy diagram on page 5. Do you plan to update the document?

While you are revising it, can you please add page numbers?

Gerv
(Reporter)

Comment 14

11 years ago
(In reply to comment #13)

> Your audit is to WebTrust criteria, even if your auditor was not certified by
> WebTrust. The WebTrust criteria state that CAs must be re-audited every 12
> months. Do you plan to get re-audited and, if so, when?
> 
StartCom doesn't participate in the webtrust program and webtrust seal. However the nature and complexity of StartComs operations is simple and there were no changes of the CA business, policy or infrastructure, therefore a re-audit is currently not needed. 

> Your policy document 1.3 is dated 27th September 2006, and contains no updates
> to reflect the fact that you are issuing a new root - not even to the
> certificate hierarchy diagram on page 5. Do you plan to update the document?
> 
The structure of the CA will not change and there will be only one operating CA root. As indicated in the request, the goal is to replace the current CA root certificate eventually.

The CA policies and practices will be adjusted in the future to reflect differences of URL locations. There will be no other changes and the switch to the new root will be performed according to our internal guidelines. 

> While you are revising it, can you please add page numbers?
> 
For your convenience the html version is in one page only:
http://cert.startcom.org/index.php?app=125
http://cert.startcom.org/index.php?app=126

(In reply to comment #14)
> StartCom doesn't participate in the webtrust program and webtrust seal. 

This is true. However, you have voluntarily agreed to be audited to WebTrust standards, and it was on this basis that you were included in the Mozilla root store. Doesn't that include frequency of re-audit?

> However
> the nature and complexity of StartComs operations is simple and there were no
> changes of the CA business, policy or infrastructure, therefore a re-audit is
> currently not needed. 

You've added a new root - I'd call that a reasonably big change, even if the supposed uses for the new root are the same as the old ones. But regardless, the WebTrust guidelines say that a yearly re-audit is required even if there is no change in published procedure.

I am also concerned that you think it's your responsibility to decide when a new audit is needed. After all, if every CA decided when it was that they'd like to be audited, there would be very few audits done!

> The structure of the CA will not change and there will be only one operating 
> CA
> root. As indicated in the request, the goal is to replace the current CA root
> certificate eventually.

I'm sure that's true; however, the certificate hierarchy diagram still needs to be updated to reflect how the new root relates to the old ones (if at all) and what intermediate certificates you have issued.

> The CA policies and practices will be adjusted in the future to reflect
> differences of URL locations. There will be no other changes and the switch to
> the new root will be performed according to our internal guidelines. 

Were these internal guidelines reviewed as part of your original audit?

> > While you are revising it, can you please add page numbers?
> > 
> For your convenience the html version is in one page only:
> http://cert.startcom.org/index.php?app=125
> http://cert.startcom.org/index.php?app=126

Page numbers are useful in order to refer to a particular, small section of the document. Having it all on one page does not help with this aim :-)

Gerv
(Reporter)

Comment 16

11 years ago
I'd like to refer to the Independent Audit Report at https://cert.startcom.org/audit.html for further information concerning the extend of discloser and commitment StartCom has undertaken. Additionally the Mozilla CA policy at http://www.mozilla.org/projects/security/certs/policy/ doesn't require any re-validation currently.
(Reporter)

Comment 17

11 years ago
I'd like to offer an additional reply to the previous post of Gerv. Due to time constrains, my last post was somewhat short.

The issuance and handling of keys and certificates is the natural part of the Public Key Infrastructure (PKI) of the CA business, being it root, intermediate or subscriber keys. The CA policies, practices and regulations of the CA govern each of thouse, which is also disclosed and confirmed usually by a third party audit.

Issuance of a new/additional root certificate is not a change to the CA policies, but the implementation thereof - which is a clearly defined process. The issuance processes of any key - being it root, intermediate and subscriber keys and certificates is performed according to the relevant criteria and this is what an audit (https://cert.startcom.org/audit.html) confirms. Specifically see section <b>Service Integrity</b>, which includes explicit:


          o

            CA Key Generation
          o

            CA Key Storage, Backup and Recovery
          o

            CA Public Key Distribution
          o

            CA Key Usage
          o

            CA Key Destruction
          o

            CA Key Archival
          o

            CA Cryptographic Hardware Life Cycle Management

I hope this explains why adding a new root is <b>NOT</b> a change at all what the conduction of the CA operations concerns and this root can be added swiftly to the NSS certificate store, specially since the current root was approved less then a year ago.
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at: http://www.mozilla.org/projects/security/certs/policy/ . On behalf of the Mozilla project, I apologise for the delay.

Here follows my assessment. StartCom is responsible for informing me if any of the below information is incorrect.

Section 4 [Technical]. I'm 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 issues no-charge certificates for SSL server use as well an personal email certificates. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

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

* Email: For certificates with the E-mail Protection EKU (1.3.6.1.5.5.7.3.4), Startcom verifies that the entity submitting the request controls the email account associated with the email address referenced in the certificate. (See page 17 of the policy document.)

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), StartCom verifies domain control by sending an email to one of the standard addresses (webmaster@domain, etc.) associated with the domain. (See page 16 of the policy document.) StartCom also issues class 2 and, occasionally, class 3 personal and server certs, with additional verification requirements.

* Code: StartCom does not currently issue code signing certs.

Section 8-10 [Audit]. StartCom has successfully completed an independent audit using the WebTrust for CAs criteria. The auditors were We! Consulting.

Section 13 [Certificate Hierarchy]. StartCom issues different classes of certificate from different intermediate roots, as shown in the certificate hierarchy diagram on page 5 of the policy document.

Other: StartCom issues CRLs (on a 12-hour schedule) and also has an OCSP responder.

I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post on the mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks.

Gerv
Bug 383722 has now been opened to track the inclusion of this certificate in the root store.

Gerv
This bug is fixed.

Gerv
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

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