fix(schema): refuse private key material in cnf.jwk

[imran-siddique]

Closes GHSA-vc4p-h84j-7qxj. Reproduced against current main before changing anything.

The gap

RFC 8747 defines cnf as a confirmation key: the public half, carried so a verifier can bind the record to the key that signed it.

models.TrustRecord already knew that. It refuses d, p, q, dp, dq, qi and k via _JWK_PRIVATE_PARAMS, with the comment "cnf.jwk is a public proof-of-possession key".

But the verification path validates against schema/trace-claim.json, not the model. The schema's jwk block constrained only the kty/crv/x/y shapes through two if/then entries; everything else fell through additionalProperties. So a Trust Record carrying its own private key validated cleanly and verify_record accepted it.

The rule existed, and only in the half that verification does not call.

Why it matters even with no attacker

There is no attacker step here. This is a producer mistake the format did not defend against. What makes it worth fixing rather than documenting is that the consequence is durable: the record is signed, self-authenticating, and typically anchored. Once it is out, the key is out, and the only remedy is to revoke the identity.

sign.sign_record could never produce this, because it builds cnf from key_to_jwk, which returns the public half only. The exposure is a record assembled by hand or by another implementation, which is exactly the population a published schema exists to constrain.

The fix

A not/anyOf constraint over the seven private JWK members, placed alongside the existing allOf shape rules, mirroring _JWK_PRIVATE_PARAMS in the reference model. Public JWKs are unaffected.

Applied to both copies, schema/trace-claim.json (the published artifact) and src/agentrust_trace/schema/trace-v0.2.json (what the package ships). They were byte-identical and still are, with a test that keeps them that way, since drifting copies is how this kind of gap survives a fix.

Tests

Nine in test_provenance_cnf_boundary.py: one per private member, two that ordinary OKP and EC public JWKs still validate, and the copy-equality check. Reverting the schema turns all seven member tests red.

Full suite: 1172 passed, with the same 4 failures that reproduce on a clean main (three fixture-regeneration tests and one schema-classification test, all unrelated).

Not fixed here

agentrust-io/trace-tests carries a third copy of this schema with the same gap, and its conformance modules do not inspect cnf.jwk members (TR-ENV-004 checks only that kty is present, so a record carrying d passes the suite). Tracked separately against that repo.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbDBXDWWvMFa7c2jGgyq9t