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

On 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.

I had proposed separate unwrap/wrap operations and I understood Vijay's proposal to be that those would only generate/accept JWE objects. The import/export operations could remain as they are, supporting a variety of key formats, including JWK. 

> 
> 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 then this would re-combine import/export and wrap/unwrap into a single pair of operations, which always take/generate a JWE object - we would no longer need KeyFormat since this would always be indicated by the enc attribute.

I'd be happy with this as well.

…Mark

> 
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com] 
> Sent: Friday, March 1, 2013 10:26 AM
> To: Vijay Bharadwaj
> Cc: Mark Watson; public-webcrypto@w3.org Group
> Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)
> 
> On Fri, Mar 1, 2013 at 9:53 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
>> I've been looking at key wrap formats lately. My observations based on having maintained crypto APIs:
>> 
>> 1. More wrapping formats means more confusion for developers and pain for vendors.
>> 2. Having wrapAlgorithm be a separate option on the import interface leads to various opportunities for inconsistency, since key wrapping formats include varying amounts of metadata. It is better to have import only deal with formats that are self-describing.
>> 
>> So given that we generally look to JOSE for high-level formats, I'd like to propose using JWE encapsulation for the wrap/unwrap formats, and removing the wrapAlgorithm parameter (and perhaps keyAlgorithm, though this needs more thought) from createKeyImporter in Mark's proposal.
>> 
>> A good starting point seems to be the JWE-protected JWK I-D at 
>> https://datatracker.ietf.org/doc/draft-miller-jose-jwe-protected-jwk/?
>> include_text=1
>> 
>> Three simple example usages of this format to illustrate what I expect will be the most common use cases:
>> 
>> 1. For RSA wrapping: Proceed as in Section 5 of the above I-D. JWE header has alg set to RSA-OAEP, and jwk.kty set to RSA. Most people would likely use enc of A128CBC+HS256 or A128GCM.
>> 
>> 2. For wrapping a key using AES: JWE header has alg set to dir, and 
>> enc as in #1. In this case the jwk element in the header is not 
>> necessary. This allows the use of any authenticated encryption mode, 
>> not just AES key wrap. This seems to be in line with the current 
>> consensus of the cryptographic community - NIST has also Approved the 
>> use of authenticated encryption modes for key wrapping: 
>> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.p
>> df
>> 
>> 3. For working with existing legacy formats such as PKCS#8: JWE header has alg set to dir, and enc set to the appropriate value (e.g. "pkcs-8" in this case).
>> 
>> The nice thing about this mechanism is that it's web-developer friendly, and adds minimal overhead for the case of the legacy formats.
>> 
>> Thoughts? If people are okay with the general idea, I can work with Mark to revise the proposal as per our action item from the last meeting.
> 
> Mark's proposal was an update to the import/export key semantics.
> 
> 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') ?
>

Received on Friday, 1 March 2013 20:47:59 UTC