Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

So it sounds to me like you're in favor of (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK.                                                             --Mike
 Date: Fri, 9 Nov 2012 19:48:32 +0100
From: ignisvulpis@gmail.com
To: michael_b_jones@hotmail.com
CC: jose@ietf.org
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

My suggestion did not change the CMK size. I think it can stay as is.
I think that the concat-kdf is hard to  implement in Firefox/NSS in Javascript if more than one iteration is needed. For the examples in the spec there is no iteration and so there  is no problem.

There is a problem when NIST compliance is really required because CEK and CIK should be computed in one go.
I could live with a NIST-like concat-KDF. I think openid connect even does not need the  optional sender/receiver-ids.

Most important is the randomness of the CMK.

I don't understand the choices you provided. I think the CMK can stay a defined.

// cmk size matters. more bytes give better cik and cek. 
// cmk size does not change encodedEncryptedKeySegment if alg = RSA1_5 or RSA-OAEP

cmk = generateRandomKey(size, enc); 
 // cik and cek have as many bytes as required by enc
(cik,cek) = some-kdf(cmk, otherInfoInput);

Axel

2012/11/9 Michael Jones <michael_b_jones@hotmail.com>

Some working group members, including Axel, James, Matt, and
Richard have expressed dissatisfaction with the use of the Concat KDF to
generate the CEK and CIK when AES CBC is the block encryption algorithm.  Reasons stated are implementation complexity
and possible issues with following the letter of the law of the NIST spec.  Axel and Richard had both written suggesting an
alternative – let the CMK be simply the concatenation of the CEK and the CIK
values.  This is the same approach used
in draft-mcgrew-aead-aes-cbc-hmac-sha2.

I and others had argued against this for size
reasons.  For A128CBC+HS256 this would
increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this
would increase the CMK size from 512 bits to 768 bits.  In the first case, after base64url encoding, one
would expect the extra 128 bits to require about an extra 21 bytes in the JWE.  The interesting fact though, is that when an
RSA algorithm is used to encrypt the CMK, the output size is same as the RSA key
size – in our case, a minimum of 2048 bits. 
Thus, for any combination of “alg”:”RSA1_5” or “RSA-OAEP” and “enc”:”A128CBC+HS256”
or “A256CBC+HS512” there is no actual
size difference in the JWE.  (However
when “alg”:”A128KW” or “A256KW” are used, there would be a size increase of
about 21 or 43 bytes, respectively.)

So I’d like to explicitly ask the working group.  Do you want us to:

(1) Use the concatenation of random CEK and CIK values as
the CMK for AES CBC, resulting in a longer CMK?

(2) Continue to use a KDF to generate the CEK and CIK
from a shorter CMK?

                                                            Thanks all,

                                                            --
Mike

P.S.  A KDF will
still be required for ECDH-ES key agreement. 
I’ll address James’ concerns about our use of Concat in a separate note.

_______________________________________________

jose mailing list

jose@ietf.org

https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose 		 	   		  