Re: Proposal for key wrap/unwrap (ISSUE-35)

On Fri, Mar 1, 2013 at 12:33 PM, Vijay Bharadwaj
<> wrote:
> [Ryan]> Mark's proposal was an update to the import/export key semantics.
> [Ryan]> Do you also see making the proposal that we only support JWK for key import/export? If so, according to the Miller draft (and to JOSE, from the last IETF), only protected keys should be supported. How would you propose to support unprotected/non-JWE-protected keys - which are a valid and important use case? Setting "enc" to "dir" doesn't mean unprotected. Perhaps you meant setting the JWK alg to some form (eg:
> 'pkcs8') ?
> I was proposing we could only support JWE encapsulation for key import/export. The thing that is encapsulated can be JWK or, as in my third example, PKCS#8.
> My understanding of the JWE format is that there are two algorithm-related fields: the alg field which is the method used to encrypt or determine the content encryption key, and the enc field which says how the actual payload is encrypted with the content encryption key (if any). As far as I can tell, setting alg to dir basically means "let the payload be your guide". This is why in the example #2 I was setting alg to dir (since there is no JWE-visible wrapping key) and enc to pkcs-8 (since that should tell the receiver what to do with the payload). If this feel ugly, we could set alg to none for such cases.
> So this naturally accommodates plaintext key import - set alg to dir (or none?) and enc to the encoding format of the key itself (i.e. "jwk" if it's an unprotected JWK, and say "pkcs-7" if it's a PKCS#7 public key).

So there are elements of this that I like:
 - Unifying on JWK resolves the ambiguity of using ArrayBufferView for
import/wrap - instead, a WebIDL dict (with fields presumed to be
equivalent to their JWK JSON equivalent) would be taken.
 - It still provides a support path for 'raw' (non-JWK) keys, with
hopefully minimal wrapping overhead

But there are elements that I'm not thrilled of:
 - The use of base64url throughout JOSE means that existing
convenience methods like window.atob/btoa are of no direct use, and
thus must be wrapped with further helpers (to handle the conversion to
 - Prevents the use of ArrayBufferView, short of the API proposal by
Richard which is to say "Whatever goes" for the fields (which I don't
think is at all desirable, even under this new model)
 - For implementing any existing cryptographic protocols that make use
of key wrapping, it means that the application will now need to
convert back from JWE into their preferred form. Given that no crypto
library natively supports JWE, this essentially means two wasted
conversions from the 'raw' API (browser impl -> raw[browser] ->
JWE[browser] -> JWE[JS app] -> raw[app])

I don't think we can remove KeyAlgorithm, especially in the same
notion as supporting 'raw' key formats, and would have trouble
supporting that, but I agree, this does seem a cleaner wrapping
solution, even with the additional overhead.

Received on Friday, 1 March 2013 20:53:48 UTC