fix(ctap2): pass through arbitrary COSE algorithm identifiers#228
Merged
Conversation
Refactor Ctap2COSEAlgorithmIdentifier from a closed repr(i32) enum into a transparent i32 newtype with associated constants for IANA-registered values. Arbitrary algorithm integers now round-trip through CBOR without being rewritten to a sentinel, so RPs requesting RS256, ES384, PS256 or any future algorithm reach the authenticator unchanged. The -9 codepoint, previously misnamed TOPT for a Trussed-internal use, is renamed to ESP256 per RFC 9864. Closes #148.
msirringhaus
approved these changes
May 27, 2026
Member
Author
|
Thanks! Addressed your comment. |
AlfioEmanueleFresta
added a commit
that referenced
this pull request
May 28, 2026
The credential public key returned by an authenticator was being stored in a closed Rust enum that only handled P-256 and Ed25519. Any credential using RSA, P-384, secp256k1 or a post-quantum algorithm failed to deserialise, so the whole registration response was rejected. Credential public keys are now stored as raw COSE bytes. The platform doesn't crypto-validate them, it forwards them to the relying party, so the closed enum was over-modelling. The authenticator data parser captures the COSE_Key bytes verbatim, preserving the attestation signature's bit-identity for relying-party verification. A small helper reads the mandatory `alg` parameter per WebAuthn L3 §6.5.2, which is what populates `publicKeyAlgorithm` in the JSON response. The previous ES256 fallback when attested credential data was missing is removed because the AT flag MUST be set per CTAP §6.1, and a silent fallback was hiding real protocol violations. The closed enum is still used for the ECDH-ES P-256 key agreement during PIN/UV protocols, where the COSE shape is fixed by spec. Stacked on top of #228.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The COSE algorithm identifier type was a closed enum with a sentinel for unknown values. Any algorithm a relying party requested that wasn't one of three known values got silently rewritten to the sentinel before reaching the authenticator. Authenticators that supported RS256, ES384, PS256, secp256k1 or other algorithms never saw the requested algorithm.
The type now passes arbitrary algorithm identifiers through unchanged, with named constants for the IANA-registered values libwebauthn cares about. The
-9codepoint was historically misnamed for an internal use and is now aligned with RFC 9864 ESP256, the actual IANA assignment.This is a breaking change on the public Rust API.
Closes #148.