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: [email protected]
To: [email protected]
CC: [email protected]
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 <[email protected]>
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
[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
