Sertifitseerimiskeskus Root Inclusion Request
Kathleen Wilson
Sertifitseerimiskeskus is the next request in the queue for public
discussion.
Sertifitseerimiskeskus (a commercial CA, covering the Baltic region -
Estonia, Lithuania, Latvia) has applied to add the Juur-SK root
certificate to NSS and enable all three trust bits. This request is
documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=414520
and in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Sertifitseerimiskeskus%20AS
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=382373
Noteworthy points:
* 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 and SSL certificates.
* The CPS and the CPs for all three types of subordinate CAs are
provided in English.
* All three trust bits are requested to be enabled.
** KLASS3-SK CP Section 3.1: The Client and data presented by him are
verified in accordance with the rules set in the document “Terms of
Use for Device Certificates” [6]. The following checks are performed
during certificate application processing: Data about the Client as a
legal person. Personal identity of device administrator and his/her
mandates for applying for the legal person for certificate issuance/
revocation. Ownership of the domain name and/or IP address in case the
device is accessible over public network
*** Comment #9: 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.
** 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.
** Comment #9: SK currently is not issuing code-signing certificates.
Nevertheless, SK itself uses few self-issued code-signing certificates
for its own purposes.
*Test website: https://digidoccheck.sk.ee
* Both CRL and OCSP are provided.
** NextUpdate for the CRL for website certs is 12 hours.
** From the CP for each type of sub CA: The guaranteed frequency of
publication is 12 hours.
* Audits: The report for 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.
This begins the one-week discussion period. After that week, I will
provide a summary of issues noted and action items. If there are no
outstanding issues, then this request can be approved. If there are
outstanding issues or action items, then an additional discussion may
be needed as follow-up.
Kathleen
Eddy Nigg
> As per the CA Schedule at https://wiki.mozilla.org/CA:Schedule
> Sertifitseerimiskeskus is the next request in the queue for public
> discussion.
>
Thanks Kathleen! I have a few questions below:
> ** 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.
Does .X represent a number in case there is more than one person with
the same name?
> 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.
>
Are users able to actually send email through that system with their
esti.ee email address or is this service only for receiving email
messages (forwarded to the real user supplied email address)? What
happens to those messages which don't have any user supplied address? Do
they simply bounce back?
> ** Comment #9: SK currently is not issuing code-signing certificates.
> Nevertheless, SK itself uses few self-issued code-signing certificates
> for its own purposes.
>
In which of the CP/CPSs (and section) provided by the CA is code-signing
issuing and their validation practice listed?
> This begins the one-week discussion period.
>
Thanks.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Eddy Nigg
> 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.
>
>
Another few things. What is the TEST-SK (2002-2012) intermediate CA and
which certificates does it issue? Where is this covered in the CP
statements?
Also the root and intermediate CA certificates have non-repudiation key
usage, I understand that this shouldn't be used for roots.
Kathleen mentioned in the report that there is an OCSP responder a t
http://ocsp.sk.ee. I couldn't find the OCSP URI in the certificates
however. Also it appears that this responder wouldn't function correctly
if the URI would be embedded into the certificates. Is this known to the CA?
Liisa Lukin
Please find answers below:
> Another few things. What is the TEST-SK (2002-2012) intermediate CA and
> which certificates does it issue? Where is this covered in the CP
> statements?
As the name says the TEST-SK issues certificates for testing purposes
which is in practice very rare occasion. It does not have CP.
> Also the root and intermediate CA certificates have non-repudiation key
> usage, I understand that this shouldn't be used for roots.
This issue seems to be matter of taste/discussion. The thinking behind
of this particular case seems to be "the CA cert KU/EKU shall contain
a superset of flags that end/user certificates have". However, it is
there. Is this any problem
> Kathleen mentioned in the report that there is an OCSP responder a thttp://ocsp.sk.ee. I couldn't find the OCSP URI in the certificates
> however. Also it appears that this responder wouldn't function correctly
> if the URI would be embedded into the certificates. Is this known to the CA?
The OCSP URI is not in the certificate for the reason - the access to
OCSP is not entirely free: one needs access certificate for signing
OCSP requests or to have it's IP address enabled for the access. As
some sofware might do automatic OCSP check after discovering this AIA
field, we did not want to trigger this behavior.
Otherwise responder functions OK.
Best Regards,
Liisa Lukin
AS Sertifitseerimiskeskus
Business Development Manager
Liisa Lukin
>
> Thanks Kathleen! I have a few questions below:
>
> > ** 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.
>
> Does .X represent a number in case there is more than one person with
> the same name?
Yes.
> > 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.
> Are users able to actually send email through that system with their
> esti.ee email address or is this service only for receiving email
> messages (forwarded to the real user supplied email address)? What
> happens to those messages which don't have any user supplied address? Do
> they simply bounce back?
The system is only for receiving e-mail. Unregistered addresses just
bounce back.
> > ** Comment #9: SK currently is not issuing code-signing certificates.
> > Nevertheless, SK itself uses few self-issued code-signing certificates
> > for its own purposes.
>
> In which of the CP/CPSs (and section) provided by the CA is code-signing
> issuing and their validation practice listed?
This is covered by common KLASS-SK CP which is generic CP for
"certificates for enterprises".
Kyle Hamilton
1) a CA signed by a root up for inclusion must have a policy related
to the certificates that it can/will issue. If it does not, it's
entirely possible for it to issue any end-entity certificate, valid
for any time period, and since it doesn't have a CP that can be
audited it will never be detected -- and since it chains to a trusted
CA, it will validate. This is a showstopper and earns my 'nay' vote
for inclusion. (Regardless of 'current practice', practice can be
modified later.)
2) More as a matter of curiosity than a major problem with the
submission: Newer versions of Firefox *will* attempt to contact OCSP
if the AIA is set, so your worry is justified. My question, though,
is why do you require access certificates or IP-based enablement to
check the status of a certificate? What is the business reason? (You
may choose not to answer, but I find myself mystified by anything that
would reduce the availability of revocation data.)
-Kyle H
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Eddy Nigg
> As the name says the TEST-SK issues certificates for testing purposes
> which is in practice very rare occasion. It does not have CP.
>
It would be good if you could cover this sub root and its requirements
in the CP/CPS. Except in case the test certificates follow one of the
other procedures.
> This issue seems to be matter of taste/discussion. The thinking behind
> of this particular case seems to be "the CA cert KU/EKU shall contain
> a superset of flags that end/user certificates have". However, it is
> there. Is this any problem
>
The extension has no effect in reality on the correct function of the root.
Eddy Nigg
>> Are users able to actually send email through that system with their
>> esti.ee email address or is this service only for receiving email
>> messages (forwarded to the real user supplied email address)? What
>> happens to those messages which don't have any user supplied address? Do
>> they simply bounce back?
>>
> The system is only for receiving e-mail. Unregistered addresses just
> bounce back.
>
OK, let me question the usefulness for enabling the S/MIME trust bit,
because effectively your users can't actually use, sign and encrypt
their email messages really.
Liisa Lukin
> On 06/17/2009 05:42 PM, Liisa Lukin:
>
> >> Are users able to actually send email through that system with their
> >> esti.ee email address or is this service only for receiving email
> >> messages (forwarded to the real user supplied email address)? What
> >> happens to those messages which don't have any user supplied address? Do
> >> they simply bounce back?
>
> > The system is only for receiving e-mail. Unregistered addresses just
> > bounce back.
>
> OK, let me question the usefulness for enabling the S/MIME trust bit,
> because effectively your users can't actually use, sign and encrypt
> their email messages really.
Sorry for misunderstanding your question regarding eesti.ee email.
Users are able to send email through eesti.ee system.
Additional info you can also read http://www.eesti.ee/portaal/postisysteem.abi
(choose ENG in upper right corner)
Eddy Nigg
The instructions indicate to use the mail server of the ISP for outgoing
mail, not that of eesti.ee. This might be a problem for various mail
servers. Maybe someone with very good knowledge on the subject could
advise on this (e.g. reverse DNS lookup, SPF, etc)?
Basically my concern is, that if the senders or sending of emails are
non-compliant to the standards (and would prevent to receive emails of
your users by servers and clients enforcing compliance), than I'd still
question the usefulness for enabling the S/MIME trust bit. That's
because it's a very specific scenario involving a CA provided (email)
service in a very specific way. I think it should be carefully
established that the service and certification is compliant in order to
be useful.
Liisa Lukin
> Two issues:
>
> 1) a CA signed by a root up for inclusion must have a policy related
> to the certificates that it can/will issue. If it does not, it's
> entirely possible for it to issue any end-entity certificate, valid
> for any time period, and since it doesn't have a CP that can be
> audited it will never be detected -- and since it chains to a trusted
> CA, it will validate. This is a showstopper and earns my 'nay' vote
> for inclusion. (Regardless of 'current practice', practice can be
> modified later.)
We will discuss this topic internally, one option is that we will
delete TEST-SK under JUUR-SK (trusted root). Will inform you about the
decsion next week.
> 2) More as a matter of curiosity than a major problem with the
> submission: Newer versions of Firefox *will* attempt to contact OCSP
> if the AIA is set, so your worry is justified. My question, though,
> is why do you require access certificates or IP-based enablement to
> check the status of a certificate? What is the business reason? (You
> may choose not to answer, but I find myself mystified by anything that
> would reduce the availability of revocation data.)
Reason is that we provide OCSP as priced service.
Liisa Lukin
> >>>> Are users able to actually send email through that system with their
> >>>> esti.ee email address or is this service only for receiving email
> >>>> messages (forwarded to the real user supplied email address)? What
> >>>> happens to those messages which don't have any user supplied address? Do
> >>>> they simply bounce back?
>
> >>> The system is only for receiving e-mail. Unregistered addresses just
> >>> bounce back.
>
> >> OK, let me question the usefulness for enabling the S/MIME trust bit,
> >> because effectively your users can't actually use, sign and encrypt
> >> their email messages really.
>
> > Sorry for misunderstanding your question regarding eesti.ee email.
> > Users are able to send email through eesti.ee system.
> > Additional info you can also readhttp://www.eesti.ee/portaal/postisysteem.abi
> > (choose ENG in upper right corner)
>
> The instructions indicate to use the mail server of the ISP for outgoing
> mail, not that of eesti.ee. This might be a problem for various mail
> servers. Maybe someone with very good knowledge on the subject could
> advise on this (e.g. reverse DNS lookup, SPF, etc)?
>
> Basically my concern is, that if the senders or sending of emails are
> non-compliant to the standards (and would prevent to receive emails of
> your users by servers and clients enforcing compliance), than I'd still
> question the usefulness for enabling the S/MIME trust bit. That's
> because it's a very specific scenario involving a CA provided (email)
> service in a very specific way. I think it should be carefully
> established that the service and certification is compliant in order to
> be useful.
This is up to SMTP server administrators, and no issues so far (system
is working since 2002). How is this relevant to our root inclusion
request ?
Frank Hecker
>> 2) More as a matter of curiosity than a major problem with the
>> submission: Newer versions of Firefox *will* attempt to contact OCSP
>> if the AIA is set, so your worry is justified. My question, though,
>> is why do you require access certificates or IP-based enablement to
>> check the status of a certificate? What is the business reason? (You
>> may choose not to answer, but I find myself mystified by anything that
>> would reduce the availability of revocation data.)
>
> Reason is that we provide OCSP as priced service.
Kyle, didn't we have a similar discussion previously with regard to
another CA? In any case, providing OCSP service is one area where I
think there is a business reason for charging somebody something, since
in the absence of OCSP stapling support the CA has to handle every OCSP
request using its own IT infrastructure. Speaking personally, in the
case of SSL-enabled web sites I think it would make sense for CAs to
make OCSP service free to web site users (which would allow CAs to use
AIA to advertise the service) and then charge the web site's owners
based on the number of OCSP requests processed for a given site.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Eddy Nigg
> Kyle, didn't we have a similar discussion previously with regard to
> another CA? In any case, providing OCSP service is one area where I
> think there is a business reason for charging somebody something,
> since in the absence of OCSP stapling support the CA has to handle
> every OCSP request using its own IT infrastructure. Speaking
> personally, in the case of SSL-enabled web sites I think it would make
> sense for CAs to make OCSP service free to web site users (which would
> allow CAs to use AIA to advertise the service) and then charge the web
> site's owners based on the number of OCSP requests processed for a
> given site.
Assuming that relying parties are required to check the validity of
certificates before relying on a certificate, the CA is required to
provide reasonable means for checking revocation thereof. IMO it doesn't
make sense to charge or provide dedicated OCSP services (except in cases
where OCSP services isn't offered out-of-bound for specific CA issued
certificates, but as a proxy). In this case I rather suspect that the
OCSP responder isn't compliant with embedded URI discovery and it's
technically correct not to embed it.
Of course we are coming here and again to the same core issue of CRL
versus OCSP, where NSS (respectively Firefox) doesn't have the means to
check CRLs without the interaction of the user (and who does that anyway?).
Ian G
> On 06/19/2009 05:11 PM, Frank Hecker:
>> Kyle, didn't we have a similar discussion previously with regard to
>> another CA? In any case, providing OCSP service is one area where I
>> think there is a business reason for charging somebody something,
>> since in the absence of OCSP stapling support the CA has to handle
>> every OCSP request using its own IT infrastructure. Speaking
>> personally, in the case of SSL-enabled web sites I think it would make
>> sense for CAs to make OCSP service free to web site users (which would
>> allow CAs to use AIA to advertise the service) and then charge the web
>> site's owners based on the number of OCSP requests processed for a
>> given site.
>
> Assuming that relying parties are required to check the validity of
> certificates before relying on a certificate, the CA is required to
> provide reasonable means for checking revocation thereof.
Sure, but that's a contract issue between its relying parties and the
CA. It isn't anything that Mozilla needs to worry about.
What can go wrong? Relying parties can't access without paying? That
sounds a bit ludicrous, because no CA has the ability to take pennies
for a check. Obviously, they charge more to the server certificate
owner for OCSP, etc.
> IMO it doesn't
> make sense to charge or provide dedicated OCSP services (except in cases
> where OCSP services isn't offered out-of-bound for specific CA issued
> certificates, but as a proxy). In this case I rather suspect that the
> OCSP responder isn't compliant with embedded URI discovery and it's
> technically correct not to embed it.
>
> Of course we are coming here and again to the same core issue of CRL
> versus OCSP, where NSS (respectively Firefox) doesn't have the means to
> check CRLs without the interaction of the user (and who does that anyway?).
It would guess that the technical issue of Firefox wanting to use OCSP
rather than CRLs is likely enough to provide the incentives needed. I
doubt there needs to be a policy or root decision here. The CA will
figure it out given its market place and the grumbles of the relying
parties.
iang
Eddy Nigg
>> Assuming that relying parties are required to check the validity of
>> certificates before relying on a certificate, the CA is required to
>> provide reasonable means for checking revocation thereof.
>
>
> Sure, but that's a contract issue between its relying parties and the
> CA. It isn't anything that Mozilla needs to worry about.
>
I'm not so sure about that. Mozilla provides a tool which is
specifically geared for the usage with SSL certificates. At court I'd
claim that my browser didn't show a certificate revoked. In this respect
Mozilla is at least party somehow.
>
> It would guess that the technical issue of Firefox wanting to use OCSP
> rather than CRLs is likely enough to provide the incentives needed. I
> doubt there needs to be a policy or root decision here. The CA will
> figure it out given its market place and the grumbles of the relying
> parties.
I have no idea what CAs think as such....I'd be afraid without any
revocation mechanism....but we've discussed that too already. Guess
there is nothing new under the sun ;-)
Kathleen Wilson
and posted your comments in this discussion. My interpretation and
summary of the discussion so far is as follows:
1) There is a question as to whether the email (S/MIME) trust bit
needs to be enabled. Liisa, are certificates chaining to this root
used for signing and encrypting email?
2) The concern was raised that the TEST-SK intermediate CA is not
covered by a documented and audited CP. The options appear to be
either to delete TEST-SK or to add/create a CP for it that will be
part of future audits. Pending decision and action by
Sertifitseerimiskeskus.
3) A question was asked about there being an OCSP responder, but the
OCSP URI is not in the certificate. The reason is that this CA offers
OCSP as a priced service. Precedence has been set for accepting CAs
that only provide CRL and not OCSP. I think that this CA basically
falls into that category.
Please let me know if I’ve missed anything.
Thanks,
Kathleen
Liisa Lukin
> 1) There is a question as to whether the email (S/MIME) trust bit
> needs to be enabled. Liisa, are certificates chaining to this root
> used for signing and encrypting email?
The answer is no. CA is not used for S/MIME.
> 2) The concern was raised that the TEST-SK intermediate CA is not
> covered by a documented and audited CP. The options appear to be
> either to delete TEST-SK or to add/create a CP for it that will be
> part of future audits. Pending decision and action by
> Sertifitseerimiskeskus.
We will delete TEST-SK, but it will take some time to complete this
action.
> 3) A question was asked about there being an OCSP responder, but the
> OCSP URI is not in the certificate. The reason is that this CA offers
> OCSP as a priced service. Precedence has been set for accepting CAs
> that only provide CRL and not OCSP. I think that this CA basically
> falls into that category.
I have to clear up here that for the web certificates we provide only
CRL, no OCSP at all. We provide OCSP (as priced service) for personal
certificates.
Sorry for misunderstandings.
What's next now? Is TEST-SK a showstopper? Is there a timeline how
quickly we have to fix it? Is there any other problems?
Kathleen Wilson
your feedback in this discussion. Your participation in this process
is greatly appreciated.
The results of this discussion are as follows.
1) The Email trust bit will not be enabled. There do not appear to be
any remaining concerns in regards to enabling the Websites and Code
Signing trust bits.
2) The TEST-SK intermediate CA is not covered by a documented and
audited CP.
Action Item: Sertifitseerimiskeskus to delete the TEST-SK intermediate
CA.
I will note this action item in the bug, and track this action item to
completion. My recommendation is that we move forward with the
approval process for this request, but that I do not create the NSS
bug to make the actual changes until Sertifitseerimiskeskus has
completed this action item.
3) It has been clarified that OCSP is not provided for website
certificates, and that only CRL is provided for website certificates.
There is a priced OCSP service provided for personal certificates, but
this is irrelevant because the email trust bit will not be enabled.
This concludes the first public discussion about
Sertifitseerimiskeskus’ request to add one new root CA certificate to
the Mozilla root store, as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=414520
I will post the action item, a summary of the request, and my
recommendation for approval in the bug.
Eddy Nigg
> 2) The TEST-SK intermediate CA is not covered by a documented and
> audited CP.
>
> Action Item: Sertifitseerimiskeskus to delete the TEST-SK intermediate
> CA.
>
I guess you meant revoke it. Revocation should be perhaps confirmed in
the CRL prior to inclusion.