RFC 9864: Fully-Specified Algorithms for COSE support

[kentakayama]

What is the areas you would like to add the new feature to?

Go-COSE Library

Is your feature request related to a problem?

Yes. The feature request is related to a problem.

Since ES256, ES384, ES512, and EdDSA currently supported by this package are now marked as deprecated in RFC 9864, I would like to request support for their replacement algorithms: ESP256, ESP384, ESP512, and Ed25519.
Otherwise, go-cose cannot create a Verifier context for COSE payloads that use these new algorithms.

Adding support for these algorithms should not be difficult, because they simply specify the curve parameter explicitly. This does not conflict with existing code -- for example, the P-256 curve is already used for ES256 even though the algorithm identifier does not specify it in the COSE spec.

However, there is a naming conflict regarding the new Ed25519 algorithm (identifier -19).
The constant name AlgorithmEd25519 is already used for the old EdDSA algorithm (identifier -8), from the time EdDSA support was originally added. Pull Request #160 introduced AlgorithmEdDSA (-8) while preserving the existing AlgorithmEd25519 constant.

What solution do you propose?

• Option A: Introduce a new constant such as AlgorithmEd25519EdDSA, as suggested by @OR13 in the PR, for -19.
  However, users who expect AlgorithmEd25519 to represent the new RFC 9864 Ed25519 algorithm may unintentionally use the old EdDSA (-8) instead.

What alternatives have you considered?

• Option B: Change the value of the existing AlgorithmEd25519 constant from -8 to -19.
  In particular, this would undo the backward‑compatibility considerations that @qmuntal intentionally preserved in the PR.
  This aligns with RFC 9864, but breaks backward compatibility for existing users.
  For example, the deprecated algorithm identifier is still used in tests such as this one.
• Option C: Do not implement the RFC 9864 algorithms at this time.
  This avoids compatibility issues but leaves the package without support for the new recommended algorithms.

I would appreciate guidance on which direction the maintainers prefer, or whether there is an alternative approach that preserves compatibility while still enabling RFC 9864 support.

Any additional context?

No response