SK Root Inclusion Request for Renewed Root

[Kathleen Wilson]

SK (Certification Centre, legal name AS Sertifitseerimiskeskus) has
applied 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.

SK is a commercial CA, covering the Baltic region (Estonia, Lithuania,
Latvia). SK is Estonia's primary certification authority, providing
certificates for authentication and digital signing to Estonian ID
Cards. 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 (e.g. Police).

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=624356

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Sertifitseerimiskeskus

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=526096

Noteworthy points:

* The primary documents 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

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

The request is to turn on the Websites and Code Signing trust bits.

* CP of Organisation Certs section 4.2.1: The acceptance or rejection of
the applications for certificates is the decision of the SK. Prior to
making a decision, the SK checks the following:
- The identity of the Client (including the registered status of the
legal person in accordance with the legislation of its home country)
- The identity of the Client’s representative
- The authority of the Client’s representative to apply for a
certificate and/or for
the revocation of a certificate on behalf of the Client
- Correctness and completeness of data submitted by the Client
- Whether the Client has the right to receive a certificate according to
the legislation of the Republic of Estonia and/or this CP
In the case of applications for digital seals, the uniqueness of the
distinguished name of a certificate is also verified.
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.
The decision of the SK is subject to the results of the aforementioned
checks and the
SK has the right to refuse to issue a certificate.

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

* Root Cert URL: http://www.sk.ee/files/EECCRCA.PEM.cer

* Test Website: https://www.openxades.org/

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

* OCSP
http://ocsp.sk.ee (Access is subject to contract.)

* 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

* Potentially Problematic Practices – None Noted
(http://wiki.mozilla.org/CA:Problematic_Practices):

This begins the discussion of the request from SK
(Sertifitseerimiskeskus) to add the “EE Certification Centre Root CA”
root certificate and turn on the Websites and Code Signing trust bits.
At the conclusion of this discussion I will provide a summary of issues
noted and action items. If there are outstanding issues, then an
additional discussion may be needed as follow-up. If there are no
outstanding issues, then I will recommend approval of this request in
the bug.

Kathleen

[Erwann Abalea]

The provided test site shows that no random is being put in the certificate, neither in the serial number nor in the subject name, while the certificate is still signed with SHA1+RSA. Looking at the CRL shows that the serial number is certainly sequential.

The intermediate CA doesn't provide any link to get its revocation status. No CRL, no OCSP.

Why do the root contain all these OIDs in the extendedKeyUsage extension: TLS Web Client Authentication, TLS Web Server Authentication, Code Signing, E-mail Protection, Time Stamping, OCSP Signing?

[tarvi....@gmail.com]

SK does not provide HTTPS certificates in automated way. Therefore issuance time cannot be predicted and serves perfectly for achieving quasi-randomness required for elliminating threat with SHA1 weakness.

Both KLASS3-SK and KLASS3-SK 2010 intermediate certificates used for issuing HTTPS certificates provide for CRL link, see:
http://www.sk.ee/en/repository/certs/

Excessive usage of extendedKeyUsage is motivated by Microsoft policies - they tend to define root certificate usages (and resulting in the whole chain) according to values noted in EKU field. For example we were excluded from business of issuing code-signing certificates because our old root certificate (Juur-SK) did not contain "code-signing" in the EKU field...

[tarvi....@gmail.com]

reede, 6. aprill 2012 12:00.11 UTC+3 kirjutas Erwann Abalea:

[Erwann Abalea]

Le mardi 10 avril 2012 20:07:39 UTC+2, tarvi....@gmail.com a écrit :
> reede, 6. aprill 2012 12:00.11 UTC+3 kirjutas Erwann Abalea:
> > The provided test site shows that no random is being put in the certificate, neither in the serial number nor in the subject name, while the certificate is still signed with SHA1+RSA. Looking at the CRL shows that the serial number is certainly sequential.
> >
> > The intermediate CA doesn't provide any link to get its revocation status. No CRL, no OCSP.
> >
> > Why do the root contain all these OIDs in the extendedKeyUsage extension: TLS Web Client Authentication, TLS Web Server Authentication, Code Signing, E-mail Protection, Time Stamping, OCSP Signing?
>
> SK does not provide HTTPS certificates in automated way. Therefore issuance time cannot be predicted and serves perfectly for achieving quasi-randomness required for elliminating threat with SHA1 weakness.

Does that account for 20 bits of entropy, as required by Mozilla CA policy and CA/B BR?

> Both KLASS3-SK and KLASS3-SK 2010 intermediate certificates used for issuing HTTPS certificates provide for CRL link, see:
> http://www.sk.ee/en/repository/certs/

The KLASS3-SK 2010 certificate doesn't contain a CRLDP extension, and doesn't contain an AIA:OCSP extension. So if this certificate were to be revoked, a relying party couldn't be informed.

> Excessive usage of extendedKeyUsage is motivated by Microsoft policies - they tend to define root certificate usages (and resulting in the whole chain) according to values noted in EKU field. For example we were excluded from business of issuing code-signing certificates because our old root certificate (Juur-SK) did not contain "code-signing" in the EKU field...

Strange. Other roots trusted for code signing don't have this extension. OCSP Signing, for example, is not necessary for the CA. TimeStamping usage requires the EKU extension to be critical.

[ianG]

On 12/04/12 21:38 PM, Erwann Abalea wrote:
> Le mardi 10 avril 2012 20:07:39 UTC+2, tarvi....@gmail.com a écrit :

>> reede, 6. aprill 2012 12:00.11 UTC+3 kirjutas Erwann Abalea:
>>> The provided test site shows that no random is being put in the certificate, neither in the serial number nor in the subject name, while the certificate is still signed with SHA1+RSA. Looking at the CRL shows that the serial number is certainly sequential.
>>>
>>> The intermediate CA doesn't provide any link to get its revocation status. No CRL, no OCSP.
>>>
>>> Why do the root contain all these OIDs in the extendedKeyUsage extension: TLS Web Client Authentication, TLS Web Server Authentication, Code Signing, E-mail Protection, Time Stamping, OCSP Signing?
>>
>> SK does not provide HTTPS certificates in automated way. Therefore issuance time cannot be predicted and serves perfectly for achieving quasi-randomness required for elliminating threat with SHA1 weakness.
>

> Does that account for 20 bits of entropy, as required by Mozilla CA policy and CA/B BR?

I wondered that too. If one assumes second resolution of time-stamp,
and issuance time to around an hour uncertainty, this gives around 12
bits. 20 bits would require 12 days. Possible but unlikely :)

Personally, I'd not be too worried about this. If the CA has a medium
term plan to upgrade, and SHA1 holds up until then, there is little
issue. They've obviously thought about it. The original attack was
against MD5 which was already broken (SHA1 is not) and it took them many
months of trying to get it right. SHA1 has held up for now, and it is
unlikely to fall from grace in any dramatic fashion.

If it is an issue, perhaps the CA could just add a random number of
seconds from 1 to 2^n on to the end of the expiry date?

iang

[Peter Kurrasch]

I know this came up before, but could someone explain (or point me to the
explanation) of why this entropy must be placed in the "main" body of the
cert before the key field (as opposed to an extension)?

Thanks.

Oh, and why not just use date, hour, min, *and* sec for randomness in both
issuance and expiration dates? Surely the most relevant portion of either
is year+month?

On Thu, Apr 12, 2012 at 6:57 AM, ianG <ia...@iang.org> wrote:

> . . .

[Kathleen Wilson]

On 4/12/12 12:35 PM, Peter Kurrasch wrote:
> I know this came up before, but could someone explain (or point me to the
> explanation) of why this entropy must be placed in the "main" body of the
> cert before the key field (as opposed to an extension)?
>

I think that originally the random data requirement was added to help
prevent attacks against non collision-resistant hash functions such as
MD5 and perhaps SHA1.

http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
#9, last sub-bullet:
"all new end-entity certificates must contain at least 20 bits of
unpredictable random data (preferably in the serial number)."

It was discussed here:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0sF31Ch9nhg

Kathleen

[Robin Alden]

I think the original suggestion to put the randomness as early as
possible came from here:
http://www.win.tue.nl/hashclash/rogue-ca/#sec7
Specifically it is to address the 'chosen prefix' attack that was
successful against MD5.

Regards
Robin Alden
Comodo

> -----Original Message-----
> Kathleen Wilson Sent:

>
> On 4/12/12 12:35 PM, Peter Kurrasch wrote:

> > I know this came up before, but could someone explain (or point me
to
> > the
> > explanation) of why this entropy must be placed in the "main" body
of
> > the cert before the key field (as opposed to an extension)?
> >
>

> I think that originally the random data requirement was added to help
> prevent attacks against non collision-resistant hash functions such as
> MD5 and perhaps SHA1.
>
> http://www.mozilla.org/projects/security/certs/policy/MaintenancePoli
> cy.html
> #9, last sub-bullet:
> "all new end-entity certificates must contain at least 20 bits of
> unpredictable random data (preferably in the serial number)."
>
> It was discussed here:
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/0s
> F31Ch9nhg
>
> Kathleen

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[ianG]

On 13/04/12 05:35 AM, Peter Kurrasch wrote:
> I know this came up before, but could someone explain (or point me to the
> explanation) of why this entropy must be placed in the "main" body of the
> cert before the key field (as opposed to an extension)?

I don't know the answer to why it should be in the main body.

The cryptographic purpose is to stop the text from being predictable.
If the text, or "image" can be predicted, then it is possible to crunch
a weak message digest like MD5 and find alternate texts that have the
same hash.

So it has to be inside the hash text, from a crypto pov. There may be
reasons in x509 packets why we can't just slip in some randomness
anywhere we want.

> Thanks.
>
> Oh, and why not just use date, hour, min, *and* sec for randomness in both
> issuance and expiration dates? Surely the most relevant portion of either
> is year+month?

No, the year is entirely predictable, it is 2012 and 2013. The month is
April and April, and the day is 13 and 13. Bad luck :)

Only the parts which are uncertain are useful as randomness, so I'd say
the mins-sec in both issuance and expiration. Just as an outsider's
observation / guess.

iang

> On Thu, Apr 12, 2012 at 6:57 AM, ianG<ia...@iang.org> wrote:
>
>> . . .
>>
>> I wondered that too. If one assumes second resolution of time-stamp, and
>> issuance time to around an hour uncertainty, this gives around 12 bits. 20
>> bits would require 12 days. Possible but unlikely :)
>>
>> Personally, I'd not be too worried about this. If the CA has a medium
>> term plan to upgrade, and SHA1 holds up until then, there is little issue.
>> They've obviously thought about it. The original attack was against MD5
>> which was already broken (SHA1 is not) and it took them many months of
>> trying to get it right. SHA1 has held up for now, and it is unlikely to
>> fall from grace in any dramatic fashion.
>>
>> If it is an issue, perhaps the CA could just add a random number of
>> seconds from 1 to 2^n on to the end of the expiry date?
>>
>>

[Phillip Hallam-Baker]

The requirement for randomness comes from a particular attack on a
particular digest function.

If the digest function is sound there is no or rather little need for
the randomness.


The idea of the attack was that the attacker constructs a certificate
request in such a way that when the certificate is issued for signed
data X it is also valid for signed data X' where the difference
between X and X' is ideally just the requisite bits to permit certs to
be signed.

For the attack to work at all the attacker has to be confident that
they can predict X from the data sent in their CSR. The randomness has
to be introduced before the data that is sent by the user which
includes the subject name and the public key, both are chosen by the
user.

[NB: Even though the modulus n is traditionally calculated from p and
q, this is not the only way you can do it. It is equally possible to
chose candidates for n and p and then work out q. This allows the MSB
of n to be chosen,]


There are much better ways to defeat this particular attack. At a
protocol level a signer should never be in the position of applying
RSA or any other public key algorithm or a digest function to data
that is under the control of another party.

In the ideal case the randomness would be inserted into the digest
function direct as in the 'randomized hashing' approach. For example
take a MAC function and use a random seed s as the key, the digest
value is then s + MAC (m, s).

My preference is for the MAC approach as it makes it possible to use
AES to support all the cryptographic primitives required for an
embedded device. But your mileage may vary.

--
Website: http://hallambaker.com/

[m...@ssc.lt]

Hi,

> SK is a commercial CA, covering the Baltic region (Estonia, Lithuania,
> Latvia). SK is Estonia's primary certification authority, providing

Can you please present more info on your "covering the Baltic region"?

I'm specifically interested in understanding what CA obligations you've delegated to third parties and publicly available policy and/or practice documents those delegated parties supposed to follow.

Unfortunately your web site doesn't contain any links to any third parties outside of your own country.

Thanks,
M.D.

[m...@ssc.lt]

Hi,

> SK is a commercial CA, covering the Baltic region (Estonia, Lithuania,
> Latvia). SK is Estonia's primary certification authority, providing

[Peter Kurrasch]

I don't have much of a problem with added randomness--one may think of it
as extra fat that makes the whole system work better. However, since I'm
not most familiar with the mechanics of signing/issuing certs (more
experienced with the receiving end of certificate clutter) I feel like I'm
still missing something.

For the attack you describe, I'm assuming it would be most effective with
an end certificate (non-CA). For a root or intermediate cert I would hope
that the authority doing the signing could detect and thus not allow the
attack scenario...?

Is it fair to say that there are 2 varieties of attacks at play here: 1)
tampering with a cert so you can insert your own key; and 2) fraudulently
obtaining a valid cert...?

Thanks.

[ianG]

On 17/04/12 08:54 AM, Peter Kurrasch wrote:
> I don't have much of a problem with added randomness--one may think of it
> as extra fat that makes the whole system work better. However, since I'm
> not most familiar with the mechanics of signing/issuing certs (more
> experienced with the receiving end of certificate clutter) I feel like I'm
> still missing something.

All [0] digital signatures are first done by hashing the message
(certificate body) with a message digest like MD5, SHA1 and increasingly
SHA2.

Then, the public key signature is done by RSA (or variants) over the
hash. So each digsig is a two-phase operation.

More importantly, for this discussion, the signature can be attacked at
two points - the hash *or* the RSA operation. Double trouble! Either
one can cause chaos if weak.

The hash attack works by (a) knowing what the cert looks like up-front,
(b) crunching that to find two matching certs, and (b) asking for a
signature on hash of cert1 when it also matches cert2.

In this case, a hash like SHA1 has 80 bits [1] of strength, or a little
less coz the academic attacks have lopped a few off. We expect academic
attacks to crack through that in due course and reduce it to say 60 ...
at which point it becomes achievable to crunch the whole thing.

So, by adding in 20 bits of randomness into the packet, we make it 2^20
times harder to attack. Think of this as adding 10-20 years crunching
strength. By which time, SHA2 and SHA3 will roll out.

> For the attack you describe, I'm assuming it would be most effective with
> an end certificate (non-CA). For a root or intermediate cert I would hope
> that the authority doing the signing could detect and thus not allow the
> attack scenario...?

Oh. No, far worse. If an intermediate can be forged by the attack on
the hash, then the attacker has a valid intermediate. Which he can use
to create as many certs as he likes, hand them out willy nilly and the
CA need never know until some accident of security happens and the cert
is forwarded for manual validation.

(This is indeed what happened in the original Rabbit attack. The team
of academics used an end-entity user cert to forge an intermediate cert
against an MD5 hash. MD5 hashes are 64 bits in strength, and there was
no randomness in the cert body.)

For a root cert, it doesn't matter, because a root cert gets its value
from being in a root list. Logically it isn't signed at all, as
self-signatures are security-wise of little meaning. Practically it is
self-signed because PKI has to distro the public key somehow, and the
method available is self-signed certs.

> Is it fair to say that there are 2 varieties of attacks at play here: 1)
> tampering with a cert so you can insert your own key; and 2) fraudulently
> obtaining a valid cert...?

Many variants, yes. A recent attack in Asia was purported to be (full
disclosure still lacking) a complete creation of 9 fresh certs by
crunching new RSA signatures without any communication with the CA.
This was for 512bit RSA sigs, now thought to be weak.

Crypto is very complicated. public key crypto is even more complicated.
PKI is horrendously more complicated...



iang

> On Fri, Apr 13, 2012 at 9:03 AM, Phillip Hallam-Baker<hal...@gmail.com>wrote:
>
>> The requirement for randomness comes from a particular attack on a
>> particular digest function.
>>
>> If the digest function is sound there is no or rather little need for
>> the randomness.
>>
>>
>> The idea of the attack was that the attacker constructs a certificate
>> request in such a way that when the certificate is issued for signed
>> data X it is also valid for signed data X' where the difference
>> between X and X' is ideally just the requisite bits to permit certs to
>> be signed.
>>
>> For the attack to work at all the attacker has to be confident that
>> they can predict X from the data sent in their CSR. The randomness has
>> to be introduced before the data that is sent by the user which
>> includes the subject name and the public key, both are chosen by the
>> user.
>>
>> [NB: Even though the modulus n is traditionally calculated from p and
>> q, this is not the only way you can do it. It is equally possible to
>> chose candidates for n and p and then work out q. This allows the MSB
>> of n to be chosen,]
>>

[0] or nearly all, certainly these ones.

[1] I'm deliberately fudging topics like birthday attacks here for
explanatory purposes.

[Paul Tiemann]

Thanks Ian - I think you put together a really good description.

Cheers,
Paul

[tarvi....@gmail.com]

> > SK does not provide HTTPS certificates in automated way. Therefore issuance time cannot be predicted and serves perfectly for achieving quasi-randomness required for elliminating threat with SHA1 weakness.
>
> Does that account for 20 bits of entropy, as required by Mozilla CA policy and CA/B BR?

This has been an utterly interesting discussion regarding requirement for entorpy with SHA1. As it is not really a practical threat right now we will consider both options of having serial number randomized and also having expiry date ranomized - perhaps a little - it might confuse our clients.

> The KLASS3-SK 2010 certificate doesn't contain a CRLDP extension, and doesn't contain an AIA:OCSP extension. So if this certificate were to be revoked, a relying party couldn't be informed.

Oh, id does, it contains: [1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://www.sk.ee/crls/juur/crl.crl

> > Excessive usage of extendedKeyUsage is motivated by Microsoft policies - they tend to define root certificate usages (and resulting in the whole chain) according to values noted in EKU field. For example we were excluded from business of issuing code-signing certificates because our old root certificate (Juur-SK) did not contain "code-signing" in the EKU field...
>
> Strange. Other roots trusted for code signing don't have this extension. OCSP Signing, for example, is not necessary for the CA. TimeStamping usage requires the EKU extension to be critical.

Well, they do. We did an excessiv analysis of other root certs before this decision. Do browse your machine for root certs...

[tarvi....@gmail.com]

It is true that we are issuing certs in Baltic area whereas we do it for _webserver_ certs this in Estonia only. In case we would extend this business area to Latvia and/or Lithuania and involve third parties, corresponding clauses will appear in our CP.

Tarvi

[Erwann Abalea]

Le vendredi 20 avril 2012 01:28:32 UTC+2, tarvi....@gmail.com a écrit :
> > The KLASS3-SK 2010 certificate doesn't contain a CRLDP extension, and doesn't contain an AIA:OCSP extension. So if this certificate were to be revoked, a relying party couldn't be informed.
>
> Oh, id does, it contains: [1]CRL Distribution Point
> Distribution Point Name:
> Full Name:
> URL=http://www.sk.ee/crls/juur/crl.crl

I connected to the presented test website (https://www.openxades.org), and the intermediate certificate doesn't contain this extension.

> > > Excessive usage of extendedKeyUsage is motivated by Microsoft policies - they tend to define root certificate usages (and resulting in the whole chain) according to values noted in EKU field. For example we were excluded from business of issuing code-signing certificates because our old root certificate (Juur-SK) did not contain "code-signing" in the EKU field...
> >
> > Strange. Other roots trusted for code signing don't have this extension. OCSP Signing, for example, is not necessary for the CA. TimeStamping usage requires the EKU extension to be critical.
>
> Well, they do. We did an excessiv analysis of other root certs before this decision. Do browse your machine for root certs...

I did. And I only found 1 CA with everything put in EKU, a spanish one with a 1024 bits key and other stupid things. And several instances of "UTN-USERFirst", with reduced usages (SGC+webserver, ipsec, user mail).
That's on the Mozilla list.

[Moudrick M. Dadashov]

Sorry, you didn't answer my question.

A CA pretending to be a trustworthy must disclose it's policies and practices regardless of profiles of certificates she issues. It's about your CA, your RA and your obligations to RPs.

The practice you have shown in the area causes a lot of questions and I expect the company should respect interests of all parties. You do have a contractual relationship with an outsourced RA, don't you?

The RA - a mobile operator - has created it's own an unprecented 'legal system', I think it's for benefit of everybody if the CA discloses this unique operational model. Thanks.

M.D.

tarvi....@gmail.com wrote:

[Kathleen Wilson]

Thank you to all of you who have reviewed and commented on this request
from Sertifitseerimiskeskus (SK). Here follows a summary of the discussion.

Questions were raised about there not being at least 20 bits of entropy
in the end-entity certificates. The resulting action item is for SK to
update their certificate issuance to either randomize the certificate
serial number, or include randomness in some other manner. One
suggestion was to add a random number of seconds from 1 to 2^n on to the
end of the expiry date.

It was clarified that the KLASS3-SK and KLASS3-SK 2010 intermediate
certificates used for issuing SSL/TLS certificates include a CRL
Distribution Point with a URI to the CRL. I re-confirmed this by
browsing to the test website, https://www.openxades.org, and viewing the
KLASS3-SK 2010 intermediate certificate CRL Distribution Point, which has
URI: http://www.sk.ee/crls/klass3/klass3-2010.crl
I have also imported that CRL into my Firefox browser without error.

A question was asked about the number of OIDs in extendedKeyUsage
extension, and response provided. No follow-up action is needed. Just a
comment that I believe that to avoid having to put all of the OIDs
specifically in, the root cert could either not specify
extendedKeyUsage, or could include anyExtendedKeyUsage.

Another question was asked about SK’s involvement in the Baltic region,
and a response provided. No follow-up action is needed.

There is only one action item resulting from this discussion:

ACTION SK: Make sure there is at least 20 bits of entropy in new
end-entity certificates.

My opinion is that this action item may be tracked in parallel with the
remainder of the root inclusion process.

If there are no further comments/questions about this request from SK,
then I will close this discussion, recommend approval in the bug, and
track the action item in the bug.

Thanks,
Kathleen

[Moudrick M. Dadashov]

Hi Kathleen,

Could we please wait a bit until we get my question about outsourced RA
obligations has been answered.

Thanks,
M.D.

On 4/24/2012 11:22 PM, Kathleen Wilson wrote:
> On 4/5/12 2:23 PM, Kathleen Wilson wrote:

[Kathleen Wilson]

On 4/24/12 3:06 PM, Moudrick M. Dadashov wrote:
> Hi Kathleen,
>
> Could we please wait a bit until we get my question about outsourced RA
> obligations has been answered.
>
> Thanks,
> M.D.
>

Of course. Sorry I overlooked that.

Kathleen

[Erwann Abalea]

Le mardi 24 avril 2012 22:22:06 UTC+2, Kathleen Wilson a écrit :
[...]

> It was clarified that the KLASS3-SK and KLASS3-SK 2010 intermediate
> certificates used for issuing SSL/TLS certificates include a CRL
> Distribution Point with a URI to the CRL. I re-confirmed this by
> browsing to the test website, https://www.openxades.org, and viewing the
> KLASS3-SK 2010 intermediate certificate CRL Distribution Point, which has
> URI: http://www.sk.ee/crls/klass3/klass3-2010.crl
> I have also imported that CRL into my Firefox browser without error.

This is the CRL issued by the intermediate CA to validate EE certificates, not the CRL issued by the root to validate this intermediate CA.

Connecting manually to the provided example site gives this intermediate certificate:

-----BEGIN CERTIFICATE-----
MIIEaTCCA1GgAwIBAgIQcJ+vg4742XhNgJW2ot9eIjANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJFRTEiMCAGA1UECgwZQVMgU2VydGlmaXRzZWVyaW1pc2tlc2t1
czEoMCYGA1UEAwwfRUUgQ2VydGlmaWNhdGlvbiBDZW50cmUgUm9vdCBDQTEYMBYG
CSqGSIb3DQEJARYJcGtpQHNrLmVlMB4XDTExMDMxNjEwNDkyNloXDTI0MDMxNjEw
NDkyNlowbTELMAkGA1UEBhMCRUUxIjAgBgNVBAoTGUFTIFNlcnRpZml0c2Vlcmlt
aXNrZXNrdXMxITAfBgNVBAsTGFNlcnRpZml0c2VlcmltaXN0ZWVudXNlZDEXMBUG
A1UEAxMOS0xBU1MzLVNLIDIwMTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrlaYRX2v89k8Hd0ADaOfnUcIn7iM6aOXkAR+jp5827ZhDqDyNddF9ZUoB
gPghGNIrkHbH7qwex39YnI0ka24lCjcwEMvQMPbyPnX/a4RyJ+wEZttmjBl++Ffr
ZK54L+vD7Dyy4YYB0Og9ktB4qptsDBj+giiv/MGPeGeNs3TacJdNb7+3splTPtPK
lDfrufvq4H6jNOv9S9bC+j2VVY9uCFXUro8AA3hoOEKJdSjlpYCa51N8KGLVJYRu
c/K81xqi054Jz+Cy/HY/AcXkk2JkxlpJoEXmcuTkxjO/QE/Xbd+mRJHnq6+HurOi
KcxKwZCPAa+d+dvRPkbyq9ohMXH9AgMBAAGjgfwwgfkwEgYDVR0TAQH/BAgwBgEB
/wIBADAOBgNVHQ8BAf8EBAMCAcYwgZIGA1UdIASBijCBhzCBhAYKKwYEAc4fBwEC
AjB2MCAGCCsGAQUFBwIBFhRodHRwOi8vd3d3LnNrLmVlL2NwczBSBggrBgEFBQcC
AjBGHkQAQQBzAHUAdAB1AHMAZQAgAHMAZQByAHQAaQBmAGkAawBhAGEAdAAuACAA
QwBvAHIAcABvAHIAYQB0AGUAIABJAEQALjAdBgNVHQ4EFgQUXXUUEYz0pY5Cj3uy
QESj7tZ6O3IwHwYDVR0jBBgwFoAUEvJaPupWHL/NBqzx8SXJqUvUFJkwDQYJKoZI
hvcNAQEFBQADggEBAGoictDDEniPQNUhwiGw7ZkqkDdu3veWjDtHe4gpiHF81h1D
xsBcd+npVN+um8ovHP1tjk2O1AT3eVUzZJzUCfl0vTjySKxhoZZwGq+Ifo5FJ/n1
z8LHe4SJ1s3bGbRJBd2khrTUeA+GosR32liOtok1XNAa4/P/qS/1mnJakX5Azsu4
sL4CtebmLRXRgUamq2sEPyFgXqVtvPy9ZF7DqIXoj7kA4Rl19//OAekprtpeA73x
6MkKBq3GLMeaLJyrAaAk/cKceYCAOEkPNk4QYb0FwvyF6ZfI28J5R7k0q5WeEK2e
iq0Pl4iCIxjPDzhufBwDV+yHtEb7bt31148c6lE=
-----END CERTIFICATE-----

which does contain no CRLDP and no OCSP URI, so it can't be easily revoked if something goes wrong.

Am I the only one to get this certificate? Is it geolocation dependent?

[Dimitris Zacharopoulos]

On 25/4/2012 1:55 πμ, Erwann Abalea wrote:
> Le mardi 24 avril 2012 22:22:06 UTC+2, Kathleen Wilson a écrit :
> [...]

>> It was clarified that the KLASS3-SK and KLASS3-SK 2010 intermediate
>> certificates used for issuing SSL/TLS certificates include a CRL
>> Distribution Point with a URI to the CRL. I re-confirmed this by
>> browsing to the test website, https://www.openxades.org, and viewing the
>> KLASS3-SK 2010 intermediate certificate CRL Distribution Point, which has
>> URI: http://www.sk.ee/crls/klass3/klass3-2010.crl
>> I have also imported that CRL into my Firefox browser without error.

I also confirm Erwann's observation concerning the subCA certificate.

Dimitris Zacharopoulos.

--
HARICA Public Key Infrastructure
http://www.harica.gr

Zacharopoulos Dimitris
AUTH Central Communication Facilities, Network Operations Center
NOC-AUTH, Thessaloniki, Macedonia, Greece
Tel. N.O.C.: +30-2310998483
Fax. N.O.C.: +30-2310998492
E-Mail: ji...@ccf.auth.gr

[tarvi....@gmail.com]

This is quite irrelevant to this discussion but shall be clarified anyways.

SK does NOT provide webserver certificates outside Estonia and does not have any contractual parties involved in this business.

However, SK DOES provide different other certificates to larger area, including for example tachograph certificates (Estonia, Latvia, Lithuaia, Finland, Russia) and end-user certificates for Mobile PKI. I presume the latter was topic of interest here as we provide certificates for Omnitel Mobile-ID in Lithuania.

Our CP for Mobile-ID (http://www.sk.ee/en/repository/CP/) says that RA-s involved in certificate provisioning are listed in www.sk.ee Indeed, EMT, Tele2, Elisa and Ominitel are listed both in pages http://www.sk.ee/en/kontakt/customerservice/ and http://www.sk.ee/en/services/other-services/mobiil-id/ so everything shall be sound.

Tarvi

[tarvi....@gmail.com]

KLASS3-SK 2010 certificates in https://www.openxades.org is replaced by now and the erroneous one (never used for any other issuance) will be revocated.

The issue of providing randomness in serial number is still under investigation.

Tarvi

[tarvi....@gmail.com]

KLASS3-SK 2010 certificates in https://www.openxades.org is replaced by now and the erroneous one (never used for any other issuance) will be revocated.

The issue of providing randomness in serial number is still under investigation.

Tarvi

kolmapäev, 25. aprill 2012 8:53.43 UTC+3 kirjutas Dimitris Zacharopoulos:

[tarvi....@gmail.com]

This is quite irrelevant to this discussion but shall be clarified anyways.

SK does NOT provide webserver certificates outside Estonia and does not have any contractual parties involved in this business.

However, SK DOES provide different other certificates to larger area, including for example tachograph certificates (Estonia, Latvia, Lithuaia, Finland, Russia) and end-user certificates for Mobile PKI. I presume the latter was topic of interest here as we provide certificates for Omnitel Mobile-ID in Lithuania.

Our CP for Mobile-ID (http://www.sk.ee/en/repository/CP/) says that RA-s involved in certificate provisioning are listed in www.sk.ee Indeed, EMT, Tele2, Elisa and Ominitel are listed both in pages http://www.sk.ee/en/kontakt/customerservice/ and http://www.sk.ee/en/services/other-services/mobiil-id/ so everything shall be sound.

Tarvi

teisipäev, 24. aprill 2012 15:54.34 UTC+3 kirjutas Moudrick M. Dadashov:

[Erwann Abalea]

Le mercredi 2 mai 2012 12:11:08 UTC+2, tarvi....@gmail.com a écrit :
> KLASS3-SK 2010 certificates in https://www.openxades.org is replaced by now and the erroneous one (never used for any other issuance) will be revocated.

The problem has been corrected, good.
You introduced inconsistencies in the certificatePolicies chain, but from previous discussions it seems this is ignored for non-EV certificates.

[Moudrick M. Dadashov]

On 5/2/2012 1:04 PM, tarvi....@gmail.com wrote:
> This is quite irrelevant to this discussion but shall be clarified anyways.
>
> SK does NOT provide webserver certificates outside Estonia and does not have any contractual parties involved in this business.

Again, what matters is your policies/practices for outsourced RA
operations. In my country, where you state you are active, very few
people know about SK. Majority of your customers have no idea about your
CP/CPS relevant to their certificates. It can hardly be called a CA
"business", as your certificates cost 0 (zero!) in whatever currency you
like. How SK returns its costs is a question about transparency.

>
> However, SK DOES provide different other certificates to larger area, including for example tachograph certificates (Estonia, Latvia, Lithuaia, Finland, Russia) and end-user certificates for Mobile PKI. I presume the latter was topic of interest here as we provide certificates for Omnitel Mobile-ID in Lithuania.
>
> Our CP for Mobile-ID (http://www.sk.ee/en/repository/CP/) says that RA-s involved in certificate provisioning are listed in www.sk.ee Indeed, EMT, Tele2, Elisa and Ominitel are listed both in pages http://www.sk.ee/en/kontakt/customerservice/ and http://www.sk.ee/en/services/other-services/mobiil-id/ so everything shall be sound.

1.5.2.1

- MO ensures security with its internal security procedures while
providing the service.

What is the role of your CA in regard to the outsourced RA's security?
Are those RAs audited together with your CA or separately?

2.1.3.

- Ensure the security with its internal security procedures. MO is
responsible for all operations and procedures regarding the production
of the Mobile-ID SIM cards, including the secure key generation on the
Mobile-ID SIM card;

What is the role of your CA in regard to these outsourced CA activities?
Are those outsourced CA activities part og your audit?

3.1.

- The identity of the client shall be verified according to the identity
verification procedure
agreed with the MO.

Can you please explain the details of this identity verification
procedure, specifically how you verify the data that is part of your EE
certificate profile.

4.2.2.

- The private keys of the generated key pair shall be loaded onto the
Mobile-ID SIM card and
the public keys forwarded to the MO by the producer of the Mobile-ID SIM
card.

Sounds like the client key pairs are generated outside of SIM card and
then loaded onto the card. Is this how it works?

- The certificates corresponding to the application are issued by SK
upon automated authenticity
and integrity verification of application data forwarded by MO.

Does this mean that MO is the only one who initiates the certificate
issuance on the CA's side?

4.2.3.

- A separate web application is to be used by the certificate holder for
activating the certificates which aims to enhance the verification of
identity. The certificates can be activated via the web application
using the national ID-card of Republic of Estonia only.

What about those customers who have no Estonian ID card?

I can't find info on how your RA presents your services to public, any
publicly available docs?

And finally you seem to outsource your OCSP services, I can't find info
how this works in terms of security and customer data protection. Are
those outsourced OCSP providers part of your audit?

Thanks,
M.D.

> Tarvi
>
> teisipäev, 24. aprill 2012 15:54.34 UTC+3 kirjutas Moudrick M. Dadashov:

[Kathleen Wilson]

Will that still be the case when NSS is updated to use libpkix for all
certs?

Kathleen

[Erwann Abalea]

I don't know libpkix enough to answer that question, sorry.

[Kathleen Wilson]

On 5/3/12 3:51 AM, Moudrick M. Dadashov wrote:
> Again, what matters is your policies/practices for outsourced RA
> operations.

I have been looking into this, and here is my understanding. Tarvi,
please correct if needed...

The software that the external RAs interface with only allows the
issuance of EID certs. e.g. They can only issue certificates that are
used in electronic ID cards, and those certificates are only usable for
digital signature and for digital identification. There are separate CP
documents regarding procedures/operations for those certs.

This request is to turn on the websites and code signing trust bits.
Only the KLASS3 subCA can sign certificates for organizations (www
server, code signing, digital stamping). The external RAs do not have
any way to access certificate issuance under this subCA. The English
version of the CP regarding organizational certificates issued under the
KLASS3 subCA is http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf.
I do not see anything in this CP that would allow external RAs to issue
certificates under this subCA.
Section 1.3: "The Client Service Point of the SK is
Sertifitseerimiskeskus AS."
Section 2.1.2: "The client service point shall accept applications for
certificates, for suspension, termination of suspension and revocation
of certificates as well as check the correctness and completeness of
these applications. In the performance of all the aforementioned
procedures an employee of the Client Service Point shall identify the
person submitting an application and check their powers and authority."

Therefore, I think that in this case the potential concerns about
external RAs (in regards to Mozilla products and NSS) are addressed
because there is no way for those external RAs to issue certificates
relating to SSL and code signing. Please let me know if I'm missing
something.

Thanks,
Kathleen

[Tarvi Martens]

This is all correct. Issues Moudrick raised are not subject to Mozilla Certificate Policy. I will happy to discuss these issues further on in other forums (like private mail).

Tarvi

[Tarvi Martens]

neljapäev, 10. mai 2012 21:51.09 UTC+3 kirjutas Kathleen Wilson:

[Moudrick M. Dadashov]

On 5/10/2012 9:51 PM, Kathleen Wilson wrote:
> On 5/3/12 3:51 AM, Moudrick M. Dadashov wrote:

>> Again, what matters is your policies/practices for outsourced RA
>> operations.
>
>

> I have been looking into this, and here is my understanding. Tarvi,
> please correct if needed...
>
> The software that the external RAs interface with only allows the
> issuance of EID certs. e.g. They can only issue certificates that are
> used in electronic ID cards, and those certificates are only usable
> for digital signature and for digital identification. There are
> separate CP documents regarding procedures/operations for those certs.
>

This is correct. But if we look at the real practices on one hand and
the fact that the EID CPS' rely on the generic CP/CPS under this Root
program on the other, it's unclear where these practices are taking
their roots?
I believe answers to my questions should clarify this confusion.

> This request is to turn on the websites and code signing trust bits.
> Only the KLASS3 subCA can sign certificates for organizations (www
> server, code signing, digital stamping). The external RAs do not have
> any way to access certificate issuance under this subCA. The English
> version of the CP regarding organizational certificates issued under
> the KLASS3 subCA is http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf.
> I do not see anything in this CP that would allow external RAs to
> issue certificates under this subCA.
> Section 1.3: "The Client Service Point of the SK is
> Sertifitseerimiskeskus AS."
> Section 2.1.2: "The client service point shall accept applications for
> certificates, for suspension, termination of suspension and revocation
> of certificates as well as check the correctness and completeness of
> these applications. In the performance of all the aforementioned
> procedures an employee of the Client Service Point shall identify the
> person submitting an application and check their powers and authority."
>
> Therefore, I think that in this case the potential concerns about
> external RAs (in regards to Mozilla products and NSS) are addressed
> because there is no way for those external RAs to issue certificates
> relating to SSL and code signing. Please let me know if I'm missing
> something.
>

For a typical (commercial or enterprise) CA this probably could be the
only conclusion. But again, this case IMO is not a standard one, in fact
this is a new category of CA that has its own underlying, if you will,
philosophy and operational model.

Unless "half pregnancy" is accepted with this Root program, I suggest to
listen to CA's answers first.

Thanks,
M.D.


> Thanks,
> Kathleen

[Kathleen Wilson]

On 5/14/12 8:33 AM, Moudrick M. Dadashov wrote:
> On 5/10/2012 9:51 PM, Kathleen Wilson wrote:
>> On 5/3/12 3:51 AM, Moudrick M. Dadashov wrote:
>>> Again, what matters is your policies/practices for outsourced RA
>>> operations.
>>
>> I have been looking into this, and here is my understanding. Tarvi,
>> please correct if needed...
>>
>> The software that the external RAs interface with only allows the
>> issuance of EID certs. e.g. They can only issue certificates that are
>> used in electronic ID cards, and those certificates are only usable
>> for digital signature and for digital identification. There are
>> separate CP documents regarding procedures/operations for those certs.
>>
>
> This is correct. But if we look at the real practices on one hand and
> the fact that the EID CPS' rely on the generic CP/CPS under this Root
> program on the other, it's unclear where these practices are taking
> their roots?
> I believe answers to my questions should clarify this confusion.
>
>

>> <snip>

>>
>> Therefore, I think that in this case the potential concerns about
>> external RAs (in regards to Mozilla products and NSS) are addressed
>> because there is no way for those external RAs to issue certificates
>> relating to SSL and code signing. Please let me know if I'm missing
>> something.
>>
> For a typical (commercial or enterprise) CA this probably could be the
> only conclusion. But again, this case IMO is not a standard one, in fact
> this is a new category of CA that has its own underlying, if you will,
> philosophy and operational model.
>
> Unless "half pregnancy" is accepted with this Root program, I suggest to
> listen to CA's answers first.
>

Moudrick,

My apologies, but I am not understanding. Are you implying that this CA
does not follow their CP/CPS? If yes, do you have evidence to
substantiate this claim?

I normally don't ask reviewers to explain their line of questioning, but
I am not following in this case. I am not understanding the concern that
you are raising, and I am not seeing the relevance. Please help me
understand...

Exactly which questions do you think still need to be answered regarding
the external RAs who can issue EID certificates?

And how are those questions relevant to Mozilla's CA Certificate Policy?
http://www.mozilla.org/projects/security/certs/policy/

Thanks,
Kathleen

[Moudrick M. Dadashov]

On 5/14/2012 7:39 PM, Kathleen Wilson wrote:

> On 5/14/12 8:33 AM, Moudrick M. Dadashov wrote:
>> On 5/10/2012 9:51 PM, Kathleen Wilson wrote:
>>> On 5/3/12 3:51 AM, Moudrick M. Dadashov wrote:
>>>> Again, what matters is your policies/practices for outsourced RA
>>>> operations.
>>>
>>> I have been looking into this, and here is my understanding. Tarvi,
>>> please correct if needed...
>>>
>>> The software that the external RAs interface with only allows the
>>> issuance of EID certs. e.g. They can only issue certificates that are
>>> used in electronic ID cards, and those certificates are only usable
>>> for digital signature and for digital identification. There are
>>> separate CP documents regarding procedures/operations for those certs.
>>>
>>
>> This is correct. But if we look at the real practices on one hand and
>> the fact that the EID CPS' rely on the generic CP/CPS under this Root
>> program on the other, it's unclear where these practices are taking
>> their roots?
>> I believe answers to my questions should clarify this confusion.
>>
>>

>>> <snip>

>>>
>>> Therefore, I think that in this case the potential concerns about
>>> external RAs (in regards to Mozilla products and NSS) are addressed
>>> because there is no way for those external RAs to issue certificates
>>> relating to SSL and code signing. Please let me know if I'm missing
>>> something.
>>>
>> For a typical (commercial or enterprise) CA this probably could be the
>> only conclusion. But again, this case IMO is not a standard one, in fact
>> this is a new category of CA that has its own underlying, if you will,
>> philosophy and operational model.
>>
>> Unless "half pregnancy" is accepted with this Root program, I suggest to
>> listen to CA's answers first.
>>
>
>

> Moudrick,
>
> My apologies, but I am not understanding. Are you implying that this
> CA does not follow their CP/CPS? If yes, do you have evidence to
> substantiate this claim?
>
> I normally don't ask reviewers to explain their line of questioning,
> but I am not following in this case. I am not understanding the
> concern that you are raising, and I am not seeing the relevance.
> Please help me understand...
>

Kathleen, let's see those questions again:

1. What is the role of your CA in regard to the outsourced RA's

security? Are those RAs audited together with your CA or separately?

2. What is the role of your CA in regard to these outsourced CA
activities? Are those outsourced CA activities part of your audit?

3. Can you please explain the details of this identity verification

procedure, specifically how you verify the data that is part of your EE
certificate profile.

4. Sounds like the client key pairs are generated outside of SIM card

and then loaded onto the card. Is this how it works?

5. Does this mean that MO is the only one who initiates the certificate

issuance on the CA's side?

6. How customers activate their certificates if they have no Estonian ID?

7. How your RA presents your services to public, any publicly available
docs?

It's about outsourced RA-CA relationship, identity verification, and
probably we call it "business practices".
Please feel free to filter out any of the above if you think is irrelevant.

> Exactly which questions do you think still need to be answered
> regarding the external RAs who can issue EID certificates?

1-5 and 7.

> And how are those questions relevant to Mozilla's CA Certificate Policy?
> http://www.mozilla.org/projects/security/certs/policy/
>

Those questions IMO are directly related to the Root under this
inclusion request and have common CP/CPS.

[Tarvi Martens]

> > dev-security-pol...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-security-policy

Let me explain structure of SK's CP-s and CPS. We have common CPS for
all certification services and different CP for each certification
service.
When assessing a particular certification service, a combination of
CPS and relevant CP clauses shall be combined together whereas CP
clauses can override CPS ones.

Certification service relevant to Mozilla policy is "Certificate
Policy of Organisation Certificates" available at
http://www.sk.ee/upload/files/Asutuse_CPv2_2_EN.pdf. Neither in this
document nor in the CPS (http://www.sk.ee/en/repository/CPS/) there is
no word about outsourced RA services.

Moudrick's questions are targeted at different certification service/
CP about end-user Mobile-ID certificates NOT relevant to Mozilla
policy. I would be more than happy to discuss these questions but
rather in different form/forum.

Tarvi

[Tarvi Martens]

We found out that we can introduce randomness in serial number after
CA software upgrade only. We commit doing this in few months time as
it is not trivial.

Tarvi


On May 2, 1:11 pm, tarvi.mart...@gmail.com wrote:
> KLASS3-SK 2010 certificates inhttps://www.openxades.orgis replaced by now and the erroneous one (never used for any other issuance) will be revocated.

[Kathleen Wilson]

On 4/5/12 2:23 PM, Kathleen Wilson wrote:
> SK (Certification Centre, legal name AS Sertifitseerimiskeskus) has

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

Thank you to all of you who have reviewed and commented on this request

from Sertifitseerimiskeskus.

Here is the current status of this discussion.

1) There is one open action item:

ACTION SK: Make sure there is at least 20 bits of entropy to new
end-entity certificates.

SK has committed to making this change, and we will track it in the bug.


2) There was discussion between Tarvi (representing SK) and Moudrick
about SK's CP for Mobile certificates. Tarvi explained that there are no
outsourced RAs allowed for the SSL and Code Signing services. The CP/CPS
documents for the different types of certificates are available on SK's
website, and confirm this.

I did not see how the discussion about the outsourced RAs for the mobile
ID certs (digital signature and identification) were relevant to this
root inclusion request, so I took the discussion offline between Tarvi
and Moudrick. As a result of that discussion Tarvi said that he plans to
update the Mobile-ID specific CP to reflect where there are differences
in certificate activation. I do not plan to track this as an action
item, because it does not impact how SK issues certificates for websites
and code signing.

If there are no further comments/questions about this request from SK,
then I will close this discussion, recommend approval in the bug, and

track the action item (entropy in end-entity certs) in the bug.

Thanks,
Kathleen

[Moudrick M. Dadashov]

Hi Kathleen,

just a short reminder, I'm still waiting SK to answer these questions:

1. RA-CA transparency, I believe the relationship between the CA and an
outsourced RA needs to be transparent regardless of the type of
certificates. This CA has created an unknown precedent where it
functions as an independent entity under its **own** CP/CPS that is in
my opinion too far from those of CA's. Is this a relevant issue here?
You know my opinion, would you mind to hear what others think?

2. OCSP delegation. I'm still waiting SK to answer how their outsourced
OCSP works:
SK:
I do not understand the question. What do you mean by "delegating OCSP
to third parties" ?
M.D.:
Delegating OCSP to third parties means a business case/practice where a
CA presents its OCSP service to relying parties indirectly. The relying
party A gets the OCSP service of the CA B through an independent entity C.

Looks like the CA has no clue who's representing it's OCSP services. The
practice of outsourcing OCSP service IMO needs to be disclosed in CA's
CP/CPS .

3. And finally, the CA is a part of a larger multinational
(telecom-banking) group (with a questionable reputation and business
practices) and that was the reason of taking the discussion off the list.
I understand the sensitivity of the issue however the CA must clearly
demonstrate that it is not part of a corruption based business model.
Most probably this is out of scope of this request, however I will
continue my own investigation of specific cases. In the meantime I'm
still waiting the CA to provide me with an appropriate contact person
for further discussions on these specific cases.

My recommendation would be: on hold until the CA clarifies the pending
questions.

Thank you.
M.D.

[Tarvi Martens]

Here are answers to Moudrick's questions:

1. Although completely not relevant to Mozilla's policy: the CP/CPS of Omnitel is required to be compatible with SK's CP/CPS and it actually is.

2. SK provides OCSP service by terms and conditions well stated in http://www.sk.ee/upload/files/General%20Conditions%20of%20%20Service%20Contract%20valid%20from%2001_09_2011.pdf. We obviously cannot prevent for some of our OCSP clients to further relay the service. If someone does it then it shall provide relevant terms and conditions of this relying service.

3. Moudrick is provided with e-mail address of our CEO.

Tarvi

[Tarvi Martens]

Here are answers to Moudrick's questions:

1. Although completely not relevant to Mozilla's policy: the CP/CPS of Omnitel is required to be compatible with SK's CP/CPS and it actually is.

2. SK provides OCSP service by terms and conditions well stated in http://www.sk.ee/upload/files/General%20Conditions%20of%20%20Service%20Contract%20valid%20from%2001_09_2011.pdf. We obviously cannot prevent for some of our OCSP clients to further relay the service. If someone does it then it shall provide relevant terms and conditions of this relying service.

3. Moudrick is provided with e-mail address of our CEO.

Tarvi

neljapäev, 26. juuli 2012 3:04.12 UTC+3 kirjutas Moudrick M. Dadashov:

[Kathleen Wilson]

On 7/30/12 5:53 AM, Tarvi Martens wrote:
>
> Here are answers to Moudrick's questions:
>
> 1. Although completely not relevant to Mozilla's policy: the CP/CPS of Omnitel is required to be compatible with SK's CP/CPS and it actually is.
>
> 2. SK provides OCSP service by terms and conditions well stated in http://www.sk.ee/upload/files/General%20Conditions%20of%20%20Service%20Contract%20valid%20from%2001_09_2011.pdf. We obviously cannot prevent for some of our OCSP clients to further relay the service. If someone does it then it shall provide relevant terms and conditions of this relying service.
>
> 3. Moudrick is provided with e-mail address of our CEO.
>
> Tarvi
>
> neljapäev, 26. juuli 2012 3:04.12 UTC+3 kirjutas Moudrick M. Dadashov:
>> Hi Kathleen,
>>
>>
>>
>> just a short reminder, I'm still waiting SK to answer these questions:
>>
>>

>> <snip>
>>
>> M.D.:
>>


Moudrick,

Do you have follow-up questions to the answers that Tarvi provided?
If not, I'd like to close this discussion.

Kathleen

[Moudrick M. Dadashov]

Hi Kathleen

On 8/7/2012 1:31 AM, Kathleen Wilson wrote:
> On 7/30/12 5:53 AM, Tarvi Martens wrote:
>>

>> Here are answers to Moudrick's questions:
>>
>> 1. Although completely not relevant to Mozilla's policy: the CP/CPS
>> of Omnitel is required to be compatible with SK's CP/CPS and it
>> actually is.

I'm in the process of collecting just the opposite evidence how your
outsourced RA functions. I'm going to send it to your CEO.
Again, the relevancy is simple - at least common root to be short..

>>
>> 2. SK provides OCSP service by terms and conditions well stated in
>> http://www.sk.ee/upload/files/General%20Conditions%20of%20%20Service%20Contract%20valid%20from%2001_09_2011.pdf.
>> We obviously cannot prevent for some of our OCSP clients to further
>> relay the service. If someone does it then it shall provide relevant
>> terms and conditions of this relying service.
>>

My question was if SK outsources its OCSP services and how. The document
above doesn't mention that and according to your answer I understand SK
has no such practice. Right after this I've requested relevant info from
a third party. I hope it should arrive soon.

>> 3. Moudrick is provided with e-mail address of our CEO.
>>

Yes, thanks, Tarvi. I'm in touch with your CEO and preparing evidences
of controversial business practices that SK is part of. Again this takes
time because of info needed from third parties.

Thanks.
M.D.

>> Tarvi
>>
>> neljapäev, 26. juuli 2012 3:04.12 UTC+3 kirjutas Moudrick M. Dadashov:
>>> Hi Kathleen,
>>>
>>>
>>>
>>> just a short reminder, I'm still waiting SK to answer these questions:
>>>
>>>

>>> <snip>
>>>
>>> M.D.:
>>>
>
>
> Moudrick,
>
> Do you have follow-up questions to the answers that Tarvi provided?
> If not, I'd like to close this discussion.
>

[Kathleen Wilson]

Hi Moudrick and Tarvi,

Have the appropriate steps been taken so that a resolution to this issue
will be reached?

This is a good time to make sure the issue is addressed, or at least
that the appropriate discussions and actions have been set into motion.

On the one hand, the Juur-SK root certificate is already included in
NSS, so it is a good thing to update NSS with the newer root certificate.

I would like to close this discussion and move forward with approving
this request.

Kathleen

[Moudrick M. Dadashov]

Hi Kathleen,

I'm waiting for SK to:

1. comment on how their CP/CPS mandated procedures in reality do not work.
2. and answer my problematic OCSP and RA outsourcing policy questions.

please feel free to move forward according to your own conformance
criteria. I'll continue until SK clarifies all my questions though.

You deserve a big Thanks from SK though :)

Thanks,
M.D.

On 8/21/2012 11:10 PM, Kathleen Wilson wrote:
> On 8/6/12 4:52 PM, Moudrick M. Dadashov wrote:

> Hi Moudrick and Tarvi,
>
> Have the appropriate steps been taken so that a resolution to this
> issue will be reached?
>
> This is a good time to make sure the issue is addressed, or at least
> that the appropriate discussions and actions have been set into motion.
>
> On the one hand, the Juur-SK root certificate is already included in
> NSS, so it is a good thing to update NSS with the newer root certificate.
>
> I would like to close this discussion and move forward with approving
> this request.
>

[Kathleen Wilson]

On 4/5/12 2:23 PM, Kathleen Wilson wrote:
> SK (Certification Centre, legal name AS Sertifitseerimiskeskus) has

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

> SK is a commercial CA, covering the Baltic region (Estonia,
> Lithuania, Latvia). SK is Estonia's primary certification

> authority, providing certificates for authentication and
> digital signing to Estonian ID Cards. 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 (e.g. Police).
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=624356
>
> And in the pending certificates list here:
>
http://www.mozilla.org/projects/security/certs/pending/#Sertifitseerimiskeskus

>

All,

I apologize for my delay in getting back to this. I got sidetracked on
some other work and am now trying to get caught up.

To summarize this discussion, there have been concerns raised about SK's
OCSP and RA practices for the mobile certificates that they issue. These
certificates are for digital signature and identification, and are not
relevant to the websites and code signing trust bits that have been
requested.

During the course of this discussion it was implied that SK does not
follow their CP/CPS mandated procedures for their mobile certificates.
Even though this is not directly relevant to the requested trust bits,
if there is evidence that the CP/CPS for any of the certificates
chaining up to this root are not followed, then that would need to be
considered. However, this discussion has been open for several months
now, and I have not seen evidence to show that SK does not follow their
CP/CPS for certificates that they issue.

The published audit statements say: "The company’s information system,
organization and work methods comply with documented Certification
Practice Statement to significant extent."

Therefore, I view this particular issue to be closed as far as Mozilla
is concerned.


There is one remaining action item resulting from this discussion...

ACTION SK: Make sure there is at least 20 bits of entropy in new
end-entity certificates.

On May 23 the representative of SK stated: "...we can introduce

randomness in serial number after CA software upgrade only. We commit
doing this in few months time as it is not trivial."

Given the timing, I ask that a representative of SK provide an update to
this action item before I close this discussion.

Kathleen

[Tarvi Martens]

Hello,

SK has successfully tested a new version of CA software producing random number in the SerialNo field. Yet, this version is not in production and will not be until our new root certificate is distributed to all browsers. In other words - we have internal readiness to start operating from new root and commit NOT to issue any certificate from new CA with sequential SerialNo.

Tarvi

[Tarvi Martens]

Hello,

SK has successfully tested a new version of CA software producing random number in the SerialNo field. Yet, this version is not in production and will not be until our new root certificate is distributed to all browsers. In other words - we have internal readiness to start operating from new root and commit NOT to issue any certificate from new CA with sequential SerialNo.

Tarvi


esmaspäev, 10. september 2012 23:24.48 UTC+3 kirjutas Kathleen Wilson:

[Kathleen Wilson]

On 4/5/12 2:23 PM, Kathleen Wilson wrote:
> SK (Certification Centre, legal name AS Sertifitseerimiskeskus) has
> applied 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.
>
> SK is a commercial CA, covering the Baltic region (Estonia, Lithuania,
> Latvia). SK is Estonia's primary certification authority, providing
> certificates for authentication and digital signing to Estonian ID
> Cards. 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 (e.g. Police).
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=624356
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Sertifitseerimiskeskus
>

> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=526096
>


Thanks again to those of you who have reviewed and commented on this
request.

I am now closing this discussion, and I will post a summary of this
request and my recommendation for approval in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=624356

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen