Skip to content

tls: emit context-bearing webpki unsupported-signature errors#6436

Closed
caniko wants to merge 1 commit into
libp2p:masterfrom
caniko:tls/unsupported-signature-context
Closed

tls: emit context-bearing webpki unsupported-signature errors#6436
caniko wants to merge 1 commit into
libp2p:masterfrom
caniko:tls/unsupported-signature-context

Conversation

@caniko

@caniko caniko commented May 12, 2026

Copy link
Copy Markdown

Description

Replace webpki::Error::UnsupportedSignatureAlgorithm and
UnsupportedSignatureAlgorithmForPublicKey (parameterless variants) with the
context-bearing UnsupportedSignatureAlgorithmContext /
UnsupportedSignatureAlgorithmForPublicKeyContext forms at every return site
in transports/tls/src/certificate.rs.

Today, a libp2p TLS handshake that rejects a certificate's signature scheme
surfaces a bare enum variant with no payload — diagnosing why two peers fail
to handshake requires reproducing the error path in a debugger. With this
change, the error carries the offending signature-algorithm OID (and the
public-key-algorithm OID where applicable), so logs and bug reports can name
the algorithm directly.

The signature_algorithm_id bytes follow the convention already used by
rustls-webpki's own population sites and the rustls_pki_types::alg_id::*
constants: the DER contents of the AlgorithmIdentifier SEQUENCE (OID
followed by parameters), without the outer SEQUENCE tag/length.

The *Context variants were added in rustls-webpki v0.103.9, so the
crate's dep range is tightened from "0.103" to "0.103.9" and the
workspace lockfile is bumped accordingly.

Notes & open questions

  • SUPPORTED_SIGNATURE_ALGORITHMS is hardcoded to mirror what
    signature_scheme() already accepts (RSA-PKCS1 SHA-{256,384,512},
    ECDSA-SHA-{256,384}, RSA-PSS-SHA-{256,384,512}, Ed25519). ECDSA-P521 and
    Ed448 are intentionally excluded because they're explicitly rejected
    downstream in verify_signature.
  • The two regression tests assert the error variant and verify the OID
    payloads are non-empty; they don't decode the OIDs back to dotted form,
    because the wire format is the same opaque byte slice that webpki and
    rustls consumers compare against alg_id::* constants.

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

Replace the parameterless UnsupportedSignatureAlgorithm{,ForPublicKey}
variants with the *Context forms carrying the offending signature
algorithm id (and public-key algorithm id where applicable), so
verification failures surface the actual OID rather than a bare enum.

The *Context variants were added in rustls-webpki v0.103.9; bump the
crate's webpki dep range from "0.103" to "0.103.9" and update the
workspace lockfile so default builds resolve a compatible version.

Adds regression tests:
- `nistp384_sha256` now asserts the returned error is
  `UnsupportedSignatureAlgorithmContext` and carries a non-empty
  `signature_algorithm_id` plus the supported-algorithm list.
- `signature_scheme_mismatch_carries_both_oids` exercises
  `verify_signature` against a scheme that does not match the cert's
  public key and asserts both algorithm-id payloads.
@jxs

jxs commented May 12, 2026

Copy link
Copy Markdown
Member

Hi, I addressed this in #6355

@caniko caniko closed this May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants