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>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]
> *Sent:* Friday, January 31, 2014 4:04 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 1:57 PM, Mike Jones <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]
> *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>
> 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
>
>
>
>
>