Hi Brian, My t_cose implementation allows protected headers with non-AEAD algorithms. I didn’t interpret 9052 as disallowing this even though it is not secure.
Now that you’ve mentioned it here, I will add an overridable error in my implementation to cover this. LL > On Jul 3, 2025, at 10:48 AM, Sipos, Brian J. <[email protected]> wrote: > > WG, > I was looking for, and have failed to find, any requirement in the base COSE > specification [1] that if the protected header map is non-empty the > associated algorithm must support additional authenticated data (AAD). The > non-normative text and examples seem to support this but I don’t see anything > normative around this. Am I just missing something? Or does this seem like > something that deserves a constraint? > > The algorithms I know to not support AAD are: > The direct (-6) <https://www.rfc-editor.org/rfc/rfc9053.html#section-6.1.1> > algorithm > The AES Key Wrap <https://www.rfc-editor.org/rfc/rfc9053.html#section-6.2.1> > family > The RSAES-OAEP <https://www.rfc-editor.org/rfc/rfc8230.html#section-3> family > The AES-CTR <https://www.rfc-editor.org/rfc/rfc9459.html#section-4> and > AES-CBC <https://www.rfc-editor.org/rfc/rfc9459.html#section-5> families > > Brian S. > > [1] https://www.rfc-editor.org/rfc/rfc9052.html > > _______________________________________________ > COSE mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
