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> 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]
> > Sent: Friday, January 31, 2014 12:25 PM
> > To: 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
>
>
>
>