StartCom Root Inclusion Request for Renewed and G2 Roots

[Kathleen Wilson]

StartCom, a commercial corporation with customers worldwide, has
requested to include the SHA-256 version of the “StartCom Certification
Authority” root certificate that is currently included in NSS, and the
“StartCom Certification Authority G2” root certificate. For both
certificates the request is to turn on all three trust bits, and to
enable EV.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=602750
Information Verified: https://bugzilla.mozilla.org/attachment.cgi?id=611672
Add the SHA-256 version of the “StartCom Certification Authority” root
certificate that is currently included in NSS.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=640368
Information Verified: https://bugzilla.mozilla.org/attachment.cgi?id=611661
Add the “StartCom Certification Authority G2” root certificate.

These requests are also summarized in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#StartCom

Noteworthy points:

* The CP/CPS documents are in English:
Document Repository: https://www.startssl.com/?app=26
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

* These root certificates are offline, and sign internally-operated sub-CAs.
** CP/CPS: 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.

The request is to turn on all three trust bits, and to also enable EV
for both roots.

According to the “Certificate Profiles” section of the CP/CPS, S/MIME
and SSL/TLS server certificates may be issued under Class 1, 2, or 3
verification procedures. Code Signing certificates may be issued under
Class 2 or Class 3 verification procedures.

* From the CP/CPS regarding Class 1 verification procedures:
** Email accounts are validated 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.
** Fully qualified domain names, typically “www.domain.com” or
“domain.com” are validated by sending an electronic mail message with a
verification code to one of the following administrative electronic mail
accounts: webm...@domain.com hostm...@domain.com
postm...@domain.com The subscriber has to return and submit the
verification code as prove of ownership of the domain name within a
limited period sufficient enough to receive an electronic mail message.
Additionally the existence of the domain name is verified by checking
the WHOIS records provided by the domain name registrar. If the WHOIS
data contain additional email addresses, they may be offered as
additional choices to the above mentioned electronic mail accounts.
The StartCom CA performs additional sanity and fraud prevention checks
in order to limit accidental issuing of certificates whose domain names
might be misleading and/or might be used to perform an act of fraud,
identity theft or infringement of trademarks.
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.
** IP Addresses representing a dotted IPv4 address, typically “10.0.0.1”
(*) are validated by sending a electronic mail message with a
verification code to one of the following administrative mail accounts:
webm...@10.0.0.1 hostm...@10.0.0.1 postm...@10.0.0.1 The
subscriber has to return and submit the verification code as prove of
ownership of the domain name within a limited period sufficient enough
to receive an electronic mail message.
(The IP 10.0.0.1 is an illustrative example.)

* From the CP/CPS regarding Class 2 verification procedures:
** The verification process of personal identities of subscribers are
performed manually. The StartCom CA validates without any reasonable
doubt that the following details are correct: First and last name,
Residence, Address, State or Region, Country
** StartCom verifies the correctness of the identity through
confirmation procedures of the submitted documents with third party
sources and cross-verification of the claimed identity. In the absence
of third party sources or listing thereof, a registered postal mail is
sent to the claimed address and identity.
The validation may be valid for 350 days for the generation of digital
certificates.
** The verification process of organizations implies same level identity
validation of the subscriber (responsible person) and are performed
manually. The StartCom CA validates without any reasonable doubt that
the following details are correct: Registered organization name,
Address, State or Region, Country
** StartCom verifies the correctness of the organization details through
confirmation procedures of the submitted documents with third party
sources and cross-verification of the claimed organization. In the
absence of third party sources or listing thereof, a registered postal
mail is sent to the claimed address and organization name.

* From the CP/CPS regarding Class 3 verification procedures:
** Class 3 validation is reserved for specially trusted entities to
which the StartCom CA has usually a relationship like business
partnership which includes employees, investors, business partners and
operators of intermediate CAs. The StartCom CA management knows without
any doubt the entity in question. The StartCom CA is in the possession
or has reviewed original documents during face-to-face meetings about
the entity in question.

* From the CP/CPS regarding EV verification procedures:
** Extended Validation (EV) Certificates implements the validation
procedures and requirements of the Extended Validation Guidelines as
published by the CA/Browser Forum. EV extends Class 2 validation and
organizations are required to designate a responsible person which is at
least Class 2 identity validated prior to any engagement for extended
validation.

* Root Cert Download URLs
https://www.startssl.com/certs/ca-sha2.pem
https://bugzilla.mozilla.org/attachment.cgi?id=572356

* Test websites:
https://www.startssl.com/
https://g2.startcom.org/

* CRL
http://cert.startcom.org/sfsca-crl.crl
http://crl.startssl.com/ca-g2.crl
http://crl.startssl.com/sfsca.crl
http://crl.startssl.com/crt3-crl.crl (NextUpdate: 2 days)
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.

* OCSP
http://ocsp.startcom.org/sub/class2/server/ca
http://ocsp.startssl.com/ca-g2
http://ocsp.startssl.com/ca
http://ocsp.startssl.com/sub/class3/server/ca
EV: http://ocsp.startssl.com/sub/class4/server/ca
CP/CPS: The OCSP responder provides results about the status of a
certificate instantly. The current CRLs are reloaded at least every 60
minutes.

* Audits: 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

* Potentially Problematic Practices -- None Noted
http://wiki.mozilla.org/CA:Problematic_Practices

This begins the discussion of the request from StartCom to include the
SHA-256 version of the “StartCom Certification Authority” root
certificate and the “StartCom Certification Authority G2” root
certificate. For both certificates the request is to turn on all three
trust bits, and to enable EV.

At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of each request in
the corresponding bug.

Kathleen

[Erwann Abalea]

Le mardi 3 avril 2012 22:08:08 UTC+2, Kathleen Wilson a écrit :
> StartCom, a commercial corporation with customers worldwide, has
> requested to include the SHA-256 version of the “StartCom Certification
> Authority” root certificate that is currently included in NSS, and the
> “StartCom Certification Authority G2” root certificate. For both
> certificates the request is to turn on all three trust bits, and to
> enable EV.

[...]

This needs to stay up, to help reduce the list length.

Just a question, how does the NSS react with non-coherent certificatePolicies chains? Startcom is not concerned as far as I can see, but some CAs use policyIds in an improper way, using an OID in and EE certificate issued by a CA limited to a set of policyIds (most of the time it's a set of 1 element) different than the one used below.
Is the chaining strictly respected? And for EV?

[Kyle Hamilton]

On Tue, Apr 17, 2012 at 11:09 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Le mardi 3 avril 2012 22:08:08 UTC+2, Kathleen Wilson a écrit :

>> StartCom, a commercial corporation with customers worldwide, has
>> requested to include the SHA-256 version of the “StartCom Certification
>> Authority” root certificate that is currently included in NSS, and the
>> “StartCom Certification Authority G2” root certificate. For both
>> certificates the request is to turn on all three trust bits, and to
>> enable EV.

> [...]
>
> This needs to stay up, to help reduce the list length.
>
> Just a question, how does the NSS react with non-coherent certificatePolicies chains? Startcom is not concerned as far as I can see, but some CAs use policyIds in an improper way, using an OID in and EE certificate issued by a CA limited to a set of policyIds (most of the time it's a set of 1 element) different than the one used below.
> Is the chaining strictly respected? And for EV?

Currently, I don't think NSS does policy checking. This will change with the advent of libpkix.

-Kyle H

[Kathleen Wilson]

Erwann, I have forwarded your questions to the NSS Team.

This discussion has been open for 3 weeks, with no questions/concerns
raised about these particular requests from StartCom.

This CA is already in Mozilla's program, has gone through the evaluation
process again, and has current audit statements.

If there are no comments on these requests from StartCom, then I plan to
close this discussion and recommend approval in the bugs.

Thanks,
Kathleen

[Kathleen Wilson]

On 4/24/12 11:55 AM, Kathleen Wilson wrote:
> On 4/17/12 11:09 AM, Erwann Abalea wrote:
>> Le mardi 3 avril 2012 22:08:08 UTC+2, Kathleen Wilson a écrit :
>>> StartCom, a commercial corporation with customers worldwide, has
>>> requested to include the SHA-256 version of the “StartCom Certification
>>> Authority” root certificate that is currently included in NSS, and the
>>> “StartCom Certification Authority G2” root certificate. For both
>>> certificates the request is to turn on all three trust bits, and to
>>> enable EV.
>> [...]
>>

> This discussion has been open for 3 weeks, with no questions/concerns
> raised about these particular requests from StartCom.
>
> This CA is already in Mozilla's program, has gone through the evaluation
> process again, and has current audit statements.
>
> If there are no comments on these requests from StartCom, then I plan to
> close this discussion and recommend approval in the bugs.
>
> Thanks,
> Kathleen

I will post a summary of these requests and my recommendation for
approval in the bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=602750
https://bugzilla.mozilla.org/show_bug.cgi?id=640368

I am now closing this discussion. Any further follow-up on these
requests should be added directly to the bugs.

Thanks,
Kathleen