Maybe that is the way to go then: In http://tools.ietf.org/id/draft-ietf-jose-json-web-algorithms simply state there that the CIK is
CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255] CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255] Similar for SHA512. General rule: use a digest that produces enough or more bits as needed for the cik or cek. NOTE (non normative) that this happens to be the same as the concat KDF as defined in NIST.800-56A for the given bit lengths Axel 2012/10/29 Mike Jones <[email protected]> > > The "PB" in PBKDF2 is "Password Based". This and related KDFs generate keys from passwords rather than other keys, and so are not applicable for this use case. > > For lack of a commonly implemented key-based KDF, we chose a very simple one that only requires support for SHA-256 and SHA-512 to build for our use cases. (Heck, for our use cases, implementations don't even require a loop - just a single hash calculation over the input.) I already know of 5 interoperable implementations at this point. It's just not that hard. > > See the example calculations in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to see how simple it actually is. > > -- Mike
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
