We could just shift the key length up in to the algorithm identifier, like
with the other KDF-based algorithms ("ECDH-ES-128"). Or maybe this argues
more for making dkLen explicit.
On Fri, Jul 19, 2013 at 1:54 PM, Jim Schaad <[email protected]> wrote:
> Richard,****
>
> ** **
>
> You still need to address the case of using ECDH-ES plus a KDF to get the
> CEK directly. I.e. not using a KEK step.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email protected]]
> *Sent:* Friday, July 19, 2013 10:26 AM
> *To:* John Bradley
> *Cc:* Jim Schaad; Mike Jones; [email protected]
>
> *Subject:* Re: [jose] 192 bit AES keys****
>
> ** **
>
> I wasn't saying that it should be a separate parameter. It's just not
> necessary in a lot of cases. If you have a 16-octet value in
> "encrypted_key", then you don't need to specify the key length; you could
> just say "AES-GCM", and the implementation would know it was AES-128-GCM
> based on the length of the key. Worse, as it is, there can be conflict.
> What should an implementation do with "enc":"A128GCM" with a 32-octet
> "encrypted_key"? Use the first 16 octets? The last? Reject?****
>
> ** **
>
> OTOH, for the cases where a KEK is derived, you do need to specify a key
> length for the KEK. So you could either do (1) "ECDH-ES+AES-KW" with a
> "dkLen" parameter (as in PKCS#5), or (2) "ECDH-ES+A128KW". If I were
> designing from clean slate, I would prefer #1, but I can live with #2.****
>
> ** **
>
> PROPOSAL: Remove key lengths in cases where it's not required ("A*GCM",
> "A*KW", "A*GCMKW"), since the length of the key will be clear from the
> "encrypted_key" value (or for "dir", from provisioning). Leave them in the
> "alg" values, since you need to specify key length there.****
>
> ** **
>
> PROS: ****
>
> -- Mitigate combinatorial explosion (don't need one identifier per key
> type)****
>
> -- Avoid conflict issues****
>
> -- Save 3 octets if you don't care about being pretty ("AGCM" instead of
> "A128GCM", though I would prefer "AES-GCM") ****
>
> -- Parallelism with the JWS algorithms (e.g., "HS256"), which don't
> specify key length****
>
> ** **
>
> CONS: ****
>
> -- Requires existing implementations to support additional algorithm
> identifiers (note: doesn't preclude supporting the old algorithm
> identifiers!)****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Jul 19, 2013 at 1:13 PM, John Bradley <[email protected]> wrote:**
> **
>
> +1 I don't think taking the length out of the algorithm and making it a
> separate parameter is a good way to go.****
>
> ** **
>
> On 2013-07-19, at 1:11 PM, "Jim Schaad" <[email protected]> wrote:***
> *
>
>
>
> ****
>
> We need to keep key lengths in algorithm ids for the purpose of key
> derivation. Additionally there would need to be some way to signal the key
> length to the system when doing key generation****
>
> ****
>
> i.e. you would need to change****
>
> jose.SetCEKAlgorithm(“AES128”) to****
>
> jose.SetCEKAlgoirthm(“AES”, 128)****
>
> ****
>
> jim****
>
> ****
>
> ****
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, July 19, 2013 9:47 AM
> *To:* John Bradley
> *Cc:* Mike Jones; [email protected]
> *Subject:* Re: [jose] 192 bit AES keys****
>
> ****
>
> Or we could just remove the key lengths from the algorithm IDs altogether
> ;) They really don't add any value.****
>
> ****
>
> On Thu, Jul 18, 2013 at 6:17 PM, John Bradley <[email protected]> wrote:**
> **
>
> I am OK with registering the 192 bit versions.
>
> Sent from my iPhone****
>
>
> On Jul 18, 2013, at 5:17 PM, Mike Jones <[email protected]>
> wrote:****
>
> Richard had previously requested that we register algorithm identifiers
> for AES using 192 bit keys. As he previously pointed out, “It seems like
> if we're going to support AES, then we should support AES. Every AES
> library I know of supports all three key lengths, so it's not like there's
> extra cost besides the registry entry.” (I’ll note that we already have
> algorithm identifiers for the “mid-size” HMAC and signature functions
> “HS384”, “RS384”, and “ES384”.)****
>
> ****
>
> I heard no objections at the time. I’m therefore thinking that we should
> register algorithm identifiers for these key sizes as well. Specifically,
> we would add:****
>
> “A192KW”, “ECDH-ES+A192KW”, “A192GCMKW”, “PBES2-HS256+A192KW”,
> “A192CBC-HS384”, and “A192GCM”. Support for these algorithms would be
> optional.****
>
> ****
>
> What do people think?****
>
> ****
>
> -- 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****
>
> ** **
>
> ** **
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
