RE: AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long

It's my understanding that you can easily build RFC 5649 given support for AES ECB mode, which I believe there's support for in WebCrypto.

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Friday, January 31, 2014 4:16 PM
To: Mike Jones
Cc: Ryan Sleevi; Jim Schaad; Alexey Proskuryakov; public-webcrypto@w3.org
Subject: Re: AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long



On Fri, Jan 31, 2014 at 4:07 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
Then I'd recommend directly encrypting the JWK with RFC 5649 if you can't use JWE.  In that case, you'd have to figure a way other than JWE header parameters to communicate the key wrapping algorithm used, key size used, etc.

Yes. But unfortunately we're told that the library support for RFC 5649 is not there yet, so at least in this first version of WebCrypto we only have RFC 3394. I don't like it, but there it is.

...Mark




                                                            -- Mike

From: Mark Watson [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
Sent: Friday, January 31, 2014 4:04 PM
To: Mike Jones
Cc: Ryan Sleevi; Jim Schaad; Alexey Proskuryakov; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>

Subject: Re: AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long



On Fri, Jan 31, 2014 at 1:57 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
You could easily use RFC 5649 (Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm) in that circumstance, if you want to directly wrap a JWK with a key wrapping algorithm.  That being said, JWK recommends just using the JWK as a JWE payload to encrypt a JWK, in which case there's no issue.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-key-20#section-6.

The problem with that is that WebCrypto does not support JWE. It would have to be implemented in Javascript and then there is no way to preserve non-extractability: decoding an "Encrypted JWK" with WebCrypto requires two steps, unwrapping the CEK and then using this to unwrap the payload JWK. There is nothing to stop the script using the CEK to decrypt the payload JWK, exposing the key.

...Mark




                                                                -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
Sent: Friday, January 31, 2014 1:39 PM
To: Jim Schaad
Cc: Alexey Proskuryakov; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: AES-KW can only wrap a JWK key if its serialization happens to be 8*n bytes long



On Fri, Jan 31, 2014 at 1:25 PM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
If you are going to fix this for jwk, then you also need to propose a fix
for dealing with raw, spki and pkcs8.

While raw is intended only for secret and thus is likely to be a multiple of
8 bytes in length, there is no future guarantee that this will be true for
all algorithms.  spki is generally only public information and thus would
not probably be encrypted, but it could be.  Pkcs8 definitely is not
guaranteed to be a multiple of 8 bytes in length.

It would be easier just to have the algorithm error in the event that the
input is not a multiple of 8 bytes in length and tell people that they
should be using AES-GCM not AES-KW for those cases.

Jim

+1

As I expressed to Mark when he proposed this solution as well, I definitely do not believe we should be inventing our own padding schemes to deal with this problem.

wrapping JWK is intrinsically messy/ugly, because regardless of whether or not the actual key data itself fits within the wrap size, JWK is "bloaty" enough (base-64 encoded, JSON overhead) that you're likely to blow out/mis-align.

Note that we have the same problem with attempting to use RSA key pairs to wrap keys. RSA-KEM is one possible solution (although not implemented in any major libraries to my knowledge).

Key wrap / unwrap is definitely the ugliest part of the spec. Here are just some of the issues I can think of
- JWK is likely too large for any fixed-length wrapping operations (AES-KW, RSA)
- There's no control for callers to specify whether or not a wrapped key should be extractable or not by the remote party
  - Or what that actually implies / guarantees re: security if there was
- It's a lossy conversion to importing and exporting JWK, if there are attributes not recognized by an implementation attached to the JWK. The same applies to wrap/unwrap
  - If you import a JWK with unrecognized attributes, then export it wrapped, what are the internal contents of that wrapped key? If you allow attribute passthru, what are the security implications of having 'attacker controlled' data as part of the wrapped key? (aka a chosen plaintext attack, effectively)




> -----Original Message-----
> From: Alexey Proskuryakov [mailto:ap@webkit.org<mailto:ap@webkit.org>]
> Sent: Friday, January 31, 2014 12:25 PM
> To: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
> Subject: AES-KW can only wrap a JWK key if its serialization happens to be
> 8*n bytes long
>
> Hi,
>
> I think that there are some omissions in how wrapping a JWK key should
> work. AES-KW in particular requires that input is 8*n bytes long, which is
of
> course not guaranteed with JWK serialization.
>
> Filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24457>, my
> proposal is to pad JWK with spaces for AES-KW. Not sure if any other
> algorithms are similarly affected.
>
> - WBR, Alexey Proskuryakov