414520 - Add Sertifitseerimiskeskus AS root CA certificate

Status: RESOLVED FIXED

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

Description

[Lembitu Ling]

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.

Comment 1

[timeless]

Class (domain-validated, identity/organisationally-validated or EV): 
Certificate Policy URL: 

you left those two fields blank, which seems odd.

Comment 2

[Lembitu Ling]

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. 

Comment 3

[Frank Hecker]

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?

Comment 4

[Lembitu Ling]

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

Comment 5

[Lembitu Ling]

Hi,

Added KLASS3-SK CP, available at http://www.sk.ee/files/Seadmesert_CP_en-1.00.pdf

Comment 6

[Lembitu Ling]

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

Comment 7

[Kathleen Wilson]

Accepting this bug so I can proceed with the information gathering/verification phase.

Comment 8

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

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

Comment 9

[Lembitu Ling]

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

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

>> 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?

Comment 11

[Kathleen Wilson]

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

Comment 12

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 13

[Kathleen Wilson]

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

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 15

[Kathleen Wilson]

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

Comment 16

[Lembitu Ling]

(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.

Comment 17

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.

Comment 18

[Liisa Lukin]

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?

Comment 19

[Kathleen Wilson]

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

Comment 20

[Liisa Lukin]

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?

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 22

[Kathleen Wilson]

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

Comment 23

[Liisa Lukin]

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

Comment 24

[Kathleen Wilson]

>> 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.

Comment 25

[Liisa Lukin]

> 
> 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

Comment 26

[Liisa Lukin]

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?

Comment 27

[Kathleen Wilson]

> 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.

Comment 28

[Liisa Lukin]

My apologies. Exact URL is http://www.sk.ee/file.php?id=457

Comment 29

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

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.

Comment 30

[Kathleen Wilson]

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

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

Comment 31

[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 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.

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

> To alleviate this concern, Sertifitseerimiskeskus has decided to delete the 
> TEST-SK intermediate CA. 

Delete?  Do you mean revoke?  I think revocation is necessary.

Comment 33

[Kathleen Wilson]

Yes, I meant revoke. I'll also check the CRL to verify when the action item has been completed.

Comment 34

[Frank Hecker]

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!

Comment 35

[Kathleen Wilson]

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.

Comment 36

[Liisa Lukin]

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

Comment 37

[Kathleen Wilson]

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.

Comment 38

[Kathleen Wilson]

I have filed bug 532742 against NSS for the actual changes.