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

Sun Nov 9 03:49:35 MST 2014

Hi Richard,

The /KeyUsage/ bit combinations in my email were taken from "Draft ETSI 
EN 319 412-2 V2.0.7 (2014-02)" which, as you know well, is based on ETSI 
TS 102 280.

The section 5.4.3 of the Draft addresses the security implications 
including /KeyUsage/ for QCs, which IMO is exactly what you have 
correctly pointed out (see "*Security note:*").

Hope this helped.

Thanks,
M.D.

On 11/5/2014 3:59 PM, tScheme Technical Manager wrote:
>
> 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 used."
>
> Best regards
>
> Richard
>
> ------------------------------------
> Richard Trevorah
> Technical Manager
> tScheme Limited
>
> M: +44 (0) 781 809 4728
> F: +44 (0) 870 005 6311
>
> http://www.tscheme.org
> ------------------------------------
>
> 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
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] (Eventually) requiring id-kpServerAuth for 
> all certs in the chain?
>
> Rick,
>
> 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 certs:
>
> NR DS KE/KA
>
> +     -     -
>
> + +    -
> -     +    -
> -     +    +
> -     -     +
> +   +    +
>
> Thanks,
> M.D.
>
> 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.
>
>     -Rick
>
>     *From:*public-bounces at cabforum.org
>     <mailto: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
>     *Cc:* CABFPub
>     *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 <mailto: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.
>
>     -- 
>
>     Regards
>
>     Signer:
>
>     	
>
>     Eddy Nigg, COO/CTO
>
>     	
>
>     StartCom Ltd. <http://www.startcom.org>
>
>     XMPP:
>
>     	
>
>     startcom at startcom.org <xmpp:startcom at startcom.org>
>
>     Blog:
>
>     	
>
>     Join the Revolution! <http://blog.startcom.org>
>
>     Twitter:
>
>     	
>
>     Follow Me <http://twitter.com/eddy_nigg>
>
>
>
>
>     _______________________________________________
>
>     Public mailing list
>
>     Public at cabforum.org  <mailto:Public at cabforum.org>
>
>     https://cabforum.org/mailman/listinfo/public
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141109/6390fdc3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3653 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20141109/6390fdc3/attachment-0001.bin 