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

On Mar 1, 2013, at 12:51 PM, Ryan Sleevi wrote:

> On Fri, Mar 1, 2013 at 12:33 PM, Vijay Bharadwaj
> <Vijay.Bharadwaj@microsoft.com> 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
> base64url)
> - 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.

Ok, I'll have a go at updating the proposal so we can see better what it looks like.

…Mark


>

Received on Friday, 1 March 2013 21:06:04 UTC