Comments on wrap/unwrap

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