Key management

In plain language: Intramedial signs each ledger bundle with one of two keys, kept as secrets inside the service that seals bundles. The public halves are published so you can check a bundle without us. We do not claim these keys sit in a hardware module, because they do not.

AWS Key Management Service does protect other secrets we hold: it wraps the keys that encrypt third-party credentials stored in our control plane. It does not hold the keys that sign bundles.

2. Which key signs which bundle#

A bundle is signed with the key of the jurisdiction that matches the region serving the workspace's request:

The jurisdiction is written into the signed core of every bundle, together with the key id, so a verifier knows which published key to use. If the preferred key is not configured, the service may sign with the other jurisdiction's key, and the bundle then names that key; if no key is configured at all, the request fails with 503 and nothing is signed or returned unsigned.

3. Key ids#

A key id (kid) is derived from the public key itself: the first 16 bytes of the SHA-256 hash of the raw 32-byte public key, encoded as base64url without padding, 22 characters. You can recompute it from the published key, so nobody can attach a different id to a key without it showing.

Every bundle names its key in signingKeyId.

4. Where the public keys are published#

Each key in the set has kty: "OKP", crv: "Ed25519", alg: "EdDSA", use: "sig", its kid, the public key x in base64url and its jurisdiction. The private part is never in the set. See ledger-bundles.snapshot and Signing keys for the API.

5. Pinning a key#

A signature proves who holds a key, not whose key it is. For the strongest position, fetch the key set once through a channel you trust, store the kid and x of the key you rely on in your own repository or records, and verify against that copy. Keep the key set you verified against next to any bundle you keep as evidence: the two together verify on their own, years later and without us.

6. Rotation#

A key changes only through a manual key change run by us. There is no automatic rotation, no schedule and no expiry. No production signing key has been rotated so far.

When a key is retired, its public half stays in the published key set for as long as bundles it signed can be relied on, and a key change never changes the bundle format. This is our commitment, not something the key endpoint enforces on its own, which is one more reason to pin the keys you rely on.

Rotation requests from workspace owners and administrators follow the process in Signing keys. A request records the wish; it does not rotate anything by itself.

7. If a key is compromised#

There is no automated compromise response, no revocation list and no revocation of single bundles. A leaked key would let its holder create bundles that verify, and a signature check alone could not tell them from genuine ones.

We would handle a suspected compromise as a security incident. Where a key has been, or may have been, misused, we would:

1. stop signing with it and move the jurisdiction to a new key;
2. publish a notice on this page and in the changelog naming the key id and, as far as we can establish it, the period in which it may have been misused;
3. tell the owners of the affected workspaces by email; and
4. decide, and say in the notice, whether the key stays in the published set. Withdrawing it makes every bundle under it fail to verify, genuine ones included, so we would weigh that against the risk of forgeries.

Your best protection does not depend on us: pin the key set you verified against, and where a bundle matters, keep it in a system you control, with its own clock, when you receive it. If the daily anchor for your workspace is switched on, the bundle's Merkle root is also entered in an anchor batch (see Verifying ledger bundles); a bundle whose root was anchored before a compromise keeps its value, because the anchor shows the root existed before the forgery became possible.

Report a suspected compromise to security@intramedial.com.

8. What custody does not protect against#

Because the signing keys are secrets available to the service that seals bundles, whoever can deploy or administer that service could cause it to sign. We limit that access to the people who operate the service, and the signed core of a bundle is built by the service from the workspace's own audit chain, not from content supplied in the request. The Record Practice Statement explains what a signature does and does not attest, and why the trust you place in us is limited to a short list. Moving the signing keys into a hardware-backed key service is a change we intend to make; until we do, this page will not say that it has happened.

9. Key events#

No key has been rotated or compromised. Notices of rotations and compromises will be added here, with their dates. Questions: security@intramedial.com.

EU notices

• Digital Services Act
• EU Data Act
• EU AI Act
• Right of withdrawal

Receipt practices

• Record Practice Statement
• Verifier Terms
• Key management
• Verifying ledger bundles
• Format versions and long-term verification
• Cryptographic agility and post-quantum status
• If Intramedial stops operating

Program terms

• Startup Program Terms
• Nonprofit Program Terms
• Education Program Terms
• Public Sector Program Terms