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
>
>