On Thu, Jul 03, 2025 at 07:35:00PM +0000, Sipos, Brian J. wrote: > Ilari, > Thanks for confirming this. It does appear that the section on AES-KW > in RFC 9053 [2] includes the statement "The protected header bucket > MUST be empty." and two families defined in RFC 9459 [3] have similar > statements. But the direct (-6) algorithm makes no such statement nor > does the RSAES-OAEP family [4]. So it seems desirable but > inconsistent.
It seems that RFC 9052 requires protected to be empty for both direct and RSA-OEAP: >From section 8.5.1 (Direct Encryption): "The 'protected' field MUST be a zero-length byte string unless it is used in the computation of the content key." The conditional is not satisfied, so this requires empty protected. >From section 8.5.3 (Key Transport): "A set of key transport algorithms is defined in [RFC8230]." "The "protected" field MUST be a zero-length byte string." The only even potentially applicable algorithm for the first statement is RSAES-OAEP. Looking at RFC 8152, it makes the same statements, but does not have any examples of Key Transport. And I found the following from section 8.5.2 (Key Wrap): "The 'protected' field MUST be a zero-length byte string if the key wrap algorithm is an AE algorithm." There are algorithms that do not satisfy the conditional: Any AEAD-type algorithm may be used for Key Wrap (even if this is poorly supported). Then all the stuff that can protect headers (Direct Key Agreement, Key Agreement with Key Wrap and AEAD) does not have similar requirements. All this does have consistent interpretation that protected is required to be empty unless there is some mechanism to protect it, but this general requirement is not stated anywhere. > Does this rise to the level of an errata for the general discussion of > protected header in RFC 9052? I think having specific guidance there > would help understanding for those who don't have a huge background in > this ecosystem. This might not rise to level of errata, but it would be nice to discuss the underlying principles instead of leaving those implict, so that future extensions know what pitfalls to avoid — even if it takes adding a new mode to run into potential issues. An example of things going wrong is the implicit requirement for all symmetric encryption to be authenticated, and then RFC 9459 adding algorithms breaking that requirement, opening an attack. COSE-HPKE adds a new mode, but that mode is fully capable of protecting headers, so no problems here. -Ilari _______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
