ISSUE-(n+1): Remove silly restriction on key sizes.  We're a formatting
working group, not a crypto parameters working group.

--Richard


On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones <[email protected]>wrote:

>  Given that we require RSA keys to be a minimum of 2048 bits in length,
> there’s no problem wrapping 768 bit keys with OAEP in practice.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf
> Of *Richard Barnes
> *Sent:* Monday, March 18, 2013 4:25 PM
> *To:* [email protected]
> *Subject:* [jose] WebCrypto feedback on key wrapping****
>
> ** **
>
> 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****
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to