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
