[jose] WebCrypto feedback on key wrapping

[Richard Barnes <[e-mail]>]

On today's call with the W3C WebCrypto working  group, I reported on the
discussion of JOSE key wrapping at the last IETF.  I was asked to relay a
few bits of feedback:

1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of
favor with some parts of the cryptographic community.  People prefer to be
able to use AEAD algorithms for key wrapping, since they are perceived to
be faster and offer a higher level of security than AES-KW. He gave the
example that IEEE 802.1 uses AES CCM.

2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt
wrapped key objects, then we would need something other than OAEP in order
to carry arbitrary-length payloads.  I agreed, and suggested that something
like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed
that KEM is troublesome due to the lack of support by native crypto
libraries.

It seems to me that these comments have impacts on JWE and JWS (pending
ISSUE-2), as well as the wrapping discussion.  The former has more impact
than the latter.

Point number 1 implies that we should offer AEAD for key wrapping in JWE as
well as for wrapped keys.  It seems to me that the simplest approach to
this would be to make the "alg" field contain an object that is
semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For
example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax,
incidentally, is roughly the same form that algorithm identifiers have in
the WebCrypto API.  Note that this type of key wrapping is supported in CMS
by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo
structure.

Point number 2 likely applies for some scenarios of JWE, especially if we
adopt the McGrew approach.  For example, if using HMAC-SHA1 and AES with a
256-bit key, the total key length is 788 bits, which is too long to be
encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve
it.  The best idea I've got is to allow wrapped keys to nest, so that you
can wrap a key inside of another wrapped key.

I will try to take these points into account in my forthcoming key wrapping
draft, and I've filed two issues against JWE to track them.

--Richard