470756 - add certsign's root ca cert

Status: RESOLVED FIXED

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

Description

[Cristian Garabet]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 

1. root certificate data: the certificate can be downloaded from
https://www.certsign.ro/certificate_digitale/lantul_de_incredere_en.htm
2. the root CA does not contain any EKU and it is used only to sign certificates for other 4 sub_CAs according to the CP and CPS and CRLS for those certificates
3. we have passed a WebTrust for CA audit performed by E&Y

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Cristian Garabet]

Certificate Practice Statements and Certificate Policy - https://www.certsign.ro/certsign_en/
see bottom of each page

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

normalizing subject

Comment 4

[Frank Wein [:mcsmurf]]

off the UNCO radar

Comment 5

[Kathleen Wilson]

Accepting this bug so we can begin the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.

Comment 6

[Kathleen Wilson]

Attachment: base64 of certSIGN ROOT CA

Comment 7

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Cristian, thank you for the thorough information that you have sent to me in regards to this request.

Attached is the Initial Information Gathering Document which summarizes the information that has been gathered and verified.  The items in the document that are highlighted in yellow indicate the information that needs to be clarified or provided. I will also summarize below.

1) I get the error ffffe009 when I try to load the CRLs into Firefox. Please see 
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
If my calculation is correct, this error corresponds to error code -8183 which would be “Security library: improperly formatted DER-encoded message.”

2) In Firefox when I set the validation option to treat the certificate as invalid if OCSP fails, I can successfully go to 
https://www.certsign.ro/certificate_digitale/lantul_de_incredere_en.htm
However, I get the following error when trying to access other www.certsign.ro https sites like
https://www.certsign.ro/certsign_en/
The OCSP server experienced an internal error.
(Error code: sec_error_ocsp_server_error)

3) Please provide a link to the audit, or attach that audit to this bug.

4) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/, I need to find text in the CP/CPS that demonstrates that reasonable measures are taken to verify that the domain referenced in an SSL cert is owned/controlled by the subscriber. I can see where IV/OV verification and uniqueness of domain name requirement are in the CPS, but I could not find how the RA verifies that the domain name is owned/controlled by the subscriber.

5) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/, I need to find text in the CP/CPS that demonstrates that reasonable measures are taken to verify that the email account associated with the email address in the cert is owned by the subscriber. This is in addition to verification of subscriber’s identity.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Kathleen,
I have a few questions about the CRLs with error -8183:
a) which one(s) of the 5 CRLs gave this error?
b) with what version of the browser were you testing?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I'm guessing that the answer to my question in comment 8 will be: all of them.

It seems that the CRLs being downloaded from those URLs are all "PEM" 
encoded, and all begin with lines that read:

-----BEGIN X509 CRL-----

NSS does not recognize that PEM header, and I suspect that PSM does not,
either.  NSS expects that it will be given a binary DER CRL, not one that
is PEM or BASE64 encoded.  The questions here are: 
1) what do the standards say is the proper encoding for downloads of CRLs?  
   Do they allow PEM? or do they require binary DER?  Also, 
2) what MIME content type does the server indicate for these downloads?

IFF it turns out that the standards allow CRLs to be PEM encoded, then 
it will be PSM's job to detect that the CRL is PEM encoded and decode it
so that what it presents to NSS will be Binary DER.  But I suspect that 
the standard is to deliver CRLs as binary DER rather than as PEM.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

In answer to the questions in comment 9,
RFC 5280 says, in section 4.2.1.13 CRL Distribution Points, page 46,

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP URI scheme is used, the
   URI MUST point to a single DER encoded CRL as specified in
   [RFC2585].  HTTP server implementations accessed via the URI SHOULD
   specify the media type application/pkix-crl in the content-type
   header field of the response.  

The RFC says the CRL must be DER encoded, meaning binary, not PEM.  
This is an issue.

Comment 11

[Cristian Garabet]

Attachment: E&Y's WebTrust for CA audit report

Comment 12

[Cristian Garabet]

Hi All,

I'll answer here to the issues mentioned in comment #7 above:

1) I get the error ffffe009 when I try to load the CRLs into Firefox. Please
see 
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html
If my calculation is correct, this error corresponds to error code -8183 which
would be “Security library: improperly formatted DER-encoded message.”

Yes, we encoded PEM.We changed this to DER.

2) In Firefox when I set the validation option to treat the certificate as
invalid if OCSP fails, I can successfully go to 
https://www.certsign.ro/certificate_digitale/lantul_de_incredere_en.htm
However, I get the following error when trying to access other www.certsign.ro
https sites like
https://www.certsign.ro/certsign_en/
The OCSP server experienced an internal error.
(Error code: sec_error_ocsp_server_error)

We tried to reproduce the error but it didn't show up. We suspect a network problem. Please recheck on this one.

3) Please provide a link to the audit, or attach that audit to this bug.

Done

4) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/,
I need to find text in the CP/CPS that demonstrates that reasonable measures
are taken to verify that the domain referenced in an SSL cert is
owned/controlled by the subscriber. I can see where IV/OV verification and
uniqueness of domain name requirement are in the CPS, but I could not find how
the RA verifies that the domain name is owned/controlled by the subscriber.

In CPS  3.1.7	Authentication of Legal Entity’s Identity we state that :"
The authorized representatives of the institution regardless the certificate level they are requesting are bind to present upon the request of the Registration Authority the following documents:
	......
        -Template statement of the domain’s titular (in case of WEB certificates when the certificate solicitor is not the owner of the domain he wants to secure)....."  
Of course, in both cases, we inquire the whois on www.rotld.ro.


5) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/,
I need to find text in the CP/CPS that demonstrates that reasonable measures
are taken to verify that the email account associated with the email address in
the cert is owned by the subscriber. This is in addition to verification of
subscriber’s identity.

 There's an omission here on our part.

Comment 13

[Kathleen Wilson]

>> Yes, we encoded PEM. We changed this to DER.

The CRL for the root now works. Will you also be changing the CRLs for its subordinate CAs?

>> OCSP error

Now it’s working for me too.

>> Verification of domain name ownership/control
>> Of course, in both cases, we inquire the whois on www.rotld.ro.

Would it be possible to add a statement about inquiring the whois and rotld to the CP or CPS?

>> Verification of email address ownership/control
>>  There's an omission here on our part.

Would it be possible to add this to your CP or CPS?

Comment 14

[Cristian Garabet]

Response to Comment #13:

>> Yes, we encoded PEM. We changed this to DER.

>The CRL for the root now works. Will you also be changing the CRLs for its
subordinate CAs?

Yes, the change is made for all CAs.


>> Verification of domain name ownership/control
>> Of course, in both cases, we inquire the whois on www.rotld.ro.

>Would it be possible to add a statement about inquiring the whois and rotld to
the CP or CPS?

A new CPS version (1.3) has been approved and published.

See 3.1.7 Authentication of Legal Entity’s Identity, page 55 

>> Verification of email address ownership/control
>>  There's an omission here on our part.

>Would it be possible to add this to your CP or CPS?

A new CPS version (1.3) has been approved and published.

See 3.1.7 Authentication of Legal Entity’s Identity, page 55 & 3.1.8 Authentication of Natural Entity’s Identity, page 57

Comment 15

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 16

[Kathleen Wilson]

This completes the Information Gathering and Verification phase as per
https://wiki.mozilla.org/CA:How_to_apply

This request has been added to the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Comment 17

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the Information Gathering Document in preparation for the upcoming discussion.

Comment 18

[Kathleen Wilson]

I am now opening the first public discussion period for this request from certSIGN to add the “certSIGN ROOT CA” root certificate and enable the Websites, Email, and Code Signing trust bits.

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 [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 “certSIGN Root Inclusion Request”

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

Comment 19

[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 the request to add the “certSIGN ROOT CA” root certificate and enable the Websites, Email, and Code Signing trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by certSIGN, 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]. certSIGN appears to provide a service relevant to Mozilla users: It is a private corporation in Romania. certSIGN is a company member of UTI Group and an accredited supplier of certification services. 

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 provided in English.

http://www.certsign.ro/certsign_en/files/certSIGN_CP_EN_v1.0.pdf
http://www.certsign.ro/certsign_en/files/certSIGN_CPS_EN.pdf

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

* Email: According to section 3.1.7 of the CPS, the RA must verify that the email address to be included in the certificate is owned/controlled by the certificate subscriber. “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.”

* SSL:  According to section 3.1.7 of the CPS, the RA must verify that the domain name to be included in the certificate is owned/controlled by the certificate subscriber. “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.”

* Code: According to sections 3.1.7 and 3.1.8 of the CPS, Code Signing certificates are issued by the certSIGN Enterprise CA Class3 sub-CA, so they are always organizationally validated.

Section 8-10 [Audit]. certSIGN is audited annually against the WebTrust CA criteria by Ernst & Young. Their recent audit was attached to this 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.

Section 13 [Certificate Hierarchy]. 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 certSIGN Non-Repudiation CA Class 4 could issue certificates for CA servers that might be operated by a third party. As per the CPS, any external subordinate CA will have to comply with the same requirements described in the CP and CPS as certSIGN.  

Note: “certSIGN Demo CA Class 1” CA is a selfsigned authority; it is not signed by the certSIGN ROOT CA. 

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

Based on this assessment I intend to approve this request to add the “certSIGN ROOT CA” root certificate and enable the Websites, Email, and Code Signing trust bits.

Comment 20

[Kathleen Wilson]

To the representatives of certSIGN: 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 and recommendation in Comment #19, and on behalf of the Mozilla project I approve this request from certSIGN to include the following root certificate in Mozilla, with trust bits set as indicated:

* certSIGN ROOT CA (web sites, email, code signing)

I will file the NSS bug to effect the approved changes.

Comment 21

[Kathleen Wilson]

I have filed bug #526532 against NSS for the actual changes.

Comment 22

[Kathleen Wilson]

Confirmed that this root is a Builtin Object Token in Firefox 3.6.

Comment 23

[Kathleen Wilson]

Attachment: WebTrust CA Audit Statement 2009

Comment 24

[Cristian Garabet]

Attachment: E&Y's WebTrust for CA audit report 2010

Comment 25

[Kathleen Wilson]

Attachment: E&Y's WebTrust for CA audit report 2011

Comment 26

[Kathleen Wilson]

Attachment: E&Y's WebTrust for CA audit report 2012

Comment 27

[Kathleen Wilson]

Attachment: E&Y's WebTrust for CA and BR audit report 2013

Comment 28

[Kathleen Wilson]

Attachment: Publicly-disclosed intermediate certs

Comment 29

[Kathleen Wilson]

Attachment: AICPA - Webtrust Audit Opinion 2015 - CertSIGN.PDF