Enforce alg header placement in protected map when AAD is supported

[aahajj]

What is the areas you experience the issue in?

Go-COSE Library

What is not working as expected?

Currently, users can mistakenly place the alg header parameter in the unprotected map even if the algorithm in use supports Additional Authenticated Data (AAD). I would suggest to introduce a check that enforces alg to be in the protected map for all algorithms that support AAD. This would improve compliance with RFC 9052 and reduce the likelihood of user errors. This would align with the way the crit header is already enforced to reside in the protected header.

RFC 9052 states :

This header parameter MUST be authenticated where the ability to do so exists. This support is provided by AEAD algorithms or construction (e.g., COSE_Sign and COSE_Mac0). This authentication can be done either by placing the header parameter in the protected-header-parameters bucket or as part of the externally supplied data.

The current algorithms in COSE that do not support AAD are:

• The direct (-6) algorithm
• The AES Key Wrap family
• The RSAES-OAEP family
• The AES-CTR and AES-CBC families

What did you expect to happen?

Introduce a check that enforces alg to be in the protected map for all algorithms that support AAD.

How can we reproduce it?

No response

Describe your environment

No response

What is the version of your Go-COSE Library?

Current Main: a633822