As an implementor, I would like to transport multiple symmetric encrypted tokens in less than 2000 bytes.
-- Dick On Jul 19, 2012, at 3:07 PM, Mike Jones wrote: > Matt, if you look at the examples in > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.1 > and > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3.2, > you'll see that the encrypted key occupies more than half the total space of > the JWE in those examples - 342 characters out of 597 and 475 respectively, > to be precise. That's a big deal when operating in space-constrained > environments, such as passing JWTs as URI query parameters - where the total > URL length is often limited to 2048 characters or sometimes less. Plus > there's a significant performance advantage in not having to do the keygen > for the CMK or two encryptions, rather than one. The direct encryption mode > may not be for everyone, but for those that need it, it can be the difference > between meeting space and performance budgets, or not. > > Like John, I'd be glad to talk with you about this in Vancouver. > > Best wishes, > -- Mike > > -----Original Message----- > From: John Bradley [mailto:[email protected]] > Sent: Thursday, July 19, 2012 2:58 PM > To: Matt Miller (mamille2) > Cc: Mike Jones; [email protected] > Subject: Re: [jose] Symmetric encryption and key agreement with and without a > separate CMK > > Sorry I missed your post. I will have a look. > > The idea with 1 is that it allows for the rotation of the key for the stream > cypher without the need to negotiate new shared secrets. > > What bothers you about it. > > We can meet up in Vancouver if you are coming > > John B. > > Sent from my iPad > > On 2012-07-19, at 3:45 PM, "Matt Miller (mamille2)" <[email protected]> > wrote: > >> >> On Jul 18, 2012, at 23:23, John Bradley wrote: >> >>> I agree that is a reasonable approach. >>> >> >> I don't know that I support a). I can't articulate exactly why, other than >> to say it gives me the willies (-: >> >>> In the XMPP example from earlier it was method 2 that they were using for >>> multiple recipients, and that worked because the receiver requested the key >>> from the sender after receiving the message. >>> >> >> That was true, now the CMK is wrapped by a separate "SMK" (Session Master >> Key). See < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 >, which I >> thought I had forwarded to this list (-: >> >>> So 2 may be useful in some multi recipient scenarios though probably not >>> all. >>> >>> John B. >>> >>> On 2012-07-18, at 7:04 PM, Mike Jones wrote: >>> >>>> Hi all, >>>> >>>> I’ve been thinking about two of our open issues, which are closely >>>> related, and am writing to make a proposal to resolve both of them. The >>>> issues are: >>>> >>>> (1) Currently we specify methods for using symmetric keys to key wrap a >>>> separate Content Master Key (CMK), but no means of using the symmetric key >>>> as the CMK directly. Some applications need this functionality, both for >>>> size and for efficiency reasons. >>>> >>>> (2) Currently we specify methods for performing key agreement and directly >>>> using the resulting key as the CMK to perform block encryption, but no >>>> means of using the agreed-upon key to wrap a separate CMK. When doing key >>>> agreement for multiple recipients, a separate CMK is needed. >>>> >>>> Thus, I propose that we define methods for filling in both of the holes >>>> above, as follows: >>>> >>>> (a) Define “alg”:”dir” (direct) to mean that the symmetric key is directly >>>> used as the CMK for the block encryption and integrity calculations, >>>> rather than as a key to wrap the CMK value. >>>> >>>> (b) Define “alg”:”ECDH-ES+A128KW” and “alg”:”ECDH-ES+A256KW” to mean that >>>> the result of the key agreement is respectively used as the 128 bit or 256 >>>> bit AES Key Wrap key to wrap the CMK. >>>> >>>> Doing this will enable all four flavors, whereas we’re currently missing 2 >>>> and 3 below: >>>> 1. The symmetric key used to wrap a separate CMK >>>> 2. The symmetric key used as the CMK >>>> 3. The key agreement result used to wrap a separate CMK >>>> 4. The key agreement result used as the CMK >>>> >>>> I recognize that flavors 2 and 4 are not usable with multiple recipients >>>> when methods such as JWE JSON Serialization are used (which counts on a >>>> common CMK value to enable a common ciphertext value). A note to that >>>> effect would be added to the JWA definitions of “alg”:“ECDH-ES” and >>>> “alg”:”dir” and it would be pointed out in the JWE-JS spec that “alg” >>>> values that utilize a separate CMK MUST be used when the plaintext is >>>> encrypted to multiple recipients. >>>> >>>> Comments? >>>> >>>> -- Mike >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/jose >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >> >> >> - m&m >> >> Matt Miller - <[email protected]> >> Cisco Systems, Inc. >> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
