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. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
