Closed Bug 532377 Opened 15 years ago Closed 13 years ago

Add CERTUM's new Root CA to Mozilla's trusted root list

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mproszkiewicz, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: EV - Included in FF6.0, EV treatment in FF 6.0)

Attachments

(4 files)

Initial Information Gathering Document
30.60 KB, application/pdf
Details
Additional information required to add CERTUMs new root to NSS trusted root list
359.55 KB, application/x-download
Details
Updated Information Gathering Document
104.46 KB, application/pdf
Details
Completed Information Gathering Document
150.43 KB, application/pdf
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 

CERTUM would like to add new root to the NSS store

The root is primarily suitable for Server and Client Authentication, e-mail, Code Signing and Timestamping, however the root itself is marked for
all issuance policies and therefore can also be used for OCSP, Encrypting File
System, IP Sec (Tunnel, User) etc.

CPS and CP are located at:
http://www.certum.pl/repository

Key extensions 
•    basicConstraints: CA: true
•    keyUsage: keyCertSign, cRLSign

Certificate File Information
CERTUM Trusted Network CA
Signature Algorithm: sha1WithRSAEncryption
Validity
	Not Before: Oct 22 12:07:37 2008 GMT
	Not After : Dec 31 12:07:37 2029 GMT
Subject:
	C=PL
	O=Unizeto Technologies S.A.
	OU=Certum Certification Authority
	CN=Certum Trusted Network CA
Serial Number: 279744 (0x444c0)

X509v3 extensions:
	X509v3 Basic Constraints: critical
		CA:TRUE
	X509v3 Subject Key Identifier:
		08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7
	X509v3 Key Usage: critical
		Certificate Sign, CRL Sign
Fingerprints
SHA1 = 07:E0:32:E0:20:B7:2C:3F:19:2F:06:28:A2:59:3A:19:A7:0F:06:9E
MD5  = D5:E9:81:40:C5:18:69:FC:46:2C:89:75:62:0F:AA:78

URI to online CRL repository
http://crl.certum.pl/ctnca.crl

URI to online location of the root
http://repository.certum.pl/CTNCA.crt

Latest WebTrust Audit:
https://cert.webtrust.org/ViewSeal?id=965


Reproducible: Always




We are under process of acquiring WebTrust for EV audit so in few weeks (maybe months) we will be requesting to mark this certificate for EV.
Summary: Add CERTUMS's new Root CA to Mozilla's trusted root list → Add CERTUM's new Root CA to Mozilla's trusted root list
Starting the Information Gathering and Verification phase as per:
https://wiki.mozilla.org/CA:How_to_apply
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Information incomplete
The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
(In reply to comment #2)
> 
> The items highlighted in yellow indicate where further information or
> clarification is needed. Please review the full document for accuracy and
> completeness.

I'm still gathering information. I'll attach proper document tomorow.
Answers and additional comments marked in green.
Thank you for the information.  

> OCSP service of current root in NSS not working

In regards to the OCSP service for the “Certum CA” root that is currently included in NSS…
Bug # 378673 was closed in 2007 as won’t fix, so that means that your OCSP service, as-is, would not ever work in Firefox. That also means that your end-users who use Firefox have not been getting revocation checking done on website certs for websites that they go to. I would think this is problematic.

Why hasn’t your OCSP responder been updated to work with what Firefox supports?

I need to understand this before moving your request for the new root inclusion into the queue for public discussion.

> Test website for new root

Before starting the public discussion for this new root, we will need a test website whose EV SSL cert chains up to this root.  It’ll take a few months in the queue, so there is time.

> Verification of email address ownership/control

Based on previous root inclusion requests, I expect that it will be problematic that there is insufficient information about verification of email address ownership control in the CP/CPS. Having this information in an internal document does not help. Can the CP or CPS be updated to provide further information? It doesn't need to provide all the details, but needs to show that sufficient verification is performed.
(In reply to comment #5)
> Thank you for the information.  
> 
> > OCSP service of current root in NSS not working
> 
> In regards to the OCSP service for the “Certum CA” root that is currently
> included in NSS…
> Bug # 378673 was closed in 2007 as won’t fix, so that means that your OCSP
> service, as-is, would not ever work in Firefox. That also means that your
> end-users who use Firefox have not been getting revocation checking done on
> website certs for websites that they go to. I would think this is problematic.
> 
> Why hasn’t your OCSP responder been updated to work with what Firefox supports?
> 
> I need to understand this before moving your request for the new root inclusion
> into the queue for public discussion.
> 

According to the IETF RFC 2560, §2.2 Response, Certum Validation Service works as Trusted Responder whose public key is trusted by the requester. Said trust is directly inherited from Certum CA. I have been told that Firefox supports that mode, but one need to set it manually. Authorized Responder mode is planning for the Extended Validation certificates. 

> > Test website for new root
> 
> Before starting the public discussion for this new root, we will need a test
> website whose EV SSL cert chains up to this root.  It’ll take a few months in
> the queue, so there is time.
> 

Test website will be  up at the end of the week, i will post address ASAP.


> > Verification of email address ownership/control
> 
> Based on previous root inclusion requests, I expect that it will be problematic
> that there is insufficient information about verification of email address
> ownership control in the CP/CPS. Having this information in an internal
> document does not help. Can the CP or CPS be updated to provide further
> information? It doesn't need to provide all the details, but needs to show that
> sufficient verification is performed.

I will look into it and see if changes to CP or CPS are possible.
Web site for new root:
https://juice.certum.pl/

> Verification of email address ownership/control

Verification of email address is achieved by sending via email a message that contain unique web address necessary to get the certificate. Only by entering this address certificate is released.
>> Verification of email address ownership/control
> Verification of email address is achieved by sending via email a 
> message that contain unique web address necessary to get the certificate. 
> Only by entering this address certificate is released.

I think that's sufficient. Please point me to where it is documented in the CP or CPS.

>> OCSP service of current root in NSS not working

I've asked for help on this item, because I don't understand the part about Firefox supporting a Trusted Responder mode.

>> Test website for new root

Is it ready?
>> Test website for new root

https://juice.certum.pl/

This site is working for me -- I'm on a new computer, so needed to re-install the new root.
In regards to the OCSP service for the currently included root, I may have to file a separate bug to track the issue. However, before doing so I would like to understand the extent of the issue. Is the OCSP URL included in all SSL certs that are issued from the old root? Or is it a small percentage of certs that actually have the OCSP URL? If yes, approximately what percent? How is it communicated to those relying parties that they need to configure Firefox to use a trusted OCSP responder?
(In reply to comment #8)
> >> Verification of email address ownership/control
> > Verification of email address is achieved by sending via email a 
> > message that contain unique web address necessary to get the certificate. 
> > Only by entering this address certificate is released.
> 
> I think that's sufficient. Please point me to where it is documented in the CP
> or CPS.
> 
It will be added in next iteration of CPS and CP changes and will be published in next few months

(In reply to comment #10)
> In regards to the OCSP service for the currently included root, I may have to
> file a separate bug to track the issue. However, before doing so I would like
> to understand the extent of the issue. Is the OCSP URL included in all SSL
> certs that are issued from the old root? Or is it a small percentage of certs
> that actually have the OCSP URL? If yes, approximately what percent? How is it
> communicated to those relying parties that they need to configure Firefox to
> use a trusted OCSP responder?

OCSP URL (http://ocsp.certum.pl) is included in all SSL certificates.
I have filed bug #540906 to track the issues with the OCSP service of the Certum root that is currently included in NSS.
Depends on: 540906
This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion  https://wiki.mozilla.org/CA:How_to_apply#Public_discussion


Please post an update to this bug when the CP/CPS have been updated as per:
>>> Verification of email address is achieved by sending via email a  
>>> message that contain unique web address necessary to get the.  
>>> certificate. Only by entering this address certificate is released. 
>> I think that's sufficient. Please point me to where it is documented
>> in the CP or CPS. 
> It will be added in next iteration of CPS and CP changes and 
> will be published in next few months 
This will need to be completed before the actual public discussion can start.
https://wiki.mozilla.org/CA:How_to_apply#Timeline
Has your CP/CPS been updated as per Comment #13?  If yes, please post the links to the new document(s) in this bug.
(In reply to comment #14)
> Has your CP/CPS been updated as per Comment #13?  If yes, please post the links
> to the new document(s) in this bug.

Yes it's been updated (chapter 3.2.2).
Thanks.

Do you have a new WebTrust CA audit report?
(In reply to comment #16)
> Thanks.
> 
> Do you have a new WebTrust CA audit report?

Yes, new audit report is available here:
https://cert.webtrust.org/SealFile?seal=1072&file=pdf
Thanks.

From the EV CPS: Since January 2010 Certum Extended Validation CA will provide revocation information via an Online Certificate Status Protocol (OCSP) service 

Can you update the EV SSL cert in the test website (https://juice.certum.pl/) to have the appropriate AIA OCSP URI?
It was a typo and was corrected in EV CPS version 3.1 to "January 2011"

According to EV Guidelines OCSP service should be provided for certificates since January 2011 (Chapter 25 (1)(B))

At the moment we cannot issue certificate with AIA OCSP URI.
I am now opening the first public discussion period for this request from Certum to add the “Certum Trusted Network CA” root certificate and enable all three trust bits. The request is to also enable EV. 

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

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

A representative of Certum must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information incomplete → EV - In Public Discussion
The public discussion for this request is now closed. 

This request from Certum is to to add the “Certum Trusted Network CA” root certificate, enable all three trust bits, and enable EV. 

The discussion resulted in the following two action items.

1) ACTION Certum: Remove ssladmin@yourdomain.com and root@yourdomain.com from the list of addresses that may be used for SSL certificate verification.

2) ACTION Certum: Provide OCSP service and test with Firefox browser. There are two levels to this action item. First, there is the OCSP responder for end-entity certs which may be tested as described here:
https://wiki.mozilla.org/CA:Recommended_Practices#OCSP.
Second, since this request is for EV, further testing will need to be done as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Please post updates into this bug as these action items are completed. Include links to the updated documentation and the test website.

After I have confirmed that the action items have been satisfactorily
completed, I plan to recommend approval of this request.
Whiteboard: EV - In Public Discussion → EV - Public Discussion Action Items
Both actions have been done:

1) ssladmin@yourdomain.com and root@yourdomain.com have been removed from list of allowed addresses

2) OCSP service for EV certificates is operational (you can check https://juice.certum.pl)
I am able to browse to the test website within my Firefox browser with OCSP enforced. I confirm that the SSL cert of the test website has the following in the AIA extension: OCSP: URI: http://evca.ocsp.certum.pl

It is my opinion that Certum has completed the action items that resulted from the discussion. Therefore, I will recommend approval of this request.
This request has been evaluated as per the Mozilla 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 from Certum to add the “Certum Trusted Network CA” root certificate and enable all three trust bits. The request is to also enable EV. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Certum, 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]. Certum appears to provide a service relevant to Mozilla users: It is an organizational unit of Unizeto Technologies SA, providing certification services related to electronic signatures. It is the oldest public certification authority in Poland and a commercial certification authority, operating on a global scale - serving customers in over 50 countries 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, CPS, and EV CPS, which are in English. 

CP: http://www.certum.eu/upload_module/downloads/certum/dokumenty/polityka_certyfikacji/Certum_CP_v3_1.pdf

CPS: http://www.certum.eu/upload_module/downloads/certum/dokumenty/kodeks_postepowania_certyfikacyjnego/Certum_CPS_v3_1.pdf

EV CPS: http://www.certum.eu/upload_module/downloads/certum/dokumenty/kodeks_postepowania_certyfikacyjnego/Certum_CPS_v3_1_EV.pdf

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

* Email: According to CPS section 3.2.2 the RA verifies the email address to be included in the certificate via an email challenge-response mechanism.

* SSL: According to CPS section 3.2.2 the RA verifies that the certificate subscriber owns/controls the domain to be included in the certificate by one or more of the following three methods. According to CPS section 4.2.2.3 Certificate issuance denial will occur if the subscriber cannot prove his/her rights to proposed DN.
1) The subscriber places a verification element indicated by Certum on the destination sever. 
2) The subscriber responds to an email sent by Certum to one of the addresses admin@yourdomain.com, administrator@yourdomain.com, webmaster@yourdomain.com, hostmaster@yourdomain.com, postmaster@yourdomain.com. 
3) The RA cross-checks the given information with the registration of the domain in publicly available WHOIS services.

* Code: According to CPS section 3.2.2 the RA verifies the identity of the subscriber or certificate administrator, the existence of the legal entity or institution, and the right of the subscriber or the certificate administrator to act on behalf of the institution or legal entity.

* EV Policy OID: 1.2.616.1.113527.2.5.1.1

Section 13 [Certificate Hierarchy]
* Certum currently has a root named “Certum CA” included in NSS. Eventually, the certificates under the old “Certum CA” root will be moved to this new root. (starting with SSL certs).
* Currently this new root has two sub-CAs:
** Certum Level I CA -- Signs certs for testing. DV only. Domain ownership verified via email exchange.
** Certum Extended Validation CA – Signs EV SSL certs 
* Eventually the new root will also have the following sub-CAs:
** Certum Level II CA -- Signs certs for S/MIME, not for SSL or code signing.
** Certum Level III CA -- Signs certs for SSL , code signing, and S/MIME 
** Certum Level IV CA – Signs certs for certification authorities, non-repudiation authorities and global network-based electronic transaction systems. 
** Certum Partners CA. Signs certs for external CAs. 
*** Comment from Certum: We do plan to use this root for subordinate CAs that are operated by external third parties, special intermediate certificate will be created and proper changes to CPS will be done when needed.


Other: 

* EV SSL CRL: http://crl.certum.pl/evca.crl (Next Update: 9 days)
**EV CPS: CRLs are updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days;  (end-entity certs)

* EV OCSP URI: http://evca.ocsp.certum.pl
** EV CPS: … and update that service at least every four days. OCSP responses from this service will have a maximum expiration time of ten days. (end-entity certs)

Section 8-10 [Audit]. 
Ernst & Young performs the audits according to the WebTrust CA and WebTrust EV criteria, and the audit reports are posted on the webtrust.org website at 
https://cert.webtrust.org/SealFile?seal=1072
https://cert.webtrust.org/ViewSeal?id=999

Based on this assessment I intend to approve this request from Certum to add the “Certum Trusted Network CA” root certificate, turn on all three trust bits, and also enable EV.
Whiteboard: EV - Public Discussion Action Items → EV - Pending Approval
To the representatives of Certum: 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 #25, and on behalf of the Mozilla project I
approve this request from Certum to include the following root certificate in Mozilla:

** Certum Trusted Network CA (websites, email, code signing), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM
Depends on: 635385
Depends on: 635390
I have filed bug 635385 against NSS and bug 635390 against PSM for the actual changes.
New audit report for EV:
https://cert.webtrust.org/ViewSeal?id=1140
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - awaiting NSS and PSM → EV - Included in FF6.0, EV treatment in FF 6.0
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: