RE: Preserving WebCrypto Key usages in JWK

Ryan - I think your statement that JWK is too tightly bound to JWS and JWE represents a misunderstanding.  The only required JWK fields are the ones representing the actual key material.  Use of any particular metadata fields, including "use" and "alg" is optional.  Furthermore, the set of metadata fields is extensible, so applications can use ones that work well for their application.

As for WebCrypto, there's no reason, for instance, why WebCrypto couldn't define these JWK fields:

AlgorithmIdentifier: a WebCrypto AlgorithmIdentifier structure
KeyUsages: an array of WebCrypto KeyUsage values

If the WebCrypto doesn't believe that "use" and "alg" are a good fit - the solution is simple.  Don't use them.  Use fields that match your application.

If WebCrypto wants a JSON key format (which I believe it does), it would seem silly to invent something just like JWK, but different.  Represent the key values in the same way.  And use the metadata values and representations appropriate for your application.

				-- Mike

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Wednesday, November 13, 2013 12:01 AM
To: Mark Watson
Cc: public-webcrypto@w3.org
Subject: Re: Preserving WebCrypto Key usages in JWK

On Tue, Nov 12, 2013 at 11:51 PM, Mark Watson <watsonm@netflix.com> wrote:
> All,
>
> In bug 23796 [1], I proposed registering new JWK attributes such that 
> a WebCrypto Key can be exported to JWK and this JWK imported back to 
> WebCrypto, without losing information.
>
> It's been requested that a use-case for this, specifically for 
> preserving the WebCrypto usages, be discussed on the list.
>
> So, here is an example. There are others, this is just a simplified 
> one to illustrate the problem.
>
> Suppose client and server have a shared secret, which on the client 
> side is stored as a WebCrypto Key, K1, with K1.extractable = false.
>
> Now suppose I wish to deliver a key, K2, to the client, wrapped with 
> K1, with WebCrypto usage on K2 of "unwrap" and K2.extractable = false.
>
> Now, finally, I will deliver a further key K3, to the client, wrapped 
> with K2. I also have K3.extractable = false.
>
> We have previously agreed that for the case of wrapped keys, there may 
> be policy in the WebCrypto implementation which throws an error on 
> conflict between attributes specified in the wrapped Key and 
> attributes specified in the upwrap method parameters. I'm assuming we 
> don't have to revisit that compromise. In this example such a policy is in place.
>
> Using the existing JWK attributes, the best we can do for K2 is 
> specify use=enc, meaning that the resulting WebCrypto Key has 
> K2.usages = encrypt, decrypt, wrap and unwrap.
>
> This means that K2 can be used to decrypt the wrapped K3, obtaining a 
> copy of K3 outside of the WebCrypto implementation. This directly 
> contradicts the policy that requires K3.extractable = false should be respected.
>
> ...Mark
>
> [1]  https://www.w3.org/Bugs/Public/show_bug.cgi?id=23796

If we look at JWK as being a separate deliverable from JWE/JWS, the usage of "enc" meaning both "enc" and "dec" is, I agree, odd.

Even aside from the wrapping concern (since JOSE has declared that wrapping is a form of encryption, ergo it reuses the "enc" usage), it seems desirable to be able to express the 'direction' of a key to prevent cryptographic misuse, much in the same way that the selection of algorithm prevents misuse.

That is, in the same way that it's 'bad cryptographic' to re-use an AES key with different modes, or to re-use an RSA key with both PSS and SSA (even though there's no 'known' risks, other than the proofs are based on the lack of re-use), it's an equally dangerous proposition to use the same key between two parties for encryption, since unless they agree on the counter/nonce space, they can quickly get in a game of counter-reuse.

A prime example: Two parties using AES-CBC (with or without a MAC, the proof is the same). Even if they use different (randomized) IVs, it increases the chance of IV re-use.

I don't have an answer for you for WebCrypto, because this is definitely an issue with JOSE and its suitability for your specific use case. If anything, this is just another example of JWK being (too) tightly coupled to JWE/JWS.

Received on Wednesday, 13 November 2013 15:05:47 UTC