I’m (slowly) working through the full purpose of the Context Info Structure.
One effect some of the fields in it can have is to improve the randomness of the CEK output by the KDF. I can’t find statement that this is a purpose of this in RFC 9052 or RFC 9053 or NIST SP800 56A<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf>, but the effect is clearly there. For example, if a nonce is set in the Context Info Structure, it, in turn, goes into the HKDF and the CEK will be perturbed by it. We’ve discussed this here a little. What I’d like to assert is that improving CEK randomness should be a non-goal for COSE going forward. It is a requirement on the implementor that they provide a high quality random CEK. We should not build anything into COSE protocols to compensate for lack of a quality RNG. This is what COSE-HPKE does. See here<https://www.rfc-editor.org/rfc/rfc9180.html#name-bad-ephemeral-randomness>. It says that if you have problems with your RNG, try RFC 8937<https://www.rfc-editor.org/rfc/rfc8937.html>. I like the separation. It makes HPKE itself and its RFC cleaner and neater. This applies not only to the CEK, but generation of the ephemeral part of DH, and even to the original generation of the static part of the DH. This is also parallels my approach for some identifiers in EAT where I explicitly do not use UUIDs<https://www.ietf.org/archive/id/draft-ietf-rats-eat-30.html#name-no-use-of-uuid>. The text in EAT explains that quality RNGs are generally available now. This has passed muster with the current security ADs in EAT IETF LC. Comments? LL
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
