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 KMS key is taken out of the signing path and scheduled for KMS deletion under the procedure in Section 5.
• 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. Key generation inside KMS. A new Authority key is created via aws kms create-key with --key-spec ECC_NIST_EDWARDS25519 and --key-usage SIGN_VERIFY. The private key is generated inside AWS KMS hardware and never exists outside of it. The creation command, returned key ID, AWS account, region, and UTC timestamp are recorded in a ceremony log file before the key is referenced anywhere else.
3. Independent attestation surface. Independent confirmation that the ceremony happened, of what key was generated, and that the published record matches reality is provided by three publicly verifiable artifacts, produced as part of the steps in this procedure or as automatic side effects of normal operation. (a) The post-rotation announcement commit from Step 7, where the new key's SHA-256 fingerprint, the retiring key's final effective date, and the updated Key Ceremony document (Section 3 "Generation record") are pushed to github.com/OrygnsCode/BitSeal. GitHub timestamps the commit independently of Orygn, and the well-known endpoint at /.well-known/bitseal-authority-key.json begins serving the new public key in the same cutover. (b) The Bitcoin-anchored seal stream: every seal issued under the new key has its signature submitted to OpenTimestamps and committed inside a Bitcoin block within 1 to 24 hours of seal time. Once anchored, the seal carries a block time that Orygn does not control. A retroactive key swap would invalidate every Bitcoin-anchored seal in the affected window. (c) The re-signed self-attestation on the Key Ceremony page Section 7: after cutover, the byte-stable ceremony content is re-signed under the new Authority key, binding the published page to the new key from the moment the new key is in service. Each of these is verifiable by anyone without having to trust Orygn. In addition, the AWS CloudTrail CreateKey management event for the new key is preserved under Orygn's control and a redacted extract is available on operator request to an auditor with a legitimate need.
4. Fingerprint capture. Retrieve the new public key via aws kms get-public-key, convert the DER output to PEM, and compute its SHA-256 fingerprint. Record the fingerprint, the KMS key ID, and the canonical PEM in the ceremony log. The fingerprint is what the relying public will be asked to verify against.
5. Configuration update. Update the production environment to reference the new key: BITSEAL_KMS_KEY_ID is set to the new key ID, BITSEAL_AUTHORITY_PUBLIC_KEY_PEM is set to the new PEM, and the retiring key is appended to 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. The signing path now calls kms:Sign against the new key for every new seal.
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. Retirement of the previous KMS key. The previous Authority key is scheduled for deletion via aws kms schedule-key-deletion with a thirty-day pending window. The thirty days span the verification overlap described in Section 7, after which the key material is destroyed by AWS KMS. The scheduling command, the target deletion date, and the corresponding CloudTrail ScheduleKeyDeletion event ID are recorded in the ceremony log. For emergency rotations under suspected compromise, the pending window may be shortened to seven days, the minimum AWS KMS permits.
9. Ceremony record. The complete ceremony log, including the CloudTrail event IDs (CreateKey, ScheduleKeyDeletion), the KMS key metadata, the public-fingerprint git commit SHA, and the post-cutover re-signed self-attestation, 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 (the 2026-05-29 migration from a software-stored private key in Vercel environment variables to AWS KMS Ed25519 hardware custody is the canonical example), 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].