[jose] NIST Concat KDF

["Manger, James H" <[e-mail]>]

JOSE still doesn’t use the NIST 800-56A Concat Key DF as that specification requires.

JWA allows PartyUInfo and/or PartyVInfo to be empty (if apu/apv/epu/epv are absent). That doesn’t comply with 800-56A that says “at a minimum, PartyUInfo shall include IDu, the identity of party U”. 800-56A also says “it is required that identifier for both parties to a key agreement transaction be included in the OtherInfo that is input to the key derivation function”.

800-56A requires that the concatenation AlgorithmID || PartyUInfo || PartyVInfo be unambiguous. It allows two ways to achieve this: pre-define fixed sizes for components; or prefix each component with its length. JWA does neither of these.

Consider two JOSE messages (ignoring some irrelevant base64url encoding):
  { ..., "apu":"JoBeth", "apv":"Anne" } and
  { ..., "apu":"Jo", "apv":"BethAnne" }
JWA implies both use the string "JoBethAnne" in the KDF despite the messages being between different parties, which defeats this part of the Concat KDF design.

JWA explicitly puts the key length and "alg" value into the AlgorithmID field that the KDF uses. However, the "alg" value alone must imply one specific key length for the rest of the JOSE processing to work so including the key length explicitly is redundant.

800-56A is designed to derive integrity and encryption keys together. For instance, it says “AlgorithmID might indicate that bits 1-80 are to be used as an 80-bit HMAC key and that bits 81-208 are to be used as a 128-bit AES key”. JWA does not do this. JWA runs the KDF twice to derive integrity and encryption keys separately.

If we want to use NIST 800-56A Concat KDF then JWA/JWE needs lots of fixes.
If we want a simpler KDF then JWA shouldn’t pretend it is the NIST 800-56A Concat KDF.

--
James Manger