Skip to content

[pre-v1.0] Key revocation: TraceRevocation claim + entry-ID anchor #67

Description

@imran-siddique

Tracking issue for the key-revocation design discussed in #46. Maintainer-driven editorial work for v1.0, not a contributor schema merge.

Decision

Anchor revocation to SCITT log entry ordering, not to iat.

A compromised record-signing key also controls the iat field it signs, so any rule of the form "reject if key revoked and iat > revoked_time" is defeated by backdating. We therefore anchor to the Merkle-bound log entry ID instead.

TraceRevocation/1.0 claim type (new §3.2.4)

{
  "type": "TraceRevocation/1.0",
  "compromised_key_id": "<key fingerprint>",
  "last_valid_entry_id": "<SCITT log entry ID>",
  "revoked_after_entry": "<next entry ID>",
  "reason": "key compromise",
  "revocation_key_id": "<org recovery key fingerprint>",
  "sig": { "alg": "ed25519", "value": "..." }
}

Verifier rule

A record signed by a revoked key is valid if and only if its SCITT inclusion entry ID is <= last_valid_entry_id in the applicable revocation statement.

  • Entry IDs are monotonic and cryptographically bound to the Merkle structure: no clock trust, no notary trust beyond the existing SCITT profile.
  • Fallback: for records with no usable SCITT receipt, binary revocation (reject all records from the key). No external anchor means no reliable way to distinguish pre- from post-compromise.

Distribution (offline-verifiable)

  • Revocation statements are anchored in the same SCITT log as the records they govern (preserves the no-callback property of §3.3).
  • Verifiers cache a signed revocation bundle with a valid_until field, same max-age model as §3.2.2. A verifier offline can assert "verified against revocation bundle valid at T".
  • This replaces the original "MUST check a well-known endpoint" proposal, which would break offline verification.

Signing-key independence (MUST)

A revocation statement for key K MUST be signed by a key at a higher level in the §3.2.1 key hierarchy than K, or by a designated org/recovery key whose compromise domain is independent of K.

Scope of the editorial change

  1. New §3.2.4 (or §3.3.x): TraceRevocation claim type + entry-ID revocation rule + binary fallback.
  2. docs/verification.md: upgrade the receipt framing so inclusion entry ID is a normative ordering/anchor source (MUST), not only an inclusion/immutability proof.
  3. schema/: revocation statement + revocation bundle format.

Cross-references

  • trace-spec#46 (origin discussion, with @madeinplutofabio)
  • Align verifier revocation-status output with the PIC binary-revocation model and its conformance vectors (evidence-sig-block-003-revoked-key, evidence-sig-block-004-expired-key) so PIC verifiers consuming TRACE records act consistently.

Out of scope

Accepting a contributor-authored normative schema diff directly. The spec text, verification.md, and schema land through the maintainer editorial process.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpre-v1.0Editorial work targeted before v1.0securitySecurity issue

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions