Re: ISSUE-35 - Wrap/Unwrap - Why JOSE?

On Fri, Apr 26, 2013 at 2:50 PM, Ryan Sleevi <sleevi@google.com> wrote:

> Out of curiosity when reviewing wrap/unwrap, what technical reasons
> are there to require the format be JOSE?
>

1) This is what was proposed and noone objected
2) There is no existing format for wrapping WebCrypto keys, which have
attributes as well as keying material. So we have to create something new.
Using JOSE, which already has an active community developing it is a much
better choice than rolling our own format in WebCrypto


>
> To put it differently, if it is to be implemented, why can it not be
> treated simply as a specialized form of export+encrypt/decrypt+import,
> where, just like export/import, it takes a key format specifier.
>

Someone objected pretty strongly to the original proposal for overloading
import/export to perform wrap/unwrap as well. I wonder who that was ... ;-)


>
> Recall that we have the key formats "raw", "pkcs8", "spki", and "jwk".
>
> The current wrap/unwrap proposal can ONLY be used with JWKs, which
> creates a divergence from the support for import/export, which
> supports more than just JWK.
>

Right, exactly because there are other formats that can represent raw
keying material, but there aren't existing formats that can securely wrap
the key and attributes together.

Having said that, if you have a use case for wrapping other key formats it
is indeed easy to add that by adding the KeyFormat field.


>
> Was this an arbitrary design decision, or are there some set of
> technical requirements? It seems like the JOSE support (including
> transliteration of JOSE algorithms, params, SPIs, etc) can all be
> handled via polyfill, and that a simple, composed,
> "export-but-then-encrypt" or "decrypt-and-then-import" is more robust
> and useful.
>

At least the mapping of algorithms and other WebCrypto Key attributes
to/from JWK is needed for pure import/export in JWK format.

Regarding the idea that the JWE object could be constructed by Javascript
if the UA provides the necessary primitives: In addition to export+encrypt
and decrypt+import we would also need primitives to wrap and unwrap the
Content Master Key in the JWE structure.

For RSA-OAEP, the wrapping of the CMK is just RSA-OAEP encryption, so that
would be decrypt+import with a key format which is the raw AES CMK bytes.
For AES, the CMK is wrapped using AES Key Wrap, so we would need support
for that. In both cases there needs to be a "usage" for decrypt+import that
is separate from simple decryption, otherwise the key encryption key can be
used to do just a decrypt, rather than a decrypt+import. The problem is
that there is no usage associated with the wrapped CMK. The JS could
decrypt+import the CMK with a usage of decrypt, allowing the JWE payload to
then be decrypted and returned to the script. That might be resolved with
Richard's proposal that the CMK be represented as a JWK object, though I'm
not sure that you don't eventually have the same problem when his recursion
terminates.

For the case where the payload is protected with AES-GCM, there's
additional authentication data to take care of. For the case where the
payload is AES-CBC + HMAC protected then you have to deal with deriving the
encryption key and the MAC key from the Content Master Key.

So, I think it's not possible to do with the present JWE format and even if
that is changed the operation doesn't factor well like this - you end up
with a number of additional primitives and I'm not sure the complexity cost
is worth the gain which is only partial decoupling from JOSE.


>
> For example, the current proposal of wrap/unwrap would effectively
> prevent any security benefits from being realized from applications
> which use PKCS#11, as they make use of PKCS#8 ( see
> http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-30m1-d7.pdf ,
> Section 6.5 ). Likewise, CNG equally supports PKCS#8 ( see
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa376263(v=vs.85).aspx
> ).
>

I'm not sure there *are* any security benefits to be gained from key
wrapping/unwrapping if the WebCrypto attributes - specifically extractable
and usages - are not also protected within the wrapper. In that case you
might as well do decrypt and then import in JS.


> This seems to address at least one criticism, and seems like it would
> greatly reduce the testing overhead.
>
> The question is - will it work, and if not, why not?
>
>