01
Create a signing identity
Associate the appropriate key with the issuer or supported service.
Signing keys
Signing keys, rotation and historical verification
Manage signing identities and retain the public verification information needed to check issued records.
Signing keys
Private signing access and public verification material
A private signing key creates a signature. The corresponding public key checks it. Keeping their roles separate lets recipients verify evidence without being able to issue records themselves.
New platform signing uses Google Cloud KMS. Public-key availability is essential for checking historical signatures.
Signing keys
Assign signing access, rotate keys and retain verification context
02
Protect issuing access
Give signing permissions only to the services and people that need them.
03
Preserve verification context
Retain historical public material and review the effect of revocation and rotation.
Details and limitations
Historical signatures, trust and unavailable keys
Plan for the life of a signed record
Choose who may request signing, where private key access is controlled and how recipients find the corresponding public verification material. Private signing credentials must not be included in proof links, browser bundles or examples. A public key or opaque key identifier enables verification; it is not a secret that grants signing access.
Rotation needs a historical verification plan. Keep the relevant public material for previously issued records and test it with the actual bundle or record representation. Revocation and compromise handling also need clear status behavior. If a required historical key is missing, disclose the incomplete check rather than replacing it with an unrelated current key.