Re: Comments on wrap/unwrap

One minor additional comment: Section 14.2.11 (unwrap), Step 8:

   1.

   If Key.extractable<https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-Key-extractable>
is
   not true, terminate this algorithm with an error.

I think might be a cut&paste error from the wrap procedures (step 7 in
14.2.10). There is no "*Key*" (or "*key*" as it should be in 14.2.10) in
the unwrap parameters and unwrapping should be independent of the
extractable parameter of the unwrapping key.

...Mark

On Tue, Jun 11, 2013 at 8:31 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> First, if you receive two versions of this email, they should be
> equivalent. I wrote one last night and now find no sign of it in my email
> system, so this is just a rewrite and retransmission :-(
>
> Second, sorry for the delay in responding on this topic. I was
> unexpectedly out of the office all last week.
>
> I have two comments on the wrap/unwrap implementation in the latest draft.
>
> 1) The procedures refer to the import/export procedures which are
> currently unspecified. For the mechanism to meet the original requirements,
> it's important that import and export respect the attributes of the Key
> (usage, exportable). We need to define mappings for these to/from JWK and
> in the import case the values in the JWK must override those in the import
> method parameters.
>
> 2) There is one important difference between our proposal and what Ryan
> has implemented. We proposed methods that would create/consume a
> JWE-encrypted JWK object in one step. Ryan's proposed methods are simpler,
> more flexible and agnostic as to the wrapping format. Implementing JWE-encrypted
> JWK takes two steps but the JS could also implement other formats.
>
> However, in order to obtain the same properties, in terms of key
> extractibility, as the original proposal it is necessary for any temporary
> keys (such as JWE Content Encryption Key) to be encoded in a way that
> carries attributes. To explain this, first note that Ryan's methods wrap
> and unwrap are effectively compound methods based on the existing encrypt,
> decrypt, import and export: wrap = export+encrypt and unwrap=decrypt+import
> where the intermediate result (at the '+') is not exposed to the script.
>
> To implement JWE-encrypted JWK with these methods we proceed as follows:
>
> Wrap a key X using wrapping key Y:
> (W1) Generate a Content Encryption Key with usage "wrap"
> (W2) Use the CEK with the wrap method to export+encrypt X (using JWK
> format)
> (W3) Use Y and with the wrap method to export+encrypt the CEK
> (W3) Construct the JWE object using the output of steps W2 and W3
>
> Unwrap a key X using wrapping key Y:
> (U1) Extract the wrapped CEK and the payload from the JWE structure
> (U2) Use Y and the unwrap method to decrypt+import the wrapped CEK,
> resulting in a Key object K[CEK] for the CEK
> (U3) Use K[CEK] and the unwrap method to decrypt+import the payload,
> resulting in a Key object for X
>
> Let's suppose the X has extractable=false. In order for this property to
> be maintained it's essential the K[CEK] is not extractible and does not
> have usage "decrypt". Otherwise, it would be possible for the Javascript to
> use K[CEK] to simply decrypt the payload, exposing the key X.
>
> Therefore, the wrapped encoding of the CEK must carry the extractible and
> usages attributes (for cases where the extractibility property of X must be
> maintained).
>
> There are two issues with this:
>
> (A) This is incompatible with the current JWE specification, where the
> wrapped CEK must be encoded as raw octets (though there is a proposal to
> allow JWK here)
>
> (B) If the wrapping key is an RSA key, then the size of the encoded CEK is
> constrained by the size of object this RSA key can encrypt. The only
> attribute-supporting encoding, JWK, has arbitrary size, so it's not clear
> how this constraint works in practice
>
> These issues may both be acceptable. I haven't done the maths for (B) to
> see what the CEK size constraint is for a given RSA key size. If this
> constraint is an issue we would need a more compact key+attributes format
> than JWK.
>
> ...Mark
>