I don't disagree that the minimum size is a good thing for implementors to do. I just don't think that that restriction is necessary in a formatting document like JW*, since it has no impact on interoperability. At most, it should be RECOMMENDED in the security considerations. It should not be a MUST.
--Richard On Mon, Mar 18, 2013 at 11:28 PM, Mike Jones <[email protected]>wrote: > I believe that the 2048 restriction was motivated by a NIST evaluation > on acceptable key lengths in which the use of 1024 bit RSA keys has already > been deprecated. Eric Rescorla’s presentation to the working group several > IETFs ago specifically recommended this, as well as the other key size > restrictions in JWA. > > At the time, the working group felt that requiring that people use keys of > acceptable lengths for the current cryptographic client for new > applications was a good thing - especially since JWS and JWE have no legacy > applications to support. > > -- Mike > > *From:* Richard Barnes > *Sent:* March 18, 2013 7:31 PM > *To:* Mike Jones > *CC:* [email protected] > *Subject:* Re: [jose] WebCrypto feedback on key wrapping > > 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
