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
>
>
>
>

Received on Saturday, 1 February 2014 00:04:28 UTC