Closed
Bug 470756
Opened 16 years ago
Closed 15 years ago
add certsign's root ca cert
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: cristian.garabet, Assigned: kathleen.a.wilson)
References
()
Details
Attachments
(11 files, 1 obsolete file)
1.17 KB,
application/x-x509-ca-cert
|
Details | |
142.16 KB,
application/pdf
|
Details | |
695.76 KB,
application/pdf
|
Details | |
27.62 KB,
application/pdf
|
Details | |
312.01 KB,
application/pdf
|
Details | |
242.89 KB,
application/pdf
|
Details | |
648.88 KB,
application/pdf
|
Details | |
339.76 KB,
application/pdf
|
Details | |
327.10 KB,
application/pdf
|
Details | |
13.74 KB,
application/zip
|
Details | |
371.60 KB,
application/pdf
|
Details |
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.
Reporter | ||
Comment 1•16 years ago
|
||
Certificate Practice Statements and Certificate Policy - https://www.certsign.ro/certsign_en/ see bottom of each page
Comment 3•16 years ago
|
||
normalizing subject
Summary: Request to add certsign's root ca to the default set of CAs distributed with Mozilla Foundation and Mozilla Corporation software applications → add certsign's root ca cert
Assignee | ||
Comment 5•16 years ago
|
||
Accepting this bug so we can begin the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
Assignee | ||
Comment 6•16 years ago
|
||
Updated•16 years ago
|
Severity: normal → enhancement
Assignee | ||
Comment 7•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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•16 years ago
|
||
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.
Reporter | ||
Comment 11•16 years ago
|
||
Reporter | ||
Comment 12•16 years ago
|
||
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.
Assignee | ||
Comment 13•16 years ago
|
||
>> 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?
Reporter | ||
Comment 14•16 years ago
|
||
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
Assignee | ||
Comment 15•15 years ago
|
||
Assignee | ||
Comment 16•15 years ago
|
||
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
Whiteboard: Information confirmed complete
Assignee | ||
Comment 17•15 years ago
|
||
Updated the Information Gathering Document in preparation for the upcoming discussion.
Attachment #364337 -
Attachment is obsolete: true
Assignee | ||
Comment 18•15 years ago
|
||
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 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 “certSIGN Root Inclusion Request” Please actively review, respond, and contribute to the discussion.
Whiteboard: Information confirmed complete → In public discussion
Assignee | ||
Comment 19•15 years ago
|
||
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.
Assignee | ||
Comment 20•15 years ago
|
||
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.
Whiteboard: In public discussion → Approved - awaiting NSS
Assignee | ||
Comment 21•15 years ago
|
||
I have filed bug #526532 against NSS for the actual changes.
Assignee | ||
Comment 22•15 years ago
|
||
Confirmed that this root is a Builtin Object Token in Firefox 3.6.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS
Assignee | ||
Comment 23•14 years ago
|
||
Reporter | ||
Comment 24•13 years ago
|
||
Assignee | ||
Comment 25•12 years ago
|
||
Assignee | ||
Comment 26•11 years ago
|
||
Assignee | ||
Comment 27•10 years ago
|
||
Assignee | ||
Comment 28•10 years ago
|
||
Assignee | ||
Comment 29•9 years ago
|
||
Updated•7 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
•