Another question is what implementations could do and should do. A conforming encryption implementation MUST send one or the other, but I don’t think a conforming decryption implementation MUST check and error out if one or the other is missing. This would most likely be an explicit check that the decryption side goes out of its way to do given that the fields are optional and it must be prepared for their absence. Given that, the encryption side might get away with leaving them both out most of the time.
I haven’t implemented this in my library, but I’d probably allow them both to the absent on the decryption side and check for one or the other on the encryption side, perhaps allowing an override if you want them both empty. LL > On Sep 1, 2025, at 12:31 PM, Laurence Lundblade <[email protected]> > wrote: > > 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] _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
