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

+1 to using the Miller draft.
________________________________
From: Vijay Bharadwaj
Sent: 3/1/2013 9:55 AM
To: Ryan Sleevi; Mark Watson
Cc: public-webcrypto@w3.org Group
Subject: RE: Proposal for key wrap/unwrap (ISSUE-35)

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

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.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, February 25, 2013 1:51 PM
To: Mark Watson
Cc: public-webcrypto@w3.org Group
Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)

On Mon, Feb 25, 2013 at 1:18 PM, Mark Watson <watsonm@netflix.com> wrote:
>
> ________________________________________
> From: Ryan Sleevi [sleevi@google.com]
> Sent: Wednesday, January 16, 2013 7:13 PM
> To: Mark Watson
> Cc: public-webcrypto@w3.org Group
> Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)
>
> Can you provide more design rationale for choosing RSA-KEM, rather
> than the much more widely supported RSA-OAEP (eg: RFC 3560). I don't
> know of a single well-tested, CORRECT implementation of RSA-KEM in the
> popular cryptographic libraries and bindings.
>
> MW> Ryan, we looked in detail at RSA-OAEP key transport and there is an issue in that it does not support payloads of arbitrary size - as required for JWK format payloads. At least not without using RSA keys of arbitrary size.

I'm not sure I follow. In the JOSE space, you perform an RSA-OAEP transport of the CMK, and the CMK protects the message. This is conceptually similar to RSA-KEM.

Certainly, given that OAEP, but not KEM, is supported by JOSE, it seems more in line with your needs?

>
> Do you have any other suggestions for RSA-based key wrap/unwrap ?
>
> We also looked in detail at RSA-KEM and it doesn't look so bad after all. In fact it's much easier to understand than the RSA-OAEP documentation.
>
> ...Mark