If a signing key is compromised
Write to security@actaseal.com. Say which key (its key id) and when you first suspected a problem.
What happens
- The key is revoked. It is flagged as revoked in the deployment's
published key list, at
/.well-known/actaseal-keys.json, with the time and the reason. It is never removed: it stays listed so that a receipt it signed can still be traced to it. - A new key takes over. A new key is added and made the active one. Revoking and replacing are separate steps, so a key can be withdrawn at once without waiting for its replacement.
- Unanchored receipts are anchored. A receipt signed under the old key that has no independent timestamp or transparency-log proof from before the compromise should have one requested straight away.
- You are told. You receive a written notice stating the period affected.
What this means for your receipts
The verifier does not treat a receipt under a revoked key as valid. Given the published key list, it reports that the signature is genuine, that the key was revoked, and when.
What settles the question is independent time. A receipt that carries a trusted timestamp or a transparency-log inclusion proof dated before the compromise can be shown to have existed before it, without relying on the compromised key. A receipt signed during the affected period with no such anchor cannot be shown that way. Treat it as unverified.
Check again any receipt you relied on for a dispute or a record, and keep the verifier's output with it.
Who holds the key
In a production deployment the signing key is held in your own key-management service or hardware module, not by ActaSeal. A compromise of that custody is also a matter for your own security team.