624356 - Add renewed Sertifitseerimiskeskus AS root certificate

Status: RESOLVED FIXED

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

Description

[Tarvi Martens]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Build Identifier: 

Hello,

AS Sertifitseerimiskeskus in Estonia has generated a new root certificate and would like to submit it for distribution.

The new root is called "EE Certification Centre Root CA" and is available from:
www.sk.ee/files/EECCRCA.PEM.cer (PEM) and www.sk.ee/files/EECCRCA.der (DER).

There has been no changes in CP/CPS so it should be seen as a technical addition.


The latest compliance audit is available from http://www.sk.ee/file.php?id=529

With best regards,

Tarvi Martens
Development Director
[phone]


Reproducible: Always

Comment 1

[Kathleen Wilson]

The previous Sertifitseerimiskeskus AS root certificate was approved for inclusion in bug #414520. It appears that most of the information from that bug will apply. Therefore, I will begin the Information Verification phase described here:
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 3

[Tarvi Martens]

* Impact to Mozilla users
Both end-user certificates and web server certificates are issued under this root certificate. Therefore Mozilla users browsing web or sending S/MIME messages shall be supported.

* Certificate Summary
The new root certificate has identical certificate hierarchy as old Juur-SK as per bug #414520.

* Test Website URL
TBD during February

* CRL URL
http://www.sk.ee/pages.php/0203040507 is a list of all CRL-s. The CRL of a new root is in http://www.sk.ee/crls/eeccrca/eeccrca.crl 

* CRLS OCSP
http://ocsp.sk.ee but the access is subject to contract.

* CA Hierarchy – The new root CA will have the same CA hierarchy as per bug #414520 i.e. 3 CA-s: KLASS3 2010 for issuing certificates for organizations (www server, code signing, digital stamping) and two CA-s for issuing certificates for physical persons: ESTEID for Estonian ID-card related services and EID for other personal qualified certificates.

* Externally Operated SubCA-s: N/A
* Cross-Signing: N/A

* Audits. By-law describing requirements is available from
http://www.tja.ee/public/documents/Elektrooniline_side/Oigusaktid/ENG/Procedure_for_Information_Systems_Audit_of_Service_Providers.mht
(sorry about the format)

* SSL Verification procedures
As per bug #414520.

* Organization verification procedures
As per bug #414520.

* Code Signing Subscriber Verification Procedure
Equivalent with SSL/Organization verification procedures

* Response to Mozilla's CA Recommended Practices
TBD

Comment 4

[Kathleen Wilson]

> * Audits. By-law describing requirements is available from
> http://www.tja.ee/public/documents/Elektrooniline_side/Oigusaktid/ENG/Procedure_for_Information_Systems_Audit_of_Service_Providers.mht
> (sorry about the format)

I don't know what this means. 

In the previous audit report (http://www.sk.ee/file.php?id=516) section 2.10 stated that compliance was checked in regards to ETSI TS 101 456. However, in http://www.sk.ee/file.php?id=529 I am not finding any mention of the audit criteria that are listed in the Mozilla CA Certificate Policy (ETSI 101 456, ETSI 102 042, or WebTrust CA).

> 
> * SSL Verification procedures
> As per bug #414520.
> 
> * Organization verification procedures
> As per bug #414520.
>

Your documents have changed, and our practices have changed. Please provide the specific information listed in #3 of 
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

 
> * Code Signing Subscriber Verification Procedure
> Equivalent with SSL/Organization verification procedures

That is insufficient. There must be some specific language in the CP/CPS about Code Signing certificates. 
#5 of 
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 5

[Tarvi Martens]

* On audits: 
The current audit report does not mention compliance to ETSI TS 101 456 (against part 6 and 7), because at the moment we are conducting separate broad audit about full compliance to ETSI TS 101 456; ETSI TS 102 042; ETSI TS 102 023. The audit will be completed at the latest 31.03.2011.

Estonian law does not require to conduct any ETSI audits or check the compliance to any ETSI standard requirements. In the previous audits, compliance with parts 6 and 7 of ETSI TS 101 456 and ETSI TS 102 023 were checked out of our own interest and results added to the report.

To solve this problem with Mozilla, we propose that we conduct compliance audit, as we had done in previous years, with the ETSI TS 101 456 (and ETSI TS TS 102 023) part 6 and 7, first and add those audit results to the public registry separately (separate audit report about additional compliance
check) as soon as possible. We can give the more specific time estimation after you assure that is convenient approach to Mozilla.

* On verification procedures - new CP is being translated. Will reply in nearest future

Comment 6

[Kathleen Wilson]

(In reply to comment #5)
> * On audits: 
> The current audit report does not mention compliance to ETSI TS 101 456
> (against part 6 and 7), because at the moment we are conducting separate broad
> audit about full compliance to ETSI TS 101 456; ETSI TS 102 042; ETSI TS 102
> 023. The audit will be completed at the latest 31.03.2011.

That's fine. 

> 
> Estonian law does not require to conduct any ETSI audits or check the
> compliance to any ETSI standard requirements. In the previous audits,
> compliance with parts 6 and 7 of ETSI TS 101 456 and ETSI TS 102 023 were
> checked out of our own interest and results added to the report.
> 
> To solve this problem with Mozilla, we propose that we conduct compliance
> audit, as we had done in previous years, with the ETSI TS 101 456 (and ETSI TS
> TS 102 023) part 6 and 7, first and add those audit results to the public
> registry separately (separate audit report about additional compliance
> check) as soon as possible. We can give the more specific time estimation 
> after you assure that is convenient approach to Mozilla.

Yes, that approach is fine.

> 
> * On verification procedures - new CP is being translated. Will reply in
> nearest future

Much appreciated.

Comment 7

[Tarvi Martens]

CP in English is now available at http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf

Client/SSL/Code signing verification procedures are addressed in p3.1, p3.3 and p4.2.1. Public registries are consulted in decision-making process, namely Central Commercial Register https://ariregister.rik.ee/index.py?lang=eng and Domain Registry http://www.eestiinternet.ee/eng for domain ownership.

Comment 8

[Kathleen Wilson]

From bug #414520: For SSL certs, Sertifitseerimiskeskus verifies the ownership of the domain name by using the whois service for international domains, and by using EENet (www.eenet.ee) for .ee domains. Sertifitseerimiskeskus contacts the domain's administrative contact before issuing a certificate.

If I could find this in the CP or CPS it would satisfy our requirement in regards to verification of the certificate subscriber's ownership/control of the domain name. However, I am not finding it. Please either update your CP/CPS to include this information, or show me where it is.

If you wish to turn on the Code Signing trust bit, please show me where in the CP/CPS there are specifics about code signing certs.

Please review and comment on the following in regards to relevance to your practices, and steps taken to mitigate risk.
Mozilla's CA Recommended Practices (https://wiki.mozilla.org/CA:Recommended_Practices) 
and
Mozilla's list of Potentially Problematic Practices (https://wiki.mozilla.org/CA:Problematic_Practices) 

Please provide a url to a website whose SSL cert chains up to this root.

Comment 9

[Tarvi Martens]

A website chaining up to the new root is now available at https://www.openxades.org/

Recent ETSI and other audits are available at http://www.sk.ee/en/repository/audit/

SK issues organizational certificates according to policy specified in http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf. SK does not currently issue organizational certificates to entities outside Estonia. This is the reason sources of information to verify Estonian legal entity was given in this thread but not in CP as we slightly look forward to expand our activity in other countries. CP states basic principles we would adhere according to specifics of relevant country.

From our position we do not differenciate certificate-issuance principles and policies with regard to code-signing certificates as we have common policy for issuing various (KU/EKU) certificates to organizational entities.

Comment 10

[Kathleen Wilson]

Thanks for the information.

When I try to import the CRL, http://www.sk.ee/crls/klass3/klass3-2010.crl, I get the following error:
Error Importing CRL to local Database. Error Code:ffffe095
Please see: https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension


Please review Mozilla's CA Recommended Practices (https://wiki.mozilla.org/CA:Recommended_Practices). If your practices differ from any of these recommended practices, then describe those differences and explain how the concern(s) are addressed.


Please review Mozilla's list of Potentially Problematic Practices (https://wiki.mozilla.org/CA:Problematic_Practices). Indicate which of these apply to your practices, and describe how the risk and concerns are mitigated.

Comment 11

[Tarvi Martens]

Critical flag has now been removed from CIDP extension. The new CRL is
located in the same place  http://www.sk.ee/crls/klass3/klass3-2010.crl

Do we have any other open issues?

Comment 12

[Kathleen Wilson]

I have imported the CRL without error into my Firefox browser.

I have received the following via email from the auditor at KPMG:
I confirm that the audit report 
http://www.sk.ee/upload/files/SK%20STO%20ETSI%20audit%202011%20ENG.pdf 
is issued by KPMG Baltics OÜ and is the same as the original report.

Comment 13

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 14

[Kathleen Wilson]

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

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 15

[Kathleen Wilson]

Do you have an audit statement for this year?

Comment 16

[Tarvi Martens]

Audtis for SK are performed in falls. The latest from 2011 is available at http://www.sk.ee/en/repository/audit/

Comment 17

[Kathleen Wilson]

I see that the audit statement for November 2011 has been posted there. I will exchange email with a representative of KPMG to confirm the authenticity of this latest statement.

Comment 18

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Sertifitseerimiskeskus to add the “EE Certification Centre Root CA” root certificate that will eventually replace the “Juur-SK” root certificate that is currently included in NSS.

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 “SK Root Inclusion Request for Renewed Root”

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

A representative of Sertifitseerimiskeskus must promptly respond directly in the discussion thread to all questions that are posted.

Comment 19

[Kathleen Wilson]

The public comment period for this request is now over. 

This request has been evaluated as per Mozilla’s 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 to add the “EE Certification Centre Root CA” root certificate that will eventually replace the “Juur-SK” root certificate that is currently included in NSS. The request is to turn on the Websites and Code Signing trust bits. EV treatment is not requested at this time.

Section 4 [Technical]. I am not aware of instances where SK (Certification Centre, legal name AS Sertifitseerimiskeskus) has 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]. SK appears to provide a service relevant to Mozilla users; it is a commercial CA, covering the Baltic region (Estonia, Lithuania, Latvia). Established in 2001, SK has the backing of Estonian and Nordic financial and telecom sector. SK’s customers include the Estonian court system and notaries, Central Bank and commercial banks, and enforcement organisations.

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.

Document Repository: http://www.sk.ee/en/repository
CPS: http://www.sk.ee/upload/files/SK_CPS_en_v2_5.pdf
CP of Organisation Certs: http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf

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

* Email: Not applicable, not requesting the email trust bit.

* SSL: As per section 4.2.1 of the CP, SK checks the identity and authority of the certificate subscriber, and “In the case of applications for web server certificates, the link between the Client and the domain name and/or IP address of the Client’s appliance is verified if the appliance is accessible through a public computer network.” Public registries are consulted in the decision-making process, namely Central Commercial Register https://ariregister.rik.ee/index.py?lang=eng and Domain Registry http://www.eestiinternet.ee/eng for domain ownership.

* Code:  As per section 3.1 and 4.2.1 of the CP, object signing certificates are issued to organizations for which SK has verified the organization’s identity, the identity of the organization's representative and his or her authorization to request the certificate.

Section 15 [Certificate Hierarchy]. 
This root will have 3 internally-operated subCAs. The “KLASS3-SK 2010” subCA signs certificates for organizations (www server, code signing, digital stamping). The other two subCAs sign certificates for physical persons: ESTEID for Estonian ID-card related services and EID for other personal qualified certificates.

* Both CRL and OCSP are provided 
http://www.sk.ee/crls   
http://www.sk.ee/crls/eeccrca/eeccrca.crl
http://www.sk.ee/crls/klass3/klass3-2010.crl
CP section 2.4.2: The revocation list is updated every 12 hours.
http://ocsp.sk.ee  (Access is subject to contract.)

Sections 9-11 [Audit]. Annual audits are performed by KPMG according to the ETSI TS 101 456 criteria. The audit reports are posted on SK’s website, so I exchanged email with a representative of KPMG to confirm the authenticity of the audit report.
http://www.sk.ee/en/repository/audit

Based on this assessment I intend to approve this request to add the “EE Certification Centre Root CA” root certificate and turn on the Websites and Code Signing trust bits.  

Note: During the discussion SK stated: “SK has successfully tested a new version of CA software producing random number in the SerialNo field. … we have internal readiness to start operating from new root and commit NOT to issue any certificate from new CA with sequential SerialNo.”

Comment 20

[Kathleen Wilson]

To the representatives of Sertifitseerimiskeskus: 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 #19, and on behalf of Mozilla I approve this request from Sertifitseerimiskeskus to include the following root certificate in Mozilla products:

** "EE Certification Centre Root CA" (websites, code signing)

I will file the NSS bug to include the new root cert.

Comment 21

[Kathleen Wilson]

I have filed bug #795020 against NSS to include the new root cert.

Comment 22

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #19)
> 
> Note: During the discussion SK stated: “SK has successfully tested a new
> version of CA software producing random number in the SerialNo field. … we
> have internal readiness to start operating from new root and commit NOT to
> issue any certificate from new CA with sequential SerialNo.”

I received email from SK in January stating: "our CA is renewed now and in production providing certificates with random number in SerialNo"