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 protected]]
Sent: Friday, July 19, 2013 11:00 AM
To: Jim Schaad
Cc: John Bradley; Mike Jones; [email protected]
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 protected]<mailto:[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]<mailto:[email protected]>]
Sent: Friday, July 19, 2013 10:26 AM
To: John Bradley
Cc: Jim Schaad; Mike Jones; [email protected]<mailto:[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]<mailto:[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]<mailto:[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]>
[mailto:jose-<mailto:jose->[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
