Seems to me that the example is wrong. Section 6.1.2 text is very clear, explicit and unambiguous.
If the salt and the KDF Context Information Structure are both empty, there’s not much point in the HKDF and you should use 6.1.1 Direct. In this example Party U/V Other is not empty, so the Context Information Structure is not empty (see “apu_other” and “apv_other”), but there are no nonces in it. In theory the salt could have been conveyed out-of-band in the example, but I doubt it because I assume the example verifies and there’s no place where the salt shows up in the JSON. I suspect the requirement for a salt or nonce is some defense in depth security. It doesn’t seem necessary unless the key material is poor. LL > On Jun 22, 2025, at 8:37 AM, Nate Jones (Windows Security) > <[email protected]> wrote: > > Hi COSE WG, > > I am reading through the COSE RFCs and there is an inconsistency I want to > dig into. > > RFC 9053 6.1.2 states: >> Either the "salt" parameter for HKDF (Table 9) or the "PartyU nonce" >> parameter for the context structure (Table 10) >> MUST be present (both can be present if desired). The value in the >> "salt"/"nonce" parameter can be generated >> either randomly or deterministically. The requirement is that it be a unique >> value for the shared secret in question. > > However, example "hmac-sha-256-08.json" from the Github-Examples repo > provides an example of "direct+HKDF-SHA-256" without providing either a > PartyU nonce or a salt: > https://github.com/cose-wg/Examples/blob/master/hkdf-hmac-sha-examples/hmac-sha-256-08.json > > Along the lines of the Github example, RFC 9053 5.1 discusses that a salt or > PartyU nonce may not be required in certain cases: >> When using a good random shared secret of the correct length, the extract >> step can be skipped. > ... >> The extract step cannot be skipped if the secret is not uniformly random > > So I'm curious: > * Is Section 6.1.2 incorrect and it is OK to use "direct+HKDF-SHA-256" > without a salt/PartyU nonce as long as your input secret is "uniformly > random" as described in section 5.1? > * Or is section 6.1.2 correct and you "MUST" always have a salt or PartyU > nonce, and hmac-sha-256-08.json is non-compliant with the COSE RFC? > > Or am I missing that the hmac-sha-256-08.json example is actually using a > pre-shared salt/nonce value here, making it compliant with the RFC? > > Appreciate your insights here, > Nate Jones > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
