RE: Public keys and key usage

Ryan,

 

I agree with you that there is no security benefit to tagging an imported public key with deriveKeys or deriveBytes.  It is strictly an interoperability issue.  Don’t use it in a way that the client on the other side cannot use.

 

If you are going to be consistent, should you not change the RSA algorithms to not enforce the verify and wrapKey usages?  I would consider this to be equivalent in terms of security benefits.

 

Jim

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Monday, November 16, 2015 9:42 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Eric Roman <ericroman@google.com>; public-webcrypto@w3.org
Subject: Re: Public keys and key usage

 

Honest question: What's the use case?

 

It's a public key. Restricting the usage offers no practical security benefit; the key is public.

It's like having an unextractable public key: What would that even mean?

 

I would rather have asymmetry, but with security benefits (such as enforcing usages on private keys, to prevent everything from key disclosure issues to cross-protocol attacks), than to try to offer symmetry of enforcement but with demonstrably circumventable security (export public key, re-import it with new usages)

 

I would argue that it's a bug that publicKeys can be marked non-extractable at all (via importKey/unwrapKey's generic steps), since the asymmetric key types (RSA, ECDSA, ECDH) *always* set the public key to be extractable.

 

On Mon, Nov 16, 2015 at 9:00 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

I totally understand that, however my question would be why cannot not use the deriveKey and deriveBits on the public key in order to restrict their usage as well.  If I send you a public key and you use it to do deriveBits and I don’t support that usage there is no enforcement of that at the present time.

 

I do not object to the fact that a public key can have no usages, just wondering if it really makes sense to say that is the only  valid option.  There would need to be some potential questions dealing with generation of public keys.  

 

I note that there are different usages set for the RSA keys, just not for the key agreement algorithms.

 

Jim

 

 

From: Eric Roman [mailto:ericroman@google.com <mailto:ericroman@google.com> ] 
Sent: Monday, November 16, 2015 1:57 PM
To: Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Cc: Ryan Sleevi <sleevi@google.com <mailto:sleevi@google.com> >; public-webcrypto@w3.org <mailto:public-webcrypto@w3.org> 
Subject: Re: Public keys and key usage

 

I didn't search the mailinglist archives, but here are some relevant discussions on bug threads:

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26413 says that keys should only be allowed to be created with usages that are applicable to the particular algorithm and key type.

 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25820: says that empty usages should not be allowed for private/secret keys, but makes an allowance for public keys.

 

>From the way ECDH defines the deriveKey and deriveBits in terms of the private key (with public key just another parameter of the algorithm) it follows that the private key can have deriveBits/deriveKey usage. But there is no corresponding usage enforced for public keys. The only option then is for their usages to be empty, since invalid usages for keys are not allowed per that first bug.

 

On Mon, Nov 16, 2015 at 1:18 PM, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

Ryan,

I did a quick search of my mail box and could not find the reasoning for forcing public ECDH keys to have an empty usage field.  Was there one or was it never discussed?

Jim