Key rotation policy.

This policy governs the life cycle of the Ed25519 Authority key used by BitSeal to sign seal manifests. Its purpose is to bound the damage of a key compromise, establish a predictable operational cadence, and commit publicly to a rotation timeline that relying parties can audit.

The companion Authority Key Ceremony document identifies the current key. This document says when and how it will change.

The Authority key is rotated on a scheduled basis once per calendar year. The rotation window is October 1 through December 31 of each year. The exact rotation date within that window is selected to minimize user-visible disruption and is announced at least fourteen days in advance via the BitSeal changelog.

Scheduled rotation does not by itself imply that the retiring key was compromised. It reflects a defense-in-depth policy of limiting the effective lifetime of any long-lived signing key.

In addition to the scheduled cadence, Orygn will rotate the Authority key out of band on any of the following triggers. The target turnaround for an emergency rotation, measured from the moment the trigger is confirmed, is seventy-two hours.

Emergency rotation may be accompanied by a public security advisory, a list of seal root hashes issued during the suspect window, and, where appropriate, a re-sign campaign under the new key for unaffected seals.

A retired Authority key remains published on the well-known endpoint indefinitely, and seals signed under it remain independently verifiable forever. This is the central point: rotation does not invalidate history.

• For verification. Any retired key continues to be accepted as a valid verifier for seals whose timestamp_utc falls inside the key's effective window. BitSeal's verifier tries the current key first and then each historical key in effective-date order.
• For signing. A retired key is never used to sign new seals. Once the new key is in production, the retired key is removed from the signing environment variable.
• For emergency rotations. If a key is retired under an emergency trigger with suspected compromise, its status on the well-known endpoint is annotated with a rotation_reason and relying parties are advised to re-verify affected seals against the contemporaneous ledger.

Every rotation, scheduled or emergency, follows the procedure below. The intent is to produce a contemporaneous, independently verifiable record that improves on the retroactive attestation described in the Key Ceremony document for the initial key.

1. Pre-rotation announcement. For scheduled rotations, publish the target date in the BitSeal changelog at least fourteen days ahead. For emergency rotations, skip this step.
2. Generation environment. Generate the new key pair on a clean, up-to-date operating system with full-disk encryption enabled, using a Known-Good toolchain. The generation command, tool version, hostname, operating system version, and UTC timestamp are recorded in a ceremony log file before the key material is used for anything.
3. Witness. At least one second Orygn-authorized witness observes the generation. The witness signs the ceremony log with a separate personal signing identity distinct from the Authority key.
4. Fingerprint capture. Compute and record the SHA-256 fingerprint of the new public key before the private key is loaded into the production secrets store. The fingerprint is what the relying public will be asked to verify against.
5. Upload. Load the new private key into Vercel as BITSEAL_PRIVATE_KEY for the Production, Preview, and Development environments. The previous key is simultaneously moved into BITSEAL_HISTORICAL_PUBLIC_KEYS as a public-key-only JSON entry including key_id, public_key_pem, effective_from, effective_until, and, for emergency rotations, rotation_reason.
6. Deploy. A production deployment pushes the changed configuration live. The well-known endpoint begins serving the new current key and the enlarged historical list.
7. Post-rotation announcement. Publish a BitSeal changelog entry containing the new key's fingerprint, the retiring key's final effective date, and, for emergency rotations, the trigger. Update the Key Ceremony document to reflect the new current key.
8. Destruction of the retired private key. The previous private key material is securely destroyed on every machine that held it. Destruction is logged in the ceremony record.
9. Ceremony record. The complete ceremony log, including the witness signature, the generation metadata, and the destruction record, is retained in an access-controlled location. A redacted public version is added to the Key Ceremony document as a new historical ceremony entry.

The primary notification channel for rotations is the BitSeal changelog at bitseal.orygn.tech/changelog. Emergency rotations are additionally announced through a security advisory on the BitSeal homepage and a notice on the Security page.

Automated consumers of the well-known endpoint should expect and handle changes to current_key and growth of historical_keys. Clients that hard-code a single public-key fingerprint will break on rotation by design, this is a feature, not a bug, because it forces contemporaneous human review of what they are trusting.

Relying parties who wish to be notified proactively can email the address in Section 9.

During the 30-day overlap window that follows every scheduled rotation, BitSeal's verifier accepts either the retiring or the new key for any seal whose timestamp falls before the cutover, and requires the new key for any seal whose timestamp falls on or after the cutover.

Independent verifiers following the offline procedure in the Key Ceremony document should try keys in the order they appear on the well-known endpoint: current first, then each historical key. A successful verification under any published key is, for the purposes of BitSeal's attestation, a successful verification.

This policy may be updated to reflect operational changes, improvements in key custody (for example, a migration from Vercel environment variables to a hardware-backed KMS), or in response to external events. The effective date at the top of this page is updated on every change. Prior versions are available on request at [email protected].