Module revocation 

Consumer-side key-revocation semantics (ACDP 0.3, RFC-ACDP-0014).

Three layers:

• classify_under_revocation — the pure §7 boundary rule: given verified revocations and a (receipt-attested) publish time, decide historically authorized (pre-compromise, receipt-attested) vs fail-closed. This is what VerificationPolicy::revocations drives inside the fetch pipeline.
• verify_revocation_body — the §5 verification pipeline for a revocation context itself: strict RFC-ACDP-0001 §5.11 body verification, §4 shape parse, and the §5 step 2 not-self-signed check against the resolved signing key’s fingerprint.
• find_revocations — the §8 discovery SHOULD: search a registry for a producer’s revocation contexts and return the ones that verify.

Functions

classify_under_revocation

Apply the RFC-ACDP-0014 §7 compromise-boundary rule.

find_registry_attested_revocations

Discover a producer’s registry-attested (§6) key revocations — the RFC-ACDP-0014 §8 second query that find_revocations’s own doc points callers at, since a producer-scoped search structurally cannot return them (they are published under the registry’s agent_id, not the producer’s).

find_revocations

Discover a producer’s key revocations on a registry (RFC-ACDP-0014 §8): search type=key-revocation (and the §10 interim acdp:key-revocation) with agent_id=<producer>, retrieve each match, and return the ones that verify per §5 (verify_revocation_body) and that satisfy two additional invariants enforced client-side, neither of which the registry can be trusted to have applied:

find_revocations_in_lineage

Discover every verified member of a revocation lineage (RFC-ACDP-0014 §4, RFC-ACDP-0013 §8.1), regardless of registry_state.status and with no trust-class or publisher scope filter applied.

verify_revocation_body

Verify a key-revocation context body per RFC-ACDP-0014 §5 and return its typed, trust-classified form.