+1
2013/3/19 Mike Jones <[email protected]> > I completely agree that documenting the engineering tradeoffs is in > scope and a worthwhile exercise. The point of my message was simply that > we needn’t “accept the goal that there should be one way of encrypting > keys” without doing this analysis.**** > > ** ** > > I think Matt Miller had it right when he wrote this morning “Personally, > I don't think it's worth discussing this much further without a more > complete counter-proposal on the table”. Should a concrete > counter-proposal to Matt’s draft be written, at that point we could have a > much more concrete discussion.**** > > ** ** > > Cheers,*** > * > > -- Mike*** > * > > ** ** > > *From:* Jim Schaad [mailto:[email protected]] > *Sent:* Tuesday, March 19, 2013 8:17 AM > *To:* Mike Jones; 'Richard Barnes' > > *Cc:* 'James H Manger'; [email protected] > *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows*** > * > > ** ** > > <personal>**** > > ** ** > > The issue has been raised for discussion. I do not believe that > documenting what the extents of the issue are is out of scope of any and > all follow on discussion. Until that has been done it is not possible to > talk about what the costs and benefits are. If you have a full set of > costs and benefits that would be an interesting message to see.**** > > ** ** > > *From:* Mike Jones > [mailto:[email protected]<[email protected]>] > > *Sent:* Monday, March 18, 2013 8:24 PM > *To:* Jim Schaad; Richard Barnes > *Cc:* James H Manger; [email protected] > *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows*** > * > > ** ** > > Since you message appears to take it as given that “there should be only > one way of encrypting keys”, I’ll point out that I don’t think that it’s > reasonable to assume that. JOSE is first and foremost an engineering > exercise, where the cost/benefit generality/complexity tradeoffs matter, > and the goal is a ubiquitously implemented crypto format for the Web that > solves the problems that people actually have, rather than a mathematical > exercise, where the goal is completeness and generality. Complexity is the > enemy of adoption.**** > > **** > > So it’s fair game to ask “What are the costs and benefits of having only > one way to encrypt keys”, versus taking that as a given.**** > > **** > > I happen to personally believe that encrypting a bare symmetric > ephemeral Content Master Key is sufficiently different than encrypting a > key that may be public, private, or symmetric and may have additional > attributes, that it’s at least worth asking the engineering question > whether special-casing the encryption of this bare symmetric ephemeral key > results in engineering benefits.**** > > **** > > Encrypting a key with attributes for storage or dissemination is not the > same kind of operation as wrapping an ephemeral symmetric key to be used > for block encryption. I’m personally fine with this being done > differently. The engineering benefit if we do it differently in the way > that Matt’s draft proposed, at least as I see it, is that we have to invent > nothing new. We already have a great format for encrypting arbitrary data, > and keys with attributes are a whole lot like arbitrary data.**** > > **** > > I respect that some with disagree with my personal view, but I’d also ask > you to respect that the engineering tradeoffs may favor having two ways to > do things that on the surface may seem similar, but are actually fairly > different in nature.**** > > **** > > Best wishes,**** > > -- Mike**** > > **** > > *From:* Richard Barnes > *Sent:* March 18, 2013 7:36 PM > *To:* Jim Schaad > *CC:* Manger, James H, [email protected] > *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows*** > * > > **** > > Well, I got to 788 by doing math incorrectly*. **** > > ** ** > > Mike was correct on the other thread that 768 is the right number. > However, that's still too big for a 1024-bit RSA key and SHA1, since 768 + > 320 = 1088 > 1024. **** > > ** ** > > Regardless, there is clearly an issue here when wrapping a JWK, which is > much larger, possibly containing an RSA key itself. So if we accept the > goal that there should be one way of encrypting keys, then we'll need to > deal with getting around the OAEP size limitations.**** > > ** ** > > --Richard > > * This is why my degree is in mathematics, and not accounting.**** > > On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email protected]> > wrote:**** > > Think in terms of encrypting a JWK directly not an intermediate key.**** > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of* > *** > > > Manger, James H > > Sent: Monday, March 18, 2013 5:17 PM > > To: [email protected]; [email protected] > > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows > > > > Richard, > > > > How do you get a 788-bit key length? > > > > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- > > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 > > bits to 512 bits. > > > > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and > > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. > > > > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. > JWA > > already says RSA key sizes MUST be at least 2048 bits. > > > > This already looks sufficient. > > > > -- > > James Manger > > > > > > > From: [email protected] [mailto:[email protected]] On Behalf > > > Of Richard Barnes > > > Sent: Tuesday, 19 March 2013 10:25 AM > > > Subject: [jose] WebCrypto feedback on key wrapping > > > > > > 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. > > > > > > 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. > > > > > > --Richard > > > > > > >> ---------- > > >> Sent: Tuesday, 19 March 2013 10:23 AM > > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows > > >> > > >> #14: Support longer wrapped keys than OAEP allows > > >> > > >> The use of RSA-OAEP for key wrapping imposes a limit on the length > > >> of the key package being wrapped. With SHA1, this length is N-320, > > >> where N is the length of the RSA modulus. Especially with larger > > >> hash functions, and especially for wrapping private keys, the size > > >> of key packages will be larger than this bound. We should > > >> incorporate a mechanism to accommodate these situations. > > >> > > >> > > >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>**** > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
