Closed
Bug 640368
Opened 14 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)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: eddy_nigg, Assigned: kathleen.a.wilson)
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.
Assignee | ||
Comment 1•14 years ago
|
||
What is the relation between this request and the one in bug #602750?
Reporter | ||
Comment 2•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Status: NEW → ASSIGNED
Whiteboard: EV- information incomplete
Assignee | ||
Comment 3•14 years ago
|
||
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.
Reporter | ||
Comment 4•14 years ago
|
||
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.
Assignee | ||
Comment 5•14 years ago
|
||
The items highlighted in green indicate where updates will be needed before
starting the public discussion.
Assignee | ||
Comment 6•14 years ago
|
||
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
Reporter | ||
Comment 7•14 years ago
|
||
Thank you, as always.
Reporter | ||
Comment 8•14 years ago
|
||
Reporter | ||
Comment 9•14 years ago
|
||
Reporter | ||
Comment 10•14 years ago
|
||
Reporter | ||
Comment 11•13 years ago
|
||
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
Reporter | ||
Comment 12•13 years ago
|
||
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.
Assignee | ||
Comment 13•13 years ago
|
||
Attachment #520812 -
Attachment is obsolete: true
Assignee | ||
Comment 14•13 years ago
|
||
(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.
Reporter | ||
Comment 15•13 years ago
|
||
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*.
Assignee | ||
Comment 16•13 years ago
|
||
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?
Reporter | ||
Comment 17•13 years ago
|
||
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.
Assignee | ||
Comment 18•13 years ago
|
||
Attachment #581837 -
Attachment is obsolete: true
Assignee | ||
Comment 19•13 years ago
|
||
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
Assignee | ||
Comment 20•13 years ago
|
||
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
Assignee | ||
Comment 21•13 years ago
|
||
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
Assignee | ||
Comment 22•13 years ago
|
||
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.
Reporter | ||
Comment 23•13 years ago
|
||
The site https://g2.startcom.org/ is now with an EV certificate.
Assignee | ||
Comment 24•13 years ago
|
||
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
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - awaiting NSS and PSM → In FF16
Updated•8 years ago
|
Product: mozilla.org → NSS
Updated•2 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•