glows in the dark JWEs would be nice to have too.
2013/3/19 Richard Barnes <[email protected]> > I agree that it's a fair question to ask. As I'm writing this key > wrapping document (as requested in Orlando), I'm trying to develop a > comparison of the costs of various wrapping schemes. > > It would be interesting to get feedback on the group as to how you would > measure cost in this case? For example: > -- Which algorithms can/cannot be supported > -- How large the encrypted object is > -- How many encryption formats a JOSE library has to support > > On the latter point, the request to use GCM for key wrapping has gotten me > thinking that perhaps we should just make JWE self-similar, by using a JWE > to wrap the key for a JWE*. That would reduce the number of encryption > code paths from two (JWE, key wrapping) to one (JWE). Again, I'll try to > make a concrete proposal in the forthcoming document. > > --Richard > > > > > On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones > <[email protected]>wrote: > >> 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
