Support fully specified algorithms per RFC 9864 - #389
Conversation
simo5
left a comment
There was a problem hiding this comment.
- We canNOT stop offering EdDSA, it will break all users
- I am not even sure we can warn about deprecation, because the new and old algorithms are not wire compatible.
However if those warning come up only when someone intentionally check things rather than by default then it is probably ok.
EdDSA needs to remain enabled, so all the tests that assume it is disabled by default needs to be changed
| 'RS256', 'RS384', 'RS512', | ||
| 'ES256', 'ES384', 'ES512', | ||
| 'PS256', 'PS384', 'PS512', | ||
| 'EdDSA', 'ES256K', 'Ed25519', |
There was a problem hiding this comment.
don't remove EdDSA, even if it is deprecated in theory by the new RFC it will be years before we can actually stop offering it
| self.assertTrue(prikey.has_public) | ||
| s = jws.JWS(payload) | ||
| s.add_signature(prikey, None, {'alg': 'EdDSA'}, None) | ||
| s.add_signature(prikey, None, {'alg': 'Ed25519'}, None) |
There was a problem hiding this comment.
don;t replace tests, keep the old ones and add new ones
| if alg.status == 'prohibited': | ||
| raise InvalidJWAAlgorithm( | ||
| '%s is prohibited and must not be used' % name) | ||
| if alg.status == 'deprecated': |
There was a problem hiding this comment.
I am not sure we should warn in the EdDSA case, while the new RFC is all uppity about using fully qualified algorithms names, there is nothing particularly wrong with the old algorithm, and it will be in use for a long time before consumers will switch (if ever).
There was a problem hiding this comment.
Makes sense, and actually explain the other points. I agree and will change the PR accordingly.
RFC 9864 ("Fully-Specified Algorithms for JOSE and COSE") deprecates
polymorphic algorithm identifiers that do not fully specify the
cryptographic operations to be performed. For JOSE, the polymorphic
"EdDSA" identifier is deprecated in favor of the fully-specified
"Ed25519" and "Ed448" identifiers, which were already registered in
this library.
This commit adds a generic algorithm status infrastructure and marks
EdDSA as deprecated, while keeping it fully functional and enabled
by default to avoid breaking existing consumers.
1. Generic algorithm status infrastructure on JWAAlgorithm:
A reusable 'status' class attribute ('active', 'deprecated', or
'prohibited') and a 'deprecated_by' attribute are added to the
JWAAlgorithm base class. JWA.instantiate_alg() checks these at
algorithm instantiation time: prohibited algorithms raise
InvalidJWAAlgorithm; deprecated algorithms emit a
DeprecationWarning only when default_warn_deprecated_algorithms
is set to True.
This approach was chosen over an EdDSA-specific solution because
RFC 9864 Section 4.4 defines both "Deprecated" and "Prohibited"
statuses for algorithm registries, and future RFCs may deprecate
additional polymorphic identifiers (e.g. ECDH algorithms noted as
polymorphic in Section 6.2).
2. Opt-in deprecation warnings via default_warn_deprecated_algorithms:
A new module-level flag default_warn_deprecated_algorithms
(default: False) controls whether DeprecationWarnings are emitted
for deprecated algorithms. This is disabled by default because
EdDSA remains in wide use and the old and new algorithm identifiers
are not wire-compatible, so warning by default would disrupt
consumers without an immediate migration path. Users who want to
audit their code for deprecated algorithm usage can set this flag
to True.
3. EdDSA remains in JWS default_allowed_algs:
Unlike RSA1_5 in JWE, EdDSA is kept in the default allowed
algorithms list. Removing it would break all existing consumers
and is not warranted given that the algorithm itself is not
cryptographically weak — the deprecation is purely about naming
specificity.
The EdDSA algorithm class (_EdDsa) is marked with
status='deprecated' and deprecated_by='Ed25519 or Ed448', but
remains fully functional for both signing and verification.
Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Rafael Guterres Jeffman <rjeffman@redhat.com>
Add tests for the Ed25519 and Ed448 fully qualified algorithm names introduced by RFC 9864, and for the EdDSA deprecation controlled by the default_warn_deprecated_algorithms flag. test_jws_ed25519 / test_jws_ed448: Verify that the new fully qualified algorithm identifiers can be used to sign and verify JWS tokens end-to-end. test_eddsa_deprecation_warning: Enable default_warn_deprecated_algorithms and verify that instantiating the EdDSA algorithm emits a DeprecationWarning whose message names both EdDSA and its replacements (Ed25519 or Ed448). test_eddsa_no_warning_by_default: Confirm that with default_warn_deprecated_algorithms set to False (the default), using EdDSA does not emit any warning, preserving backward compatibility for existing consumers. Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Rafael Guterres Jeffman <rjeffman@redhat.com>
|
Modified implementation to allow opt-in deprecation warning or EdDSA algorithm. This will allow us to change behavior when non-fully specified algorithms are required, while allowing anyone that want to push adoption to have deprecation warnings. |
|
uhmm where did the support for the new algorithms go ? |
|
Oh NVM I just see that the algorithms were already there ... |
Support for fully specified algorithms is added and deprecated EdDSA algorithms are removed from the allowed algorithms list.
As EdDSA is only deprecated, it is not removed and can be forced back if required (see
test_EdDsa_signing_and_verificationtest).Fixes #386