Keep #1; add #3; drop #4; and maybe add #2, but not with an “alg”:”dir” hack.
#4 (key agreement result used as the CMK) saves ~50 chars (or 24 chars?) compared to #3, but only when you have used hundreds of chars (probably doube-base64-encoded) to represent an ephemeral key. Not sure it is worthwhile. The “alg”:”dir” hack is making Richard Barnes’s JSMS ideas look better and better (if it didn’t drop the authenticatedAttributes part of CMS). -- James Manger From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Thursday, 19 July 2012 11:04 AM To: [email protected] Subject: [jose] Symmetric encryption and key agreement with and without a separate CMK 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
