[spec] Key revocation extension — reject records signed by compromised keys after a declared timestamp

[harshnair75567-cloud]

Spec section affected

Problem
LIMITATIONS.md mentions that if a signing key is compromised/stolen, all records it signed remain cryptographically valid indefinitely. Verifiers have no way to distinguish legitimate records from forged/fake ones issued by an attacker using the stolen key.

Proposed change
Two additions to the spec:

1. Revocation Record — a signed document (using a separate backup key) declaring:

compromised_key_id — the key being revoked
revoked_time — timestamp of compromise
reason — optional(for other verifiers)

2. Verifier obligation — before accepting a TRACE record as valid, a verifier MUST check a well-known revocation endpoint and MUST reject any record where the signing key appears in the revocation list and iat > revoked_time

Backward compatibility

• [ . ] Non-breaking (new optional field, informative addition)
• Breaking (removes or changes required field, changes wire format, changes algorithm set)

Motivation
without revocation it can allow infinite impersonation hence this could help stop any forged TRACE record from passing verification

Related issues or PRs
None. addresses the gap mentioned in limitations.md

[madeinplutofabio]

Good catch. I agree this is a real gap to close before v1.0.

One sharp edge in the proposed verifier rule:

reject any record where the signing key appears in the revocation list and iat > revoked_time

I would avoid anchoring that decision to iat alone. iat is part of the signed record, so if the record-signing key is compromised, the attacker also controls the key that signs iat. They can set iat to a value before revoked_time and the forged record may pass the proposed check. The mandatory max-age in §3.2.2 bounds the abuse window but does not close it: within the freshness window, an attacker can still backdate iat to just before revoked_time.

TRACE already has a better time anchor in the transparency / SCITT layer. If the record carries a transparency receipt with a verifiable inclusion time, the safer rule is closer to:

reject if the record-signing key is revoked and the record's transparency-log inclusion time is at or after revoked_time.

That uses an independently anchored time source (the log operator, already trusted in the §2.3 TCB) rather than a timestamp asserted by the compromised signer.

For records from a revoked key without a usable transparency receipt / independently trusted timestamp, the safe fallback should be binary revocation: reject all records from that key. That is harsher, since it can invalidate legitimate pre-compromise records, but without an external time anchor there is no reliable way to distinguish signed before compromise from forged after compromise with a backdated iat.

A couple of other design details worth specifying, in my opinion:

• The Revocation Record should be signed by a key that is not in the same compromise domain as the revoked record-signing key, for example an org/root/recovery key or a higher level in the §3.2.1 key hierarchy. Otherwise the same compromise that invalidates the record-signing key also invalidates the independence of the revocation channel.
• MUST check a well-known revocation endpoint may conflict with TRACE's offline-verifiability goal in the abstract. Defining revocation as signed statements, optionally anchored in the same transparency log, lets verifiers cache and distribute revocation state and still verify offline with bounded freshness. The same §3.2.2 max-age model could apply to revocation statements too.

Related prior art: PIC Standard uses the simpler binary model today: local trusted keyring, revoked_keys, optional per-key expires_at, and fail-closed verification for missing/revoked/expired keys, pinned by conformance vectors (evidence-sig-block-003-revoked-key, evidence-sig-block-004-expired-key). That model avoids the backdating issue because it does not trust a timestamp from the revoked signer, but it also cannot preserve legitimate pre-compromise records. A TRACE-specific design can improve on that by using transparency inclusion time when available, with binary revocation as the fail-closed fallback.

Happy to help turn this into concrete spec text if useful.