User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727) Build Identifier: All CA Details ---------- CA Name: Sertifitseerimiskeskus AS Website: http://www.sk.ee One Paragraph Summary of CA, including the following: Commercial CA, covering Baltic region ( Estonia, Lithuania, Latvia ) No subordinate CA-s Audit Type (WebTrust, ETSI etc.): ETSI Auditor: KPMG Estonia Auditor Website: http://www.kpmg.ee/ Audit Document URL(s): http://www.sk.ee/file.php?id=430 URL of certificate hierarchy diagram: http://www.sk.ee/files/tree.pdf Certificate Details ------------------- (To be completed once for each certificate; note that we only include root certificates in the store, not intermediates.) Certificate Name: Juur-SK Issuing intermediate certificates for Estonian ID-cards, WPKI solutions and Web server certificates. Certificate HTTP URL (on CA website): http://www.sk.ee/files/JUUR-SK.der Version: V3 SHA1 Fingerprint: 409D 4BD9 17B5 5C27 B69B 64CB 9822 440D CD09 B889 Modulus Length (a.k.a. "key length"): 2048 bit RSA Valid From (YYYY-MM-DD): 2001-08-30 Valid To (YYYY-MM-DD): 2016-08-26 CRL HTTP URL: http://www.sk.ee/crls/juur/crl.crl CRL issuing frequency for end-entity certificates: 12h OCSP URL: http://ocsp.sk.ee Class (domain-validated, identity/organisationally-validated or EV): Certificate Policy URL: CPS URL: http://www.sk.ee/file.php?id=432 Requested Trust Indicators (email and/or SSL and/or code): all policies URL of website using certificate chained to this root (if applying for SSL): https://digidoccheck.sk.ee Reproducible: Always Steps to Reproduce: 1. 2. 3.
Class (domain-validated, identity/organisationally-validated or EV): Certificate Policy URL: you left those two fields blank, which seems odd.
Summary: Certificate request → Add Sertifitseerimiskeskus AS root CA certificate
Hi, Sorry for the Class field, it should read: Class (domain-validated, identity/organisationally-validated or EV): identity/organisationally-validated As for the CP URL - this certificate is root certificate, that issues only intermediate certificates that have different CP-s as seen on http://www.sk.ee/files/tree.pdf. I am not sure if we have CP of Juur-SK available at the web.
Severity: normal → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Just confirm: The company name is "Sertifitseerimiskeskus AS", the root CA certificate name is "Juur-SK". The comment says "No subordinate CA-s", but clearly there are in fact three subordinate CAs under the Juur-SK root. Note that we will need the CPS/CP documents for the subordinate CAs in order to verify that issuance of end-entity certificates is in accordance with our policy. Also, the Sertifitseerimiskeskus CPS refers to a Personal Identification Act for Estonia; can you provide me an English version of that?
Hi, I clearly misenderstood questioning of subordinate CA-s in company section. As there is only 1 company, Sertifitseerimiskeskus AS, that has 1 root certificate and intermediates i thought we have 1 CA with different roles through intermediate certificates. As of Personal Identification Act for Estonia - it can be found at address http://www.legaltext.ee/text/en/X30081K4.htm With the CP-s of our intermediate certificates it is a bit harder. We do not have english translation of KLASS3-SK CP available at the moment. It has not been translated, but we well try to fix it ASAP. Meanwhile you can read CP-s of EID-SK (200) and ESTEID-SK (2007) at address http://www.sk.ee/pages.php/0203040504
Hi, Added KLASS3-SK CP, available at http://www.sk.ee/files/Seadmesert_CP_en-1.00.pdf
Hi, Is there any information that i can provide to help solving this bug ? With the Mozilla-s market share growth we are starting to loose clients to those CA-s that are trusted by Mozilla and this is really starting to affect our business. If there is anything (and i mean ANYTHING) i can do to solve this situation or speed up the process, please let me know ASAP. With best regards, Lembitu Ling Senior system administrator Sertifitseerimiskeskus AS
Accepting this bug so I can proceed with the information gathering/verification phase.
Assignee: hecker → kathleen95014
Attached is the initial information gathering document which summarizes the information that has been collected and verified. Within the document the items highlighted in yellow indicate the information that is still needed or where clarification or action is still needed. I will summarize below: 1) In Firefox four of the CRLs result in error: “The application cannot import the Certificate Revocation List (CRL). Error Importing CRL to local Database. Error Code:ffffe095 Please ask your system administrator for assistance. They are http://www.sk.ee/crls/juur/crl.crl http://www.sk.ee/crls/esteid/esteid.crl http://www.sk.ee/crls/esteid/esteid2007.crl http://www.sk.ee/crls/eid/eid2007.crl Do you happen to have the CDP (CRL distribution point) extension flagged as "critical" for these CRLs? Mozilla browsers do not presently implement the CrlDP extension because it is patented. So, Mozilla browsers do not presently honor CRLs with critical CrlDP extensions. 2) Please confirm or correct: All of the subordinate CAs are internally operated by Sertifitseerimiskeskus AS. The Ministry of Internal Affairs of Republic of Estonia is the registration authority for ESTEID-SK certificates, but the ESTEID-SK CA is operated internally by Sertifitseerimiskeskus AS. 3) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ please point me to the documentation that satisfies the following requirements: a) SSL domain verification – I found this in KLASS3-SK CP section 3.1. b) for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; 4)Would you please review the problematic practices as described in http://wiki.mozilla.org/CA:Problematic_Practices and comment as to whether any of these are relevant? If relevant, please provide further info. 5) For informational purposes only: I need to do an independent verification of the audit report. I will be contacting the auditor separately. 6) Your current audit was completed in October of last year, so it’s still valid. For the sake of completeness, do you happen to have audit scheduled for this year? Thanks, Kathleen
1) As of CDP status, it is set as critical. Looking at RFC 3280: 5.2.5 Issuing Distribution Point The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. I can see from this that CDP should be marked as critical, but software can ignore it at will. In Mozilla case it seems that you produce a crash instead. How do you comment on this ? Can you please give me some information about this patent ? 2) Confirmed. 3) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ please point me to the documentation that satisfies the following requirements: a) SSL domain verification – I found this in KLASS3-SK CP section 3.1. SK verifies ownership of the domain from appropriate domain registry. In case of .ee domains it is EENet (www.eenet.ee) and for international domains whois.net is used. We always contact domain's administrative contact before issuing certificate. b) for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; SK issues personal certificates for Estonian ID-card. E-mail address in the certificate is not that person claims but generated by the issuer in a form Surname.Lastname[.X]@eesti.ee. The eesti.ee mail server runs just a forwarding service – it is not a full-fledged mail service. The user's duty is to authenticate to the service with his ID-card and register his actual e-mail address with the service. c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; SK currently is not issuing code-signing certificates. Nevertheless, SK itself uses few self-issued code-signing certificates for it's own purposes. 4) We did not find any problematic practice that would be relevant. 5) Contacting our auditor is fine by us. 6) This years audit is ongoing as we speak. With best regards, Lembitu
>> Although the extension is critical, conforming implementations are not >> required to support this extension. > I can see from this that CDP should be marked as critical, but software > can ignore it at will. Conforming implementations are not required to support it, but ALL conforming implementations ARE required to reject certs and CRLs that contain critical extensions that they do not support. Critical extensions cannot be ignored. > In Mozilla case it seems that you produce a crash instead. A crash? Do you mean that the program stops executing? Or do you mean that Firefox rejects the CRL and/or the cert being validated, but continues to run? If it actually crashes, do you have any mozilla crash numbers for the crashes?
I have completed the independent verification of the audit report. From KPMG Baltics AS: "We confirm that the audit report for Sertifitseerimiskeskus AS, currently available on http://www.sk.ee/file.php?id=430, is issued by KPMG Baltics AS and is the same as the original report." Kathleen
The information gathering phase of this request is complete. This request is ready for the public discussion phase, and will be prioritized and scheduled as per https://wiki.mozilla.org/CA:Schedule In regards to some of the CRLs resulting in the ffffe095 error code due to the CIDP being flagged as critical... The holders of the patent have granted the right to use that patented technology in NSS, so the NSS team is now working on implementing the code that will understand and use the CIDP. There will also have to be changes in Firefox to make this work. I don't currently know of the schedule for this work to be completed, but it may be at least six months. Would it be reasonable for you to remove the critical flag from those CRLs? Thanks, Kathleen
Assignee: kathleen95014 → hecker
Whiteboard: Information confirmed complete
In comment 9, Lembitu Ling seems to have written that his CA's CRLs cause Mozilla to crash. That needs to be resolved before this can go forward, IMO.
I think that "crash" was not the intended word. In Firefox the following CRLs result in Error Code ffffe095 http://www.sk.ee/crls/juur/crl.crl http://www.sk.ee/crls/esteid/esteid.crl http://www.sk.ee/crls/esteid/esteid2007.crl http://www.sk.ee/crls/eid/eid2007.crl While these URLs work: http://www.sk.ee/crls/test/crl.crl http://www.sk.ee/crls/klass3/klass3.crl http://www.sk.ee/crls/eid/eid.crl I believe that it'll be the case that either the critical flag will have to be removed from the CIDP of the corresponding CRLs, or the root will have to only be accepted for a version of Firefox that has the code change to accept this. Kathleen
(In reply to comment #14) > In comment 9, Lembitu Ling seems to have written that his CA's CRLs cause > Mozilla to crash. That needs to be resolved before this can go forward, > IMO. Sorry, "crash" was really a bit strong word here. It does not allow to import CRL and produces error code ffffe095. As of removing the CIDP i still see that RFC states that "Although the extension is critical, conforming implementations are not required to support this extension." and Nelson Bolyard states that "Critical extensions cannot be ignored." - you might have some misunderstanding with RFC here. But we do not have really anything against removing critical flag from CIDP. We just have to consult our Manager of Certification Services about this and if he has nothing against removing that flag, we will remove it. Will give new feedback on this topic ASAP.
Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.
Assignee: hecker → kathleen95014
Hi Katlheen! I'd like to inform you that Lembitu Ling has ended up his employment relationship with Sertifitseerimiskeskus. I am taking over all the communications regarding getting SK root certificate included in Mozilla. Could you please give me a short overview how things are. 2008-10-20 16:07:26 you wrote that NSS team is going to implement the code that will understand and use the CIDP. Do you have any update how's it going?
Hi Liisa, I'm happy to provide you with current status for this request. This request is in the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion The status column indicates which request is currently in discussion. Only one request can be in the first discussion at a time, and it takes one to two weeks for each request. A description of the overall inclusion process can be found here: https://wiki.mozilla.org/CA:How_to_apply The information that has been gathered and verified is in the attachment to this bug. A couple of weeks before this request goes into public discussion, I will re-review the information to see what needs to be updated, such as an audit report from an audit that was done within the past year. I will post the request for updated information in this bug. The CRLs that were giving errors in Firefox before are still giving errors and won't load. I don't have a time frame for when CIDP will be supported in Firefox. Please see our recommendation at https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension
Hi Kathleen. We are about to consider negative aspects of changing our current CRL's (not to put critical CIDP extensions into full CRLs). Which CRL's are important for you? Is it only CRL of our Root Certificate (JUUR-SK) http://www.sk.ee/crls/juur/crl.crl or do we need to remove the critical flag from the CIDP of all our CRLs. Webserver cerificates are issued only under KLASS3-SK. Do you have any update when Firefox starts supporting CIDP?
In answer to comment 20, Firefox will interpret any CRL with a critical CIDP as being a partial or indirect CRL, so all full CRLs need to be free of critical CIDPs. This is important for the CRLs accessed for any cert that has CDP but not AIA/OCSP extensions.
In preparation for the public discussion phase, I have re-reviewed the information that has been gathered and verified for this request. There are three items that need to be updated: 1) The audit that we have is from 2007. Comment #9: (2008-10-16): This years audit is ongoing as we speak. Please provide a recent audit that meets requirements of sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/ 2) The list of Potentially Problematic Practices has been updated http://wiki.mozilla.org/CA:Problematic_Practices Please review the list and indicate which ones are relevant. Where relevant, please provide further information. 3) CRLs These CRLs download into Firefox without error: http://www.sk.ee/crls/test/crl.crl http://www.sk.ee/crls/eid/eid.crl http://www.sk.ee/crls/klass3/klass3.crl These CRLs give the ffffe095 error when downloading into Firefox: http://www.sk.ee/crls/juur/crl.crl http://www.sk.ee/crls/esteid/esteid.crl http://www.sk.ee/crls/esteid/esteid2007.crl http://www.sk.ee/crls/eid/eid2007.crl As Nelson said in Comment #21, full CRLs should not have a critical CIDP. Also, in Section 2.4.2 of KLASS3-SK CP it says: “The guaranteed frequency of publication is 12 hours.” However, it looks like NextUpdate is 9 days for http://www.sk.ee/crls/klass3/klass3.crl
1) new audit is from 2008, this years audit is ongoing. it will take some time with translations, will send you link asap. 2) the only relevant is "CRL with critical CIDP Extension" 3) can you please explain in which case do you use other CRL's beside http://www.sk.ee/crls/klass3/klass3.crl (for websertificates) and http://www.sk.ee/crls/juur/crl.crl (for Root Certificate)? in our option only these two are relevant for you. please confirm. klass3.crl downloads into Firefox without error and we're ready to change the other crl at the beginning of next week 4) reg klass3.crl updates we will change frequency back to 12 hours at the beginning of next week
>> 1) new audit is from 2008, this years audit is ongoing. it will take some >> time with translations, will send you link asap. A link to the 2008 audit and the corresponding translation will be great. >> 2) the only relevant is "CRL with critical CIDP Extension" Thanks for reviewing the updated list of potentially problematic practices. >> 3) can you please explain in which case do you use other CRL's beside >> http://www.sk.ee/crls/klass3/klass3.crl (for websertificates) and >> http://www.sk.ee/crls/juur/crl.crl (for Root Certificate)? >> in our option only these two are relevant for you. please confirm. >> klass3.crl downloads into Firefox without error and we're ready to change the >> other crl at the beginning of next week I tried all of the CRLs for the root and sub-CAs that are provided at: http://www.sk.ee/pages.php/0202040202,36 I assumed that they are all relevant because you have requested the websites, email, and code signing trust bits be enabled for this root. Are the following 3 CRLs irrelevant because the corresponding certs are only used for ID cards? http://www.sk.ee/crls/esteid/esteid.crl http://www.sk.ee/crls/esteid/esteid2007.crl http://www.sk.ee/crls/eid/eid2007.crl >> 4) reg klass3.crl updates we will change frequency back to 12 hours at the >> beginning of next week Thanks.
> > Are the following 3 CRLs irrelevant because the corresponding certs are only > used for ID cards? > http://www.sk.ee/crls/esteid/esteid.crl > http://www.sk.ee/crls/esteid/esteid2007.crl > http://www.sk.ee/crls/eid/eid2007.crl That's correct, these 2 are used for ID-Card > http://www.sk.ee/crls/esteid/esteid.crl > http://www.sk.ee/crls/esteid/esteid2007.crl and these are used for Mobile-ID (wpki) > http://www.sk.ee/crls/eid/eid2007.crl > http://www.sk.ee/crls/eid/eid.crl
1) 2008 audit in english is available www.sk.ee/files/Certification service and timestamping service provider information system audit report 2008 by KPMG.pdf 2) CRLs download now without error: >> http://www.sk.ee/crls/klass3/klass3.crl (for websertificates) >> http://www.sk.ee/crls/juur/crl.crl (for Root Certificate)? 3) klass3.crl updates are changed to 12 hours Is there anything else missing?
> 1) 2008 audit in english is available www.sk.ee/files/Certification service > and timestamping service provider information system audit report 2008 by > KPMG.pdf Would you please send me the exact url? I can only seem to find the old audit. I can now download the root and website cert CRLs into Firefox without error, and I can see that the NextUpdate for klass3.crl is 12 hours.
My apologies. Exact URL is http://www.sk.ee/file.php?id=457
Updating the information gathering document in preparation for the public discussion. Note that I have exchanged email with KPMG and confirmed the authenticity of the new audit.
Attachment #343982 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from Sertifitseerimiskeskus to add the Juur-SK root certificate to NSS and enable all three 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 firstname.lastname@example.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 “Sertifitseerimiskeskus Root Inclusion Request” Please actively review, respond, and contribute to the discussion.
Whiteboard: Information confirmed complete → In public discussion
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 a new root CA certificate for Sertifitseerimiskeskus AS. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Sertifitseerimiskeskus, 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. There were some concerns expressed in the comment period regarding Sertifitseerimiskeskus’s TEST-SK intermediate CA not being covered by a documented and audited CP. To alleviate this concern, Sertifitseerimiskeskus has decided to delete the TEST-SK intermediate CA. The recommendation is that this action item be completed before creating the NSS bug to add the root. Section 6 [Relevancy and Policy]. Sertifitseerimiskeskus appears to provide a service relevant to Mozilla users: It is a commercial CA, covering the Baltic region - Estonia, Lithuania, Latvia. 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 Certification Practice Statement and the Certificate Policy for Device Certificates. Both of these documents are provided in English. CPS: http://www.sk.ee/file.php?id=432 Certificate Policy for Device Certificates: http://www.sk.ee/file.php?id=434 Section 7 [Validation]. Sertifitseerimiskeskus appears to meet the minimum requirements for subscriber verification, as follows: * Email: Not applicable. Sertifitseerimiskeskus is not requesting that the email trust bit be enabled. * SSL: 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. * Code: Sertifitseerimiskeskus verifies the identity and the authorization of the entity submitting the certificate signing request. Section 8-10 [Audit]. Section 8-10 [Audit]. * A recent audit performed by KPMG has been posted on the CA’s website. The authenticity of the audit report has been confirmed. The audit report clearly states that the audit checked and verified compliance with legal acts, the Certification Practice Statement, the Digital Signatures Act, and ETSI TS 101 456. No issues were noted in the report. Section 13 [Certificate Hierarchy]. * This Juur-SK root issues three types of internally operated subordinate CAs. The first type of subordinate CA is used to issue electronic ID cards which contain certificates for digital signature and for digital identification. The second type of subordinate CA is used to issue internal ID cards of the Republic of Estonia. The third type of subordinate CA is used to issue device, SSL, and code signing certificates. There is a separate CP for each subordinate CA. Other: * NextUpdate for the CRL for website certs is 12 hours. * OCSP is not provided for website certs. Potentially problematic practices: None noted. Based on this assessment I recommend that Mozilla approve this request to add the Juur-SK root certificate to NSS, and enable the Websites and Code Signing trust bits. However, I recommend that the NSS bug should not be created until Sertifitseerimiskeskus has completed their action item to delete the TEST-SK intermediate CA.
> To alleviate this concern, Sertifitseerimiskeskus has decided to delete the > TEST-SK intermediate CA. Delete? Do you mean revoke? I think revocation is necessary.
Yes, I meant revoke. I'll also check the CRL to verify when the action item has been completed.
To Kathleen: As always, thank you for your work on this request. To the representatives of Sertifitseerimiskeskus AS: 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. I have reviewed the summary and recommendation in comment #31 (along with the clarification in comment #33), and on behalf of the Mozilla project I approve this request from Sertifitseerimiskeskus AS to include the following root certificate in Mozilla, with trust bits set as indicated: * Juur-SK (web sites, code signing) Kathleen, could you please file the necessary bugs against NSS and PSM to effect the approved changes? When those bugs are completed please change the status of this bug to RESOLVED FIXED. Thanks in advance!
Whiteboard: In public discussion → Approved
Thanks! Liisa, please let me know when the TEST-SK intermediate CA has been revoked. I'll create the NSS bug after I see the TEST-SK CA in the CRL/ARL.
Whiteboard: Approved → Approved - awaiting CA confirmation of Test CA revocation
dear kathleen, i'm happy to inform you that we have revoked TEST-SK intermediate CA (issued by JUUR-SK). please find JUUR-SK CRL http://www.sk.ee/crls/juur/crl.crl
For TEST-SK intermediate CA: Certificate SerialNumber=3c b4 25 19 The TEST-SK intermediate CA is signed by the Juur-SK root CA with CRL http://www.sk.ee/crls/juur/crl.crl I opened that CRL and found that the certificate with Serial number 3c b4 25 19 was revoked on Tuesday, December 01, 2009 2:10:16 AM This completes the action items for this root inclusion request. I will create the NSS bug.
Whiteboard: Approved - awaiting CA confirmation of Test CA revocation → Approved - awaiting NSS
I have filed bug 532742 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In NSS 3.12.6 and Firefox 3.6.2
You need to log in before you can comment on or make changes to this bug.