Implement circuit verification key whitelist/revoke mechanism

[jpraynaud]

Why

Any change in a circuit (logic, dependency update, parameters) changes its verification key, and a circuit or a key can turn out to be insecure. There is no mechanism today to invalidate the certificates produced with it: the trust in the circuit verification key is compile time only, and clients have no signal to reject a range of certificates.

What

Prepare a revocation mechanism for certificates in defined epoch ranges. The revocation list is published, signed by the genesis key, and must be verified by clients prior to verification.

How

• Specify the format of the whitelist and revocation list (circuit verification keys, epoch ranges) and how the genesis key signs it
• Implement the creation and the signing of the list with the genesis key (new command in the aggregator)
• Enforce the whitelist and revocation checks on the circuit verification key in the prover and the verifier setup
• Update the infrastructure
• Update the documentation
• Create a runbook for the revocation procedure
• Publish the registries to the repository:
  • testing-preview
  • dev-preview
  • pre-release-preview (will be done upon deployment)
  • release-preprod (will be done upon deployment)
  • release-mainnet (will be done upon deployment)

[github-actions]

This issue has been automatically marked as stale because it has been inactive for 90 days.