Authority key ceremony.

This Key Ceremony document exists so that any third party relying on a BitSeal seal, whether to audit a file, defend a legal position, or evaluate the credibility of BitSeal as a provenance service, can answer three questions without having to rely on Orygn's public statements alone.

• Which exact public key is the canonical BitSeal Authority key today.
• Under what conditions the matching private key was generated and is held.
• What we can and cannot attest to about its history.

Where we do not have a formal attestation of a historical fact, this document says so plainly. A ceremony document that invents details is worth less than one that is honest about gaps.

The values below are derived at page request time from the Authority public key published as BITSEAL_AUTHORITY_PUBLIC_KEY_PEM, which is set to the public half of the KMS-resident signing key at provisioning time. They update immediately on key rotation and always match the value served at the well-known endpoint.

-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAz5+MzvF50PQ7G8zcLCDN2RbNCaFawyAXv9mGX88W3k8=
-----END PUBLIC KEY-----

Manifest specifications signed by this key

The Authority key signs two manifest formats. Both share the same BLAKE3 Merkle construction; they differ only in the bytes the Ed25519 signature covers. Every seal carries an explicitseal_mode field so verifiers can dispatch unambiguously.

The current Authority key was generated under the ceremony procedure published in our Rotation Policy. The facts below are the contemporaneous record of that generation event. A second, retired record follows below for the original Authority key (in service 2026-04-19 through 2026-05-29), which is preserved here in full so any seal issued under it remains independently auditable. Any relying party can recompute the current public-key fingerprint in Section 2 from the same PEM using the steps in Section 6, a mismatch between what this page claims and what the well-known endpoint serves is the strongest signal that something is wrong.

Current key (in service from 2026-05-29, AWS KMS hardware custody)

Previous key (in service 2026-04-19 through 2026-05-29, software custody, now retired)

The original Authority key was a software-generated Ed25519 key held as a Vercel environment variable. It was retired on 2026-05-29 when the AWS KMS key above took over signing, and its public half was moved into the historical-keys list under key_id = pre-kms-2026-04-19 with effective_from = 2026-04-19 and effective_until = 2026-05-29. The retired public key appears in Section 5 below and in the historical_keys array at the well-known endpoint. Seals issued during its effective window remain independently verifiable forever; BitSeal's verifier dispatches to it automatically by timestamp. The retired private key bytes were deleted from every Vercel environment at the time of cutover; there is no surviving copy in any other system held by Orygn.

Why a clean first-generation ceremony

Before the original Authority key recorded above, a pre-launch Ed25519 key had existed in the hosting environment variables since early development so that the signing code path could be exercised in staging. That key was never used to sign any externally-published seal and is not honored as a historical Authority key. Rather than publish a ceremony document with gaps around its generation, we rotated to the new key recorded under the full procedure. The pre-launch key is discarded and does not appear in Section 5.

What this record does and does not prove

• It establishes a self-consistent, timestamped statement of how each key was generated, under what procedure, on what platform.
• For the current KMS key, it commits the operator to a specific KMS key ID, region, and IAM-policy shape. The corresponding CloudTrail CreateKey and IAM events are preserved under Orygn's control and a redacted extract is available on operator request to an auditor with a legitimate need.
• It is signed by the current Authority key itself via the Self-Attestation Signature in Section 7, which proves that whoever holds the current signing capability is willing to bind themselves to the text of this document.

The Authority private key is held inside AWS KMS in the AWS account and region recorded in Section 3. It was generated inside an AWS KMS HSM and cannot be exported. The only operation any caller can perform with this key is the AWS KMS Sign API. The full list of named subprocessors is at /legal/subprocessors.

Residual attack surface: an attacker who exfiltrates the runtime IAM access key from the Vercel environment can produce valid Authority signatures against the current key for as long as they hold the credential, but cannot extract the private key, cannot list other AWS resources, cannot delete the key, and cannot escalate to other AWS principals. The recovery path under that scenario is documented in the Rotation Policy as an emergency rotation trigger.

This represents the conclusion of the HSM-migration roadmap item previously listed in this section and in the BitSeal Security threat model. The current state is FIPS 140-3 Security Level 3 HSM-backed Ed25519 signing, by inheritance from the AWS KMS HSM module validated under CMVP Cert #4884.

When the current Authority key is rotated, its public key is moved into the historical list so that seals signed under the retired key remain independently verifiable forever. Historical keys are never deleted.

There are two things you may want to reproduce offline: the public-key fingerprint above (proves the key shown here is the key being used), and the signature on any specific seal (proves a given manifest was actually signed by that key). Both are documented below.

Reproducing the fingerprint with OpenSSL

curl -s https://bitseal.orygn.tech/.well-known/bitseal-authority-key.json \
  | jq -r .current_key.public_key_pem \
  | openssl pkey -pubin -pubout -outform der \
  | openssl dgst -sha256

Reproducing the fingerprint with the BitSeal SDK

pip install bitseal
python -m bitseal.verify --fingerprint

If the fingerprint you compute does not match Section 2, stop trusting the page you are reading and email [email protected]. Mismatch is the single strongest signal that the hosted ledger or CDN has been tampered with.

Verifying a seal signature

Every seal manifest carries a seal_mode field telling a verifier which signature layout to use. The SDK does this automatically; python -m bitseal.verify --root <hex> fetches the seal, reads seal_mode, and dispatches to the matching path. The manual recipes for each layout are:

Verifying both layouts requires no BitSeal code. Any conforming Ed25519 implementation plus the public key from Section 2 is sufficient. The SDK source is open at OrygnsCode/BitSeal-SDK for reference.

A detached Ed25519 signature over the canonical text of this document, signed by the Authority key itself, is available at /api/legal/ceremony-attestation. The endpoint returns a JSON bundle containing the canonical text that was signed, the Ed25519 signature, the public-key fingerprint, the canonical content fact-sheet, and a server-side timestamp.

Signing a document about the Authority key with the Authority key is deliberately recursive and has one narrow property: it proves that whoever held the Authority key at the moment the endpoint was called was willing to bind themselves to the text of this document at that time. It does not prove that the signer is Orygn, that binding comes from the domain, TLS certificate, and corporate records.

What the V2 attestation binds to

The canonical text is six lines, UTF-8, LF-only, with a trailing newline on the last line. The signature covers exactly those bytes:

BITSEAL_CEREMONY_ATTESTATION_V2
content_sha256: <64-char hex>
document: /legal/key-ceremony
effective_date: 2026-06-04
key_fingerprint_sha256: <colon-hex>
signed_at_utc: <ISO 8601>

The content_sha256 line binds the signature to the structured facts of this ceremony: the authority identity, key fingerprint, raw public key, the v1 + v2 manifest specs the key signs, and the canonical service URLs. The exact bytes that hash to content_sha256 are shown below.

Canonical content (hashed by content_sha256)

BITSEAL_KEY_CEREMONY_CONTENT_V1
authority_ceremony_url: https://bitseal.orygn.tech/legal/key-ceremony
authority_organization: Orygn LLC
authority_service_url: https://bitseal.orygn.tech
effective_date: 2026-04-19
key_algorithm: Ed25519
key_curve: edwards25519
key_fingerprint_sha256_colon: 86:6C:6F:8C:1A:D2:A9:98:AF:21:5B:10:62:41:21:20:35:92:D0:34:3B:DE:B5:01:A9:E5:E1:DA:04:CD:3C:48
key_fingerprint_sha256_hex: 866c6f8c1ad2a998af215b10624121203592d0343bdeb501a9e5e1da04cd3c48
key_public_raw_hex: cf9f8ccef179d0f43b1bccdc2c20cdd916cd09a15ac32017bfd9865fcf16de4f
manifest_spec_url: https://github.com/OrygnsCode/BitSeal/blob/main/spec/v2-manifest.md
manifest_spec_v1: merkle-blake3-64k-v1
manifest_spec_v2: merkle-blake3-64k-v2

Reproduce the binding by running sha256sum over those exact bytes (no trailing whitespace beyond the single final newline) and checking the result against the canonical_content_sha256 field on the attestation endpoint. If the two differ, the attestation does not correspond to the facts shown here.

A future revision will add a secondary, off-key signature from a personal signing identity held by the Orygn operator so that the self-reference is broken. Until that is in place, treat the self-attestation as a consistency check, not an independent identity check.

This document is versioned. Every substantive change bumps the effective date at the top of this page. Prior versions are available on request at [email protected].