[zohebk8s]

What this changes

Closes #76.

verify_record() checked signature and freshness but never consulted revocation or transparency state, so a record signed by a revoked or compromised key kept verifying. This is a gap against the spec's own normative text, not a new requirement: §3.2.1 already says "Verifiers MUST consult current revocation status at verification time".

A signature stays cryptographically valid forever and nothing inside a record can retract the key that made it, so the verifier is the only place withdrawal of trust can be applied.

The revocation store

verify_record(..., revocation=...) accepts either form:

# A revocation list the caller already holds.
verify_record(record, trusted_jwk, revocation={"kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k"})

# Or a live CRL / status endpoint / SCITT lookup.
verify_record(record, trusted_jwk, revocation=lambda key_id: crl.is_revoked(key_id))

Outcome	Result
Key listed as revoked	Rejected (ValueError)
Store raises (endpoint down, timeout)	Rejected; an unavailable source is not evidence a key is unrevoked
Key absent from the store	Verification continues
No revocation passed	Check skipped; offline verification, unchanged

Failing closed on an unreachable store is the part that matters: if a lookup failure fell through to "verified", an attacker holding a revoked key would only need to make the status endpoint unreachable.

Two design points worth review

The check reads the trusted key, not record["cnf"]["jwk"]. The embedded key is attacker-controlled until the signature verifies, so keying the lookup on it would let a revoked issuer present an unlisted thumbprint and pass. There is a test pinning this.

Identifiers are the RFC 7638 JWK Thumbprint or kid. Thumbprints work when an issuer publishes no kid, and are stable across JWKs differing in optional members. jwk_thumbprint() is exported so a caller can key a list on the same identifier the verifier derives; it is pinned against the RFC 8037 Appendix A.3 known-answer vector.

Scope

Deliberately not in this PR:

• No normative text, schema, or record field changed. This implements an existing MUST in the library, so it is not a spec change and needs no comment period.
• revocation defaults to None rather than being required. Making it mandatory is a breaking API change for every consumer (cMCP, ca2a) and is better decided alongside [pre-v1.0] Key revocation: TraceRevocation claim + entry-ID anchor #67, which designs the TraceRevocation claim and the entry-ID anchor. This PR gives the verify path the hook; [pre-v1.0] Key revocation: TraceRevocation claim + entry-ID anchor #67 can decide what feeds it.
• Transparency/SCITT state is reachable through the callable form, but no SCITT client is added here.

Documented rather than left implied: docs/verification.md opens with "independently verifiable offline", which is true and is exactly why non-revocation is the one thing it cannot establish. That page and LIMITATIONS.md now say so directly.

Type of change

• Editorial (typo, link fix, clarification — no normative effect)
• Non-breaking spec change (new optional field, new platform profile, informative addition)
• Breaking spec change (requires 14-day comment period and Project Lead sign-off)
• Schema change
• Example addition

None of the listed categories fit, so I have left them unticked rather than claim one inaccurately. This is a library and docs change that implements an existing normative MUST. No spec text, schema, or record field is modified. Happy to tick whichever box you consider correct.

Spec section

3.2.1 (Signing and key management), implemented rather than modified. No spec text changed.

Checklist

• DCO sign-off on all commits (git commit -s)
• CHANGELOG.md updated
• Breaking changes marked with <!-- CHANGED: #NNN — description --> in spec text (not applicable, no breaking change)
• Backward compatibility statement included: additive keyword argument defaulting to None, so offline verification is byte-for-byte unchanged

Verification

• 105 tests pass, 14 new. Every new line covered (sign.py misses are pre-existing).
• ruff check src tests and mypy src/agentrust_trace (strict) clean.
• Backward compatibility checked against a downstream consumer: the cMCP suite passes unchanged with the patched package installed, 893 passed and 8 skipped, before and after.

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	NONE
Overall	MEDIUM

Automated check by AgenTrust Contributor Check.

[zohebk8s]

Fork CI is green on this exact commit (283383d), both matrix legs:
https://github.com/zohebk8s/trace-spec/actions/runs/30584031843

test (3.11) and test (3.12): lint, type check, and tests all pass.

[imran-siddique]

Reviewed the diff carefully, including against the individual-contributor spec policy. This is not a normative change: spec/trace-v0.2.md and schema/ are untouched, and the changed files are the reference implementation plus non-normative docs. It implements normative text that §3.2.1 already carries rather than adding a requirement, so the policy that reserves spec changes to known orgs does not apply here.

On the substance, the security-critical decisions are all the right way round:

• The check is keyed on the trusted key, never record["cnf"]["jwk"]. That is the one detail that decides whether this is a real control or theatre, since the embedded key is attacker-controlled until the signature verifies, and keying on it would let a revoked issuer present an unlisted thumbprint. The allow_embedded_key=True case is called out rather than glossed.
• A store that cannot answer is a rejection, not a pass. An unreachable CRL is not evidence a key is unrevoked.
• revocation=None stays the default, so offline verification is unchanged and the feature is additive. LIMITATIONS.md and docs/verification.md now say plainly that offline mode proves "validly signed by this key", not "this key is still trusted". That honesty is the part I care most about.
• jwk_thumbprint hashes only the RFC 7638 required members per kty, so it is stable across JWKs differing in kid/alg/use. Using JCS for the serialization is fine given member names are ASCII, and the docstring already notes why that is byte-identical to RFC 7638 §3.3 ordering. Omitting oct is correct for a module that only handles public confirmation keys.
• Matching on thumbprint or kid covers issuers that publish neither consistently.

Placement before the signature check is right: the trusted key's status does not depend on the record, so there is nothing to gain by verifying first.

Only failing check is the maintainer-hold gate.