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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
