Subject: [jose] 192 bit AES keys

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jul 2013 21:17:16 +0000

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 18 Jul 2013 21:24:13 +0000

> "A192KW", "ECDH-ES+A192KW", "A192GCMKW", "PBES2-HS256+A192KW", "A192CBC-HS384", and "A192GCM".  Support for these algorithms would be optional.

+1

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: John Bradley <[email-masked]>
Date: Thu, 18 Jul 2013 18:17:56 -0400

I am OK with registering the 192 bit versions. 

Sent from my iPhone

> On Jul 18, 2013, at 5:17 PM, Mike Jones <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 12:47:18 -0400

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-masked]> 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****
>
> ** **
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 19 Jul 2013 10:11:08 -0700

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-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Friday, July 19, 2013 9:47 AM
To: John Bradley
Cc: Mike Jones; [email-masked]
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.

Sent from my iPhone

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 13:14:01 -0400

Ok, fine.  :)

I can buy that it needs to be there for key derivation in the combined
cases (e.g., ECDH-ES+A128GCM).  The need to specify key length at
generation time is not a JOSE issue.

On Fri, Jul 19, 2013 at 1:11 PM, Jim Schaad <[email-masked]> wrote:

> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, July 19, 2013 9:47 AM
> *To:* John Bradley
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [jose] 192 bit AES keys****
>
> ** **
>
> ;)  They really don't add any value.****
>
> ** **
>
> On Thu, Jul 18, 2013 at 6:17 PM, John Bradley <[email-masked]> wrote:**
> **
>
> Sent from my iPhone****
> On Jul 18, 2013, at 5:17 PM, Mike Jones <[email-masked]>
> wrote:****
>
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/jose****
>
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: John Bradley <[email-masked]>
Date: Fri, 19 Jul 2013 13:13:34 -0400

+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-masked]> 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
>  
> jose.SetCEKAlgorithm(“AES128”) to
> jose.SetCEKAlgoirthm(“AES”, 128)
>  
> jim
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
> Or we could just remove the key lengths from the algorithm IDs altogether ;)  They really don't add any value.
>  
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 13:25:42 -0400

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-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
>  *Richard Barnes

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 19 Jul 2013 10:54:29 -0700

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-masked]] 
Sent: Friday, July 19, 2013 10:26 AM
To: John Bradley
Cc: Jim Schaad; Mike Jones; [email-masked]
Subject: Re: [jose] 192 bit AES keys

PROS: 

-- Avoid conflict issues

CONS: 

 

+1   I don't think taking the length out of the algorithm and making it a
separate parameter is a good way to go.

jim

On Thu, Jul 18, 2013 at 6:17 PM, John Bradley < <mailto:[email-masked]>
[email-masked]> wrote:

Sent from my iPhone

On Jul 18, 2013, at 5:17 PM, Mike Jones <
<mailto:[email-masked]> [email-masked]> wrote:

What do people think?

                                                            -- Mike

_______________________________________________
jose mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/jose>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 14:00:00 -0400

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-masked]> wrote:

> Richard,****
> CEK directly.  I.e. not using a KEK step.****
>
> ** **
>
> Jim****
>
> ** **
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Friday, July 19, 2013 10:26 AM
> *To:* John Bradley
> *Cc:* Jim Schaad; Mike Jones; [email-masked]
>
> "encrypted_key"?  Use the first 16 octets?  The last?  Reject?****
>
> ** **
>
> designing from clean slate, I would prefer #1, but I can live with #2.****
>
> ** **
>
> "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****
>
> "A128GCM", though I would prefer "AES-GCM") ****
>
> -- Parallelism with the JWS algorithms (e.g., "HS256"), which don't
> specify key length****
>
> ** **
>
> CONS: ****
>
> identifiers!)****
> On Fri, Jul 19, 2013 at 1:13 PM, John Bradley <[email-masked]> wrote:**
> **
>
> separate parameter is a good way to go.****
>
> ** **
>
> On 2013-07-19, at 1:11 PM, "Jim Schaad" <[email-masked]> wrote:***
> *
>
>
>
> ****
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Jul 2013 18:15:47 +0000

To me, the proposal to change the algorithm identifiers this late in the game doesn't seem to meet the criteria that Karen expressed in her note "thoughts on deployed code and breaking changes<http://www.ietf.org/mail-archive/web/jose/current/msg02542.html>":

These specifications have been evolving for a long time. I am sure that they could be improved in a myriad of ways, but at this point, without a strong rationale and a ground swell of working group support, we should work to complete what we have. Any major refactoring or new functionality should be deferred as future work.

Yes, we could have used different algorithm identifiers or refactored them in various ways, but those that we have already have been shown to work, and work well in practice.  There is no functionality gap that needs to be corrected by changing them.

I'll plan to add the 192 bit AES identifiers as you requested Richard, at which point I think we should call it good.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Friday, July 19, 2013 11:00 AM
To: Jim Schaad
Cc: John Bradley; Mike Jones; [email-masked]
Subject: Re: [jose] 192 bit AES keys

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Friday, July 19, 2013 10:26 AM
To: John Bradley
Cc: Jim Schaad; Mike Jones; [email-masked]<mailto:[email-masked]>

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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> wrote:

jim

From: [email-masked]<mailto:[email-masked]> [mailto:jose-<mailto:jose->[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Friday, July 19, 2013 9:47 AM
To: John Bradley
Cc: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] 192 bit AES keys

On Thu, Jul 18, 2013 at 6:17 PM, John Bradley <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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".)

What do people think?

                                                            -- Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 14:25:11 -0400

We do have to fix interop issues, though.  So if we're going to keep key
lengths in the identifiers, we need to say what an implementation should do
when there's a conflict, probably in JWA.
"""
It is possible for an algorithm that specifies a key length is used in a
JOSE object that provides an explicit key for the algorithm (e.g., an
encrypted key in JWE).  In such cases, if the length of the provided key is
not the same as the key length specified in the algorithm, then a recipient
MUST reject the JOSE object as invalid.
"""

Color me unenthusiastic about the combinatorial explosion here.  How would
you even support an algorithm with a truly variable key length (e.g.,
Blowfish)?  It's also unclear to me why there's a requirement being levied
here that's not being levied on JWS.  This just seems like more "la la la
we've always done it this way", waltzing into a solution that is
unnecessarily difficult to maintain.

On Fri, Jul 19, 2013 at 2:15 PM, Mike Jones <[email-masked]>wrote:

>  To me, the proposal to change the algorithm identifiers this late in the
> game doesn’t seem to meet the criteria that Karen expressed in her note “thoughts
> on deployed code and breaking changes<http://www.ietf.org/mail-archive/web/jose/current/msg02542.html>
> ”:****
>
> ** **
>
> These specifications have been evolving for a long time. I am sure that
> they could be improved in a myriad of ways, but at this point, without a
> strong rationale and a ground swell of working group support, we should
> work to complete what we have. Any major refactoring or new functionality
> should be deferred as future work.****
>
> ** **
>
> Yes, we could have used different algorithm identifiers or refactored them
> in various ways, but those that we have already have been shown to work,
> and work well in practice.  There is no functionality gap that needs to be
> corrected by changing them.****
>
> ** **
>
> I’ll plan to add the 192 bit AES identifiers as you requested Richard, at
> which point I think we should call it good.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *Sent:* Friday, July 19, 2013 11:00 AM
> *To:* Jim Schaad
> *Cc:* John Bradley; Mike Jones; [email-masked]
>
> more for making dkLen explicit.****
>
> ** **
>
> On Fri, Jul 19, 2013 at 1:54 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> Richard,****
>
>  ****
>
> *Cc:* Jim Schaad; Mike Jones; [email-masked]****
>
>