Conversation
rmhrisk
force-pushed
the
feat/revoc-auditability
branch
from
1e40422 to
907563a
Compare
rmhrisk
pushed a commit
that referenced
this pull request
Mar 17, 2026
All three were written before the work was done and never updated: 1. README Known Limitations and SPEC.md §Revocation — Auditability both said 'Java issuer does not yet emit the revoc: extension line'. Java has emitted it since PR #51 (feat/revoc-auditability). Updated to: all four issuers emit the line; all four verifiers parse it; active enforcement is advisory. 2. SPEC.md Open Questions section said 'Revocation auditability: deferred to v2' as if the artifact hash commitment was not built. It was built in PR #51. Updated to: tamper-evident commitment implemented; full auditability (hard verifier enforcement + public revocation log) still deferred. 3. IMPLEMENTERS_GUIDE.md §Mode 0 payload size section said 'Mode 0 is not yet implemented in this reference SDK'. Mode 0 was implemented in PR #46 across all four SDKs. Updated to describe what is implemented.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every checkpoint body now includes a
revoc:<hex(SHA-256(artifact))>extension line when a revocation artifact is available. Per c2sp.org/tlog-checkpoint, extension lines are part of the authenticated content — witnesses automatically cosign this line without any witness code changes.What this provides: An issuer cannot present a different revocation artifact for the same tree size without invalidating the witnessed checkpoint. Revocation state is tamper-evident.
What this does not provide: Full CRLite-style auditability where independent parties can reconstruct the filter from publicly disclosed revocation events. The issuer remains the sole authority for which entries enter the revoked set.
Design: The revocation artifact is built first (no circular dependency — it uses log entry data, not the checkpoint root). Mode 0 payloads use pre-computed plain 3-line body signatures stored alongside the 4-line signatures so the Mode 0 verifier can reconstruct the signed body from
(origin, treeSize, rootHash)alone.All four SDKs: Go, TypeScript, Rust, Java issuers emit the extension line. All four verifiers parse it.
Tests: Go 5/5, TS SDK 49/49, Rust 31/31, Java 40/40, interop 19/19.