Skip to content

security: enforce revocation/transparency at verify time #76

Description

@imran-siddique

Tracked follow-up from the June 2026 org-wide security hardening review. Wave 1/2 fixes are merged and published; this is remaining hardening.

verify_record checks signature + freshness but does not consult any revocation/status or SCITT transparency state, so a revoked/compromised key keeps verifying.

Scope: add a revocation/status check to the verify path (caller-provided revocation store or CRL/STH lookup), and document that pure offline verification cannot prove non-revocation. Fail closed when a record references a revoked key.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    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