feat(signing): SigningProvider Protocol for KMS-backed signing (#283)

[bokelley]

Closes #283.

Summary

Adds a SigningProvider Protocol so the RFC 9421 request-signing profile no longer requires the private key to live in process memory. Operators using AWS KMS / GCP KMS / Azure Key Vault / Vault Transit can implement the Protocol against their managed key store without forking the signer.

The 2026-04-28 retriage on #283 green-lit this exact scope: Protocol + InMemorySigningProvider + async_sign_request() + pem_to_adcp_jwk + the RFC 8941 key_id escaping fix at signer.py:105.

What's added

• SigningProvider Protocol (src/adcp/signing/provider.py) — async sign(signature_base: bytes) -> bytes, key_id() -> str, algorithm() -> Literal["ed25519", "ecdsa-p256-sha256"]. Contract docstring covers lazy init, public-key type-checking, rotation tripwire, key separation by adcp_use, and fingerprint-logging redaction.
• InMemorySigningProvider — default adapter wrapping the existing in-process path. Validates Ed25519 vs. EC, EC curve = SECP256R1, and key_id non-empty at construction (closes the constructor-time alg/key/curve binding gap flagged in original triage and reaffirmed by security-reviewer this round).
• async_sign_request(provider=...) — async entry point. Shares _prepare_signature with the sync path so both produce byte-identical Signature-Input. Sync sign_request is unchanged.
• pem_to_adcp_jwk(pem, *, kid, purpose, password=None) — derives the public JWK from a PEM. Accepts PKCS#8 private OR SPKI public PEMs (the latter is what KMS adopters typically have, since the private half never leaves the managed store). Output is byte-shape-identical to generate_signing_keypair's public half, so the spec-required adcp_use claim and JWA alg value are correct by construction.
• RFC 8941 §3.3.3 escaping fix (signer.py:_escape_sf_string) — applied to keyid, nonce, tag before interpolation into Signature-Input. Rejects anything outside printable ASCII 0x20-0x7E, including CRLF (HTTP-header-injection vector at non-httpx integrators) and lookalike Unicode quotes (parser-divergence vector against Go/JS verifiers).

Reviewer-flagged items addressed

This PR went through code-reviewer, ad-tech-protocol-expert, and security-reviewer. Their feedback is incorporated:

From	Item	Resolution
code-reviewer	Drop temporal/historical framing in module docstring	Done — "Adapter contract:" header instead.
code-reviewer	Add ECDSA byte-identity test	Done — test_sync_and_async_signature_input_identical_for_es256 (signature value skipped due to random k).
code-reviewer	Rename payload → signature_base on Protocol	Done.
code-reviewer	Match full PEM sentinel -----BEGIN PUBLIC KEY----- instead of substring	Done.
security-reviewer	_escape_sf_string must reject characters outside §3.3.3 grammar	Done — raises ValueError on non-printable-ASCII; tests cover CRLF, NULL, and Unicode quote.
security-reviewer	Move alg/key/curve binding check from sign-time to constructor-time on InMemorySigningProvider	Done — covers Ed25519 vs. EC mismatch and non-SECP256R1 curve.
ad-tech-protocol-expert	Confirm RFC 9421 alg casing, no pre-hash, P1363 encoding, RSA-PSS out of scope, JWK shape parity	All confirmed in code. No spec violations found.

Test plan

• pytest tests/conformance/signing/ — 375 passed, 6 skipped
• 21 new tests in test_signing_provider.py covering: round-trip async sign+verify (ed25519 + es256), sync/async byte-identity (both algs), RFC 8941 escape with " and \, control-char + non-ASCII rejection, pem_to_adcp_jwk shape parity for both algs, SPKI public-PEM acceptance, RSA rejection, alg/key mismatch and wrong-curve rejection
• ruff check — clean on changed files
• mypy src/adcp/signing/ — clean
• black --check — clean on changed files
• Pre-commit hooks pass (black, ruff, mypy, bandit, detect-private-key)
• CI green on PR

Notes

• No spec change required — the Protocol is purely an SDK concern. AdCP already permits any signing path that produces a verifiable RFC 9421 signature against the keys at jwks_uri.
• No KMS adapter shipped in this PR. The Protocol is the integration point; adapter implementations belong in adopter projects (or behind opt-in extras in a follow-up). This matches the reviewer guidance from the original triage.

🤖 Generated with Claude Code