[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

tScheme Technical Manager richard.trevorah at tScheme.org
Wed Nov 5 13:59:39 UTC 2014

Hi Moudrick,


I've always recommended that in a 'pure' QC then only the NR bit should be
set - as per an email I received (via FESA a number of years ago) regarding
situation in Italy:


About your question, also in Italy is strictly forbidden use the key pair
for qualified electronic signature for other purpose. I fully agree with the
technical explanation provided by Adam. I can add that to avoid other uses,
the qualified certificates used for 5.1 electronic signature MUST contains
as "Keyusage" (id-ce 15) only the "nonRepudiation bit on ", and the
"extended key usage" (id-ce 37) must NOT be coded. 

Finally, the qualified CA key pair used to subscribe the end user QC cannot
be used to subscribe other kind of certificates which contain the
"nonRepudiation bit on" .


This was based AIUI on the risk that DS can be used for Authentication and
there is a threat that the nonce to be signed turns out to be a contract!


However, as I said this was 7 years ago so maybe the Italian law has changed
since then!


Although, as it says in RFC3739: " Combining the nonRepudiation bit in the
keyUsage certificate extension with other keyUsage bits may have security
implications depending on the context in which the certificate is to be


Best regards


Richard Trevorah
Technical Manager
tScheme Limited

M: +44 (0) 781 809 4728
F: +44 (0) 870 005 6311


The information in this message and, if present, any attachments are
intended solely for the attention and use of the named addressee(s). The
content of this e-mail and its attachments is confidential and may be
legally privileged. Unless otherwise stated, any use or disclosure is
unauthorised and may be unlawful.

If you are not the intended recipient, please delete the message and any
attachments and notify the sender as soon as practicable



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Moudrick M. Dadashov
Sent: 03 November 2014 22:24
To: Rick Andrews; Eddy Nigg; Brian Smith
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs
in the chain?



EKUs are normally used on EE certificates but QCs profile doesn't use it.

Below is the allowed KeyUsage bit combinations (just in case) for signature


+     -     -

+    +    -
-     +    -
-     +    +
-     -     +
+   +    + 


On 11/4/2014 12:00 AM, Rick Andrews wrote:

Can one of our European colleagues comment about Qualified certs? I seem to
recall that was the sticky point when we last discussed this.




From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Eddy Nigg
Sent: Monday, November 03, 2014 1:45 PM
To: Brian Smith
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs
in the chain?



On 11/03/2014 11:36 PM, Brian Smith wrote:

On Mon, Nov 3, 2014 at 1:32 PM, Eddy Nigg <eddy_nigg at startcom.org> wrote:


On 11/03/2014 11:20 PM, Brian Smith wrote:

2. Require the revocation of any intermediate certificates that do not have
an EKU extension or have an EKU extension with anyExtendedKeyUsage and/or
have an EKU extension with id-kp-serverAuth.

You must be joking, aren't you? :-)


Sorry, I omitted a qualifier: "...that do not conform to the BRs (e.g. are
not technically constrained or publicly audited)."


In other words, require the revocation of CA certificates that do not comply
with the BRs, if issued by a CA for which the BRs apply. Again, this should
already be the case.

Ah, that's something else :-)

Thanks for confirming.





Eddy Nigg, COO/CTO


StartCom Ltd. <http://www.startcom.org> 


startcom at startcom.org


Join the Revolution! <http://blog.startcom.org> 


Follow Me <http://twitter.com/eddy_nigg> 



Public mailing list
Public at cabforum.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141105/09a84d3b/attachment-0003.html>

More information about the Public mailing list