certSIGN Root Inclusion Request

[Kathleen Wilson]

As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
certSIGN is the next request in the queue for public discussion.

certSIGN (a private corporation in Romania) has applied to add the
“certSIGN ROOT CA” root certificate and enable the Websites, Email,
and Code Signing trust bits.

The request is documented in the following bug:

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

And in the pending certificates list here:

http://www.mozilla.org/projects/security/certs/pending/#certSIGN

Summary of Information Gathered and Verified:

https://bugzilla.mozilla.org/attachment.cgi?id=405591

Noteworthy points:

* The CPS is provided in English:
http://www.certsign.ro/certsign_en/files/certSIGN_CPS_EN.pdf

* This root has 4 internally-operated subordinate CAs for different
classes of certificates based on use and verification requirements:
** certSIGN CA Class 2: Simple certificates used for authentication,
signing, and encryption.
** certSIGN Qualified CA Class 3: Qualified Certificates
** certSIGN Enterprise CA Class3: Certificates used for SSL, code
signing, VPN gateways.
** certSIGN Non-Repudiation CA Class 4: CA Servers Certificates used
for Time Stamping and OCSP.

* The request is to enable the Websites, Email, and Code Signing trust
bits.

** CPS Section 3.1.7: The procedure performed by RA of checking the
legal entity’s identity and its authorized representative’s identity
consists of (see as well Table 3.1.8):
- Checking the documents rendered by the Subscriber,
- Checking the request, that consists of:
-- Checking the compliance of the data mentioned in the request with
those from the documents rendered,
-- (optional) checking the proof of private key possession (if the
request supposes a key pair to create an electronic signature) and the
fact that the Distinctive Name is the right one,
- Checking the authorization and identity of the representative of the
legal entity that submits the request (including applications for
certification as Certification Authority) on behalf of this entity.
- Checking for certificates to be used for SSL-enabled servers, that
the domain referenced in the certificate is registered by the entity
submitting the certificate request or by that that has authorized the
usage of domain by the entity submitting the request. This is done be
means of whois service provided by ROTLD at www.rotld.ro
- Verification that the email account associated with the email
address in the certificate is controlled by the subscriber. The
certificate request cannot be made/validated in the RA software
application if the subscriber does not validate his email account.
The Registration Authority is committed to check the correctness and
the authenticity of all data rendered in a request (see Table 3.1.8,
Chapter 3.1.9).

** SSL and Code Signing certificates are issued by the certSIGN
Enterprise CA Class3 sub-CA, so they are always organizationally
validated.

* Test website: https://www.certsign.ro/certsign_en/

* certSIGN provides CRL, NextUpdate is 48 hours
* certSIGN provides OCSP: http://ocsp.certisgn.ro

* Audit: certSIGN is audited annually against the WebTrust CA criteria
by Ernst & Young. Their recent audit was attached to the bug report,
https://bug470756.bugzilla.mozilla.org/attachment.cgi?id=361730. I
confirmed the authenticity of the document via an email exchange with
a contact at Ernst & Young.

* Other

** The certSIGN Non-Repudiation CA Class 4 could issue certificates
for CA servers that might be operated by a third party. CPS Section
1.1: "For the time being, certSIGN does not have a mutual agreement
with another certificate issuing authority. If this situation will
change the users will be informed by publishing the new version of the
Certification Policy (CP) and of the Certification Practice Statement
(CPS)."

** There is a CA mentioned in the CPS for issuing demo certificates.
However, this “certSIGN Demo CA Class 1” CA is a selfsigned authority
-- it is not signed by the certSIGN ROOT CA.

This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may
be needed as follow-up.

Kathleen

[Eddy Nigg]

On 10/22/2009 08:23 PM, Kathleen Wilson:

> * This root has 4 internally-operated subordinate CAs for different
> classes of certificates based on use and verification requirements:
> ** certSIGN CA Class 2: Simple certificates used for authentication,
> signing, and encryption.
> ** certSIGN Qualified CA Class 3: Qualified Certificates
> ** certSIGN Enterprise CA Class3: Certificates used for SSL, code
> signing, VPN gateways.
> ** certSIGN Non-Repudiation CA Class 4: CA Servers Certificates used
> for Time Stamping and OCSP.
>
> * The request is to enable the Websites, Email, and Code Signing trust
> bits.
>

This request looks fine, I do have still some reading to do however.

> ** CPS Section 3.1.7: The procedure performed by RA of checking the
> legal entity’s identity and its authorized representative’s identity
> consists of (see as well Table 3.1.8):
>

In particular we ought to receive assurance that those RAs are properly
audited as well.

> * Test website: https://www.certsign.ro/certsign_en/
>
> * certSIGN provides CRL, NextUpdate is 48 hours
> * certSIGN provides OCSP: http://ocsp.certisgn.ro
>

Before continuing I would like to receive test certificates from all
intermediate CA issuers and if Kathleen or Nelson could perform a test
with OCSP set on hard fail and visit relevant sites, email signatures
etc. I suspect that this OCSP responder is not compliant.

> ** The certSIGN Non-Repudiation CA Class 4 could issue certificates
> for CA servers that might be operated by a third party. CPS Section
> 1.1: "For the time being, certSIGN does not have a mutual agreement
> with another certificate issuing authority. If this situation will
> change the users will be informed by publishing the new version of the
> Certification Policy (CP) and of the Certification Practice Statement
> (CPS)."
>

We need to know what the requirements and controls for external CAs are.
They should be audited as well (required by CA policy) or audited as
part of the CA. Since Mozilla doesn't have a review or re-auditing
requirement, this should be clarified and disclosed upfront. Again, this
should have been done as part of the WebTrust audit.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[cristian garabet]

On Oct 25, 3:41 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 10/22/2009 08:23 PM, Kathleen Wilson:
>
> > * This root has 4 internally-operated subordinate CAs for different
> > classes of certificates based on use and verification requirements:
> > ** certSIGN CA Class 2: Simple certificates used for authentication,
> > signing, and encryption.
> > ** certSIGN Qualified CA Class 3: Qualified Certificates
> > ** certSIGN Enterprise CA Class3: Certificates used for SSL, code
> > signing, VPN gateways.
> > ** certSIGN Non-Repudiation CA Class 4: CA Servers Certificates used
> > for Time Stamping and OCSP.
>
> > * The request is to enable the Websites, Email, and Code Signing trust
> > bits.
>
> This request looks fine, I do have still some reading to do however.
>
> > ** CPS Section 3.1.7: The procedure performed by RA of checking the
> > legal entity’s identity and its authorized representative’s identity
> > consists of (see as well Table 3.1.8):
>
> In particular we ought to receive assurance that those RAs are properly
> audited as well.

Answer:
It his not clear what other assurance is needed other that the one
provided by the E&Y Audit. According to 1.3.2 Registration Authority
from page 15 of the CPS:

“Registration Authority functions on the basis of the authorization
obtained from a Certification Authority corresponding to the CERTSIGN
domain and can operate only within CERTSIGN. Now, external
Registration Authorities are not allowed.”

>
> > * Test website:https://www.certsign.ro/certsign_en/
>
> > * certSIGN provides CRL, NextUpdate is 48 hours
> > * certSIGN provides OCSP:http://ocsp.certisgn.ro
>
> Before continuing I would like to receive test certificates from all
> intermediate CA issuers and if Kathleen or Nelson could perform a test
> with OCSP set on hard fail and visit relevant sites, email signatures
> etc. I suspect that this OCSP responder is not compliant.

Answer:
We have only one OCSP responder for the certificates issued by the
certSIGN Enterprise CA Class 3. In other words, the validity of the
certificates used for SSL, code signing and VPNs can be verified by
this mean. It is true that the OCSP responder issues responses also
for certificates issued by the other CAs, but we recommend usage of
CRLs for validity verification. In order to verify the OCSP responder
and the certificates issued by certSIGN, you can access the following
websites which use digital certificates issued by certSIGN:
- https://vpn.unicredit.ro/
- https://online.ratb.ro/
- https://mail.certsign.ro
- https://www.depozitarulcentral.ro

Regarding the other certs, please check ldap.certsign.ro.

>
> > ** The certSIGN Non-Repudiation CA Class 4 could issue certificates
> > for CA servers that might be operated by a third party. CPS Section
> > 1.1: "For the time being, certSIGN does not have a mutual agreement
> > with another certificate issuing authority. If this situation will
> > change the users will be informed by publishing the new version of the
> > Certification Policy (CP) and of the Certification Practice Statement
> > (CPS)."
>
> We need to know what the requirements and controls for external CAs are.
> They should be audited as well (required by CA policy) or audited as
> part of the CA. Since Mozilla doesn't have a review or re-auditing
> requirement, this should be clarified and disclosed upfront. Again, this
> should have been done as part of the WebTrust audit.
>

Answer:

In the CPS, page 21:

“certSIGN Certification Authority can register and issue a certificate
to any external entity that plays the role of subordinate
Certification Authority, provided that the registration and issuance
of the certificate are based on an agreement concluded between the two
parties.
The CPS and the Certification Policy are part of the contracts
concluded between CERTSIGN and Subscribers, Relying Parties or other
entities that provide services of public key infrastructure, such as
time stamp, certificate status verification etc.”

According to this, any external subordinate CA has to comply with the
same requirements described in the CP and CPS, as certSIGN.
Obviously, if we were to a sign a contract for an external CA under
certSIGN Non-Repudiation CA Class 4 CA we would impose the Web Trust
audit as a mandatory condition .

> --
> Regards
>
> Signer:  Eddy Nigg, StartCom Ltd.

> XMPP:    start...@startcom.org

> Blog:    http://blog.startcom.org/
> Twitter:http://twitter.com/eddy_nigg

Hi all!

See the answer above.

Regards,

Cristian

[Kathleen Wilson]

> > Before continuing I would like to receive test certificates from all
> > intermediate CA issuers and if Kathleen or Nelson could perform a test
> > with OCSP set on hard fail and visit relevant sites, email signatures
> > etc. I suspect that this OCSP responder is not compliant.
>
> Answer:
> We have only one OCSP responder for the certificates issued by the
> certSIGN Enterprise CA Class 3. In other words, the validity of the
> certificates used for SSL, code signing and VPNs can be verified by
> this mean. It is true that the OCSP responder issues responses also
> for certificates issued by the other CAs, but we recommend usage of
> CRLs for validity verification. In order to verify the OCSP responder
> and the certificates issued by certSIGN, you can access the following
> websites which use digital certificates issued by certSIGN:
> -      https://vpn.unicredit.ro/
> -      https://online.ratb.ro/
> -      https://mail.certsign.ro
> -      https://www.depozitarulcentral.ro

My Firefox browser is set to enforce OCSP, and I was able to go to all
of the websites listed above without error. For all of theses sites,
the SSL cert has AIA Extension: Not Critical, OCSP: URI: http://ocsp.certsign.ro

Kathleen

[Eddy Nigg]

On 10/27/2009 05:53 PM, cristian garabet:

> “Registration Authority functions on the basis of the authorization
> obtained from a Certification Authority corresponding to the CERTSIGN
> domain and can operate only within CERTSIGN. Now, external
> Registration Authorities are not allowed.”
>

Excellent for the clarification.

> We have only one OCSP responder for the certificates issued by the
> certSIGN Enterprise CA Class 3. In other words, the validity of the
> certificates used for SSL, code signing and VPNs can be verified by
> this mean. It is true that the OCSP responder issues responses also
> for certificates issued by the other CAs, but we recommend usage of
> CRLs for validity verification. In order to verify the OCSP responder
> and the certificates issued by certSIGN, you can access the following
> websites which use digital certificates issued by certSIGN:
> - https://vpn.unicredit.ro/
> - https://online.ratb.ro/
> - https://mail.certsign.ro
> - https://www.depozitarulcentral.ro
>

Your intermediate CAs also have the same OCSP responder URI. Are code
signing certificates issued also by the "certSIGN Enterprise CA Class 3"
issuer? Could you possibly provide a certificate which was issued
sometime from the last month or so?

> According to this, any external subordinate CA has to comply with the
> same requirements described in the CP and CPS, as certSIGN.
> Obviously, if we were to a sign a contract for an external CA under
> certSIGN Non-Repudiation CA Class 4 CA we would impose the Web Trust
> audit as a mandatory condition .
>

This requirement is very import, please include it in your CP/CPS. Why
are other external intermediate CAs not subject to the same requirement?

Thanks for your answers so far.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.

XMPP: star...@startcom.org

[cristian garabet]

On Oct 27, 8:47 pm, Eddy Nigg <eddy_n...@startcom.org> wrote:
> On 10/27/2009 05:53 PM, cristian garabet:
>
> > “Registration Authority functions on the basis of the authorization
> > obtained from a Certification Authority corresponding to the CERTSIGN
> > domain and can operate only within CERTSIGN. Now, external
> > Registration Authorities are not allowed.”
>
> Excellent for the clarification.
>
> > We have only one OCSP responder for the certificates issued by the
> > certSIGN Enterprise CA Class 3. In other words, the validity of the
> > certificates used for SSL, code signing and VPNs can be verified by
> > this mean. It is true that the OCSP responder issues responses also
> > for certificates issued by the other CAs, but we recommend usage of
> > CRLs for validity verification. In order to verify the OCSP responder
> > and the certificates issued by certSIGN, you can access the following
> > websites which use digital certificates issued by certSIGN:
> > -  https://vpn.unicredit.ro/
> > -  https://online.ratb.ro/
> > -  https://mail.certsign.ro
> > -  https://www.depozitarulcentral.ro
>
> Your intermediate CAs also have the same OCSP responder URI. Are code
> signing certificates issued also by the "certSIGN Enterprise CA Class 3"
> issuer? Could you possibly provide a certificate which was issued
> sometime from the last month or so?

Answer: Yes, code signing certs are issued by the CA you mentioned.
For such a cert please follow: http://www.certsign.ro/cab/csfenroll.cab

>
> > According to this, any external subordinate CA has to comply with the
> > same requirements described in the CP and CPS, as certSIGN.
> > Obviously, if we were to a sign a contract for an external CA under
> > certSIGN Non-Repudiation CA Class 4 CA  we would impose the Web Trust
> > audit as a mandatory condition .
>
> This requirement is very import, please include it in your CP/CPS. Why
> are other external intermediate CAs not subject to the same requirement?
>

Answer:

According to the Certificate Policy or to Table 1.1/ page 12 from CPS
the only issuer of certs for other CAs is certSIGN Non-Repudiation CA
Class 4 CA . We agree with your remark and we'll discuss it asap in
the Policies and Procedures Committee.

>
Thanks for your answers so far.
>
> --
> Regards
>
> Signer:  Eddy Nigg, StartCom Ltd.

> XMPP:    start...@startcom.org

> Blog:    http://blog.startcom.org/
> Twitter:http://twitter.com/eddy_nigg

Hi all!

Please see above.

Regards,

Cristian

[Eddy Nigg]

On 10/28/2009 01:48 PM, cristian garabet:

> According to the Certificate Policy or to Table 1.1/ page 12 from CPS
> the only issuer of certs for other CAs is certSIGN Non-Repudiation CA
> Class 4 CA . We agree with your remark and we'll discuss it asap in
> the Policies and Procedures Committee.
>
>

Thanks a lot!

The only other item I'd like to have confirmed is regarding the OCSP
responder.

Nelson:

Could you please quickly check that the OCSP responder is in working
order and compliant? Thanks.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.

XMPP: star...@startcom.org

[Kathleen Wilson]

Thanks Eddy!

Does anyone else have an opinion about this request?
Shall I proceed with making the recommendation for approval after
hearing from Nelson in regards to the OCSP responder?

Kathleen

[Ian G]

I skimmed the audit report. No issues occurred to me. (I thought it
was a bit flat, almost a straight copy out of the examples, but that
can't be seen as a criticism.)

iang

[Nelson Bolyard]

On 2009-10-28 05:23 PDT, Eddy Nigg wrote:
> On 10/28/2009 01:48 PM, cristian garabet:
>> According to the Certificate Policy or to Table 1.1/ page 12 from CPS
>> the only issuer of certs for other CAs is certSIGN Non-Repudiation CA
>> Class 4 CA . We agree with your remark and we'll discuss it asap in
>> the Policies and Procedures Committee.
>
> Thanks a lot!
>
> The only other item I'd like to have confirmed is regarding the OCSP
> responder.
>
> Nelson:
>
> Could you please quickly check that the OCSP responder is in working
> order and compliant? Thanks.

I thank Kathleen for bringing this request to my attention today.
I don't read this list daily any more.

Yes, I tested the URLs given in
news://news.mozilla.org:119/d5debfe3-3192-4aa2...@37g2000yqm.googlegroups.com
and OCSP worked for them. Anyone can do that.
Kathleen had already done it, in fact.

[Kathleen Wilson]

Thank you, Eddy and Iang, for reviewing this request and providing
your comments and feedback. Also, thank you, Nelson, for double-
checking the OCSP responder. Your contributions are greatly
appreciated.

This discussion was in regards to the request from certSIGN to add the
“certSIGN ROOT CA” root certificate and enable the Websites, Email,

and Code Signing trust bits.

There is one action item resulting from this discussion in regards to
certSIGN updating their CPS to provide further information about a Web
Trust audit being mandatory for an external CA under the certSIGN Non-
Repudiation CA Class 4 CA. I do not plan to track this action item.

There are no other action items resulting from this discussion.

I will post a summary of the request and my recommendation for
approval in the bug:

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

I am now closing this discussion. Any further follow-up on this
request should be added directly to the bug.

Thanks,
Kathleen

[cristian garabet]

Dear all,

Thank you very much for your contribution to our objective of become
part of the Mozilla world! A special remark for Eddy that pointed out
the obvious necessary prerequisite for external sub CAs overlooked by
us. I am glad to inform you all that our policies committee held a
meeting last week and approved the new cps with the prerequisite
included ( you can check this out here
http://www.certsign.ro/certsign_en/files/certSIGN_CPS_v1.5_en.pdf at
page 16).

Regards,

Cristian

[Eddy Nigg]

On 11/04/2009 12:04 PM, cristian garabet:

> Thank you very much for your contribution to our objective of become
> part of the Mozilla world! A special remark for Eddy that pointed out
> the obvious necessary prerequisite for external sub CAs overlooked by
> us. I am glad to inform you all that our policies committee held a
> meeting last week and approved the new cps with the prerequisite
> included ( you can check this out here
> http://www.certsign.ro/certsign_en/files/certSIGN_CPS_v1.5_en.pdf at
> page 16).
>

I'm glad to know that it was perceived as helpful! Cheers!