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
