FWIW, I wouldn't be all that opposed to adding back in the
authenticatedAttributes.
I also note that this all becomes unnecessary if you can just have one wrapped
key value for many encrypted objects. That works fine in JSMS using detached
encryption info:
[tiny-encrypted-body-1], ..., [tiny-encrypted-body-n],
{
"type": "EncryptedData",
"algorithm": {name:"aes128-gcm", iv:"ZONce...lU-g"}
"keys": /* wrapped keys */
}
On Jul 20, 2012, at 2:56 AM, Manger, James H wrote:
> 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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
