Custody, explained
Custody means who holds the storage and who holds the signing key. Every record says which, and the verifier reports it. There are two modes, and a workspace can move from one to the other.
The three properties the design rests on
Section titled “The three properties the design rests on”Stratl’s security does not depend on one cloud. It depends on three properties, and any provider that offers them can hold custody:
- A key service that can sign but never releases the private key. Today: AWS KMS, Google Cloud KMS, Azure Key Vault.
- Object storage that keeps every version and gives the Stratl service no permission to delete. Today: Amazon S3, Google Cloud Storage, Azure Blob.
- A timestamp authority independent of both the customer and Stratl. Today: two public RFC 3161 authorities, tried in order.
Managed custody
Section titled “Managed custody”The default. When a workspace is created, its owner picks a region. Stratl creates one signing key for the workspace inside the key service in that region, and stores its records, checkpoints and any original content under the workspace’s own prefix in a bucket in that region. The choice is fixed: keys do not move between regions.
The Stratl service holds four permissions on that custody, and no others:
| Granted | Not granted |
|---|---|
| Ask the key service to sign | Export, copy or wrap the private key: the permission does not exist for this key type |
| Read the public key | Delete, disable or change the policy of a key |
| Write records, checkpoints and content under the workspace prefix | Delete a stored object or a version |
| Read them back | Make anything public: public access is blocked at the storage level |
Every signature the service asks for is noted and, at each checkpoint, sealed into a signed record in your stream, so you can see every use of your key and match it to the provider’s own audit log. Key-usage records.
Your own custody
Section titled “Your own custody”A workspace owner can take custody: their own bucket and their own key, on their own cloud, on AWS, Google Cloud or Azure. Stratl then holds only the permission to sign with that key and to write and read that bucket, granted by the customer and revocable by them.
Before anything moves, Stratl proves the arrangement against the real account: it signs a probe and verifies it, writes a small object and reads it back, then tries to delete it. The delete must fail. Then a hand-over statement naming the old custody, the new custody and the chain head is signed by both keys, written into both storages, and recorded in the stream. From that record on, new records are signed with the customer’s key; all history is copied into the customer’s storage without being re-signed, and the old public key stays in every bundle so old records still verify. The full procedure.
What is stored where
Section titled “What is stored where”| Thing | Where | Content? |
|---|---|---|
| Records, signatures, checkpoints, public keys | Custody storage (managed bucket or your own) | Fingerprints and metadata only |
| Original content, if the source uploaded it | Custody storage, under its fingerprint | Yes, the bytes |
| The searchable index | Stratl’s PostgreSQL, one location for all workspaces | Fingerprints and metadata only, never content |
| Sign-in codes, sessions, keys | Stratl’s database, as one-way hashes | No |
| Logs | Hosting providers | Paths, ids and errors; never content |
What custody does not change
Section titled “What custody does not change”Assurance is about how events were captured and does not change with custody. What changes is who controls the evidence, and the record says so plainly: a managed-mode bundle reads key custody: Stratl-managed, per workspace, externally timestamped. That is honest, and for many customers acceptable; enterprise contracts usually require the customer to hold at least the key.