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

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.


                                                                -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Friday, January 31, 2014 1:39 PM
To: Jim Schaad
Cc: 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 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