Security
Who holds each private half.
The map shows where each private half sits. The ledger under it names the holder, who certifies or vouches the public half, and where the key would live in your deployment. Every claim carries its class.
Where every private half sits
One tile for each kind of key. The side it sits on holds the private half.
- Anchor and authority signing keys
- Hosted entity signing key
- Certified key
- Supplied public key
- Vouched by its own root
- Outside Connect custody: the estate's own services make and vouch it
3 kinds of key
Raidiam holds the private half
Read first. Each tile is a row in the ledger below.
- Anchor signing key, for both trust domains Raidiam, in a key management service
- Authority signing key, for both trust domains Raidiam, in the same key management service
- Connect hosted entity signing key Raidiam
13 kinds of key
The holder keeps the private half
Raidiam's setup and deploy tools made the certified and supplied keys, delivered each private half to its holder, and keep a copy in the operator's key store.
- Platform keys Each platform process
- Records resource key The resource process
- Transfers and portfolios resource keys The resource process
- Attester federation key The attester process
- Attester attestation key The attester process
- Agent authentication keys The catalogue, on Tarnbrook's behalf
- Release signing key The catalogue process
- Publisher, partner and division root keys Each root's own process
- Agent keys a party's own root vouches Each agent's service
- SPIRE certificate authority and SVID keys The SPIRE server host, and each workload over the workload API
- Instance keys Each running copy, in process
- Scheme officer client key The officer console process
- Catalogue's Connect client key The catalogue process
Every kind of key this estate runs
3 of 16
kinds of key
Raidiam holds the private half
13 of 16
kinds of key
The holder keeps the private half
Where Raidiam holds a key
The three Raidiam holds are: Anchor signing key, for both trust domains · Authority signing key, for both trust domains · Connect hosted entity signing key
The anchor signers and the authority signers on this tenant are keys in a key management service, in the account Raidiam operates. Every signed statement names its key identifier in its header. A key management boundary you operate for the authority signer is a deployment choice for Connect, and this tenant is configured the other way. Deployment evidence
Both anchors sign with one federation key, and both authorities sign with one authority key. The two trust domains are separated by entity identifier and by governance record, and a consumer pins the pair, so a chain to the wrong anchor is refused on the issuer. Cryptographic separation is absent: the holder of the shared key can mint a statement in either anchor's name, and on this tenant that holder is Raidiam. Not observed on this tenant
For a partner's security team
Who holds the private keys?
- On this estate
In 2 of the 3 custody models the holder keeps the private half: 18 of the 19 entities that declare a model. Raidiam's setup and deploy tools generated those keys and delivered each private half to its holder. The rest run the Connect hosted model, where Connect signs the entity configuration with a key Raidiam holds.
Deployment evidence- Across the boundary
Signed statements, fetched with an unauthenticated GET and no header sent. Each statement names in its header the key identifier that signed it.
Deployment evidence
Raidiam holds the private half3 of 16
Read first rather than left to be found. Each row says where the equivalent key would live in a deployment you operate.
-
Anchor signing key, for both trust domains
- Held by
- Raidiam, in a key management service
- Certified or vouched by
- Pinned by each consumer as the pair of anchor identifier and key, for each domain it reads
- What this deployment does
- Published in both anchors' entity configurations. The two domains are separated by entity identifier and by governance record.
- In your deployment
- Your tenant's key service
-
Authority signing key, for both trust domains
Deployment evidence
- Held by
- Raidiam, in the same key management service
- Certified or vouched by
- The anchor of each domain
- What this deployment does
- Signs subordinate statements, resolve responses and trust marks in both domains.
- In your deployment
- As the anchor key
-
Connect hosted entity signing key
- Held by
- Raidiam
- Certified or vouched by
- Both authorities, on their statements about a hosted entity
- What this deployment does
- Signs the entity configuration of an entity Connect hosts.
- In your deployment
- Your tenant's key service
The holder keeps the private half13 of 16
Connect receives a signing request, a public key, or nothing at all. Raidiam's tools made the certified and supplied keys and delivered them to each holder.
-
Platform keys
Deployment evidence
- Held by
- Each platform process
- Certified or vouched by
- A certificate from a signing request under the platforms organisation
- What this deployment does
- One key for each platform, published in the statement about it.
- In your deployment
- Your authorisation server's key store
-
Records resource key
Deployment evidence
- Held by
- The resource process
- Certified or vouched by
- A supplied public key. Connect publishes it and issues no certificate for it.
- What this deployment does
- Signs what the resource publishes about itself.
- In your deployment
- Your resource's key store
-
Transfers and portfolios resource keys
Deployment evidence
- Held by
- The resource process
- Certified or vouched by
- A supplied public key. Connect publishes it and issues no certificate for it.
- What this deployment does
- The key identifier is the digest of the subject public key, so both ends compute it independently.
- In your deployment
- Your resource's key store
-
Attester federation key
Deployment evidence
- Held by
- The attester process
- Certified or vouched by
- A certificate from a signing request under the group organisation
- What this deployment does
- Signs the attester's entity configuration.
- In your deployment
- Your attester, or a Raidiam authorisation server with the attestation capability
-
Attester attestation key
Deployment evidence
- Held by
- The attester process
- Certified or vouched by
- Published in the attester's attestation key set and reached through the chain
- What this deployment does
- Signs each attestation and the signed list of stopped copies. Consumers find the key by resolving the attester.
- In your deployment
- As the attester federation key
-
Agent authentication keys
Deployment evidence
- Held by
- The catalogue, on Tarnbrook's behalf
- Certified or vouched by
- A certificate from a signing request under the group organisation
- What this deployment does
- Sign the assertions an agent presents at a token endpoint. The assertion route sits behind a credential, and the runtime authenticates through it.
- In your deployment
- Your agent runtime
-
Release signing key
Deployment evidence
- Held by
- The catalogue process
- Certified or vouched by
- A certificate from a signing request, published in the publisher leaf's key set
- What this deployment does
- Signs Tarnbrook's release records. The catalogue's writes to Connect use the Connect client key below.
- In your deployment
- Your build pipeline's signing key
-
Publisher, partner and division root keys
Deployment evidence
- Held by
- Each root's own process
- Certified or vouched by
- Supplied public keys on the recognition records
- What this deployment does
- Tarnbrook holds the public half alone. Each party signs its own root, its records and its statements about its agents.
- In your deployment
- The party's own key store
-
Agent keys a party's own root vouches
Deployment evidence
- Held by
- Each agent's service
- Certified or vouched by
- The party's own root, in its statement about the agent. Connect receives nothing for this key.
- What this deployment does
- Signs each agent's entity configuration.
- In your deployment
- The party's own key store
-
SPIRE certificate authority and SVID keys
Deployment evidence
- Held by
- The SPIRE server host, and each workload over the workload API
- Certified or vouched by
- The bundle at the workload domain root
- What this deployment does
- An SVID lives one hour and signs the binding proof.
- In your deployment
- Your workload identity system
-
Instance keys
Deployment evidence
- Held by
- Each running copy, in process
- Certified or vouched by
- The attester, in the attestation's confirmation claim
- What this deployment does
- Generated where the copy runs. The attester binds its public half in the attestation.
- In your deployment
- The running copy
-
Scheme officer client key
Deployment evidence
- Held by
- The officer console process
- Certified or vouched by
- A certificate under the scheme organisation
- What this deployment does
- Every withdrawal is attributed to this client and to the named officer.
- In your deployment
- The scheme's case management tool
-
Catalogue's Connect client key
Deployment evidence
- Held by
- The catalogue process
- Certified or vouched by
- A certificate under the operations organisation
- What this deployment does
- The operator credential for each environment.
- In your deployment
- Your governance front end, or a service behind it
- Your platform Pins the anchor it trusts.
- Raidiam Connect Publishes signed statements about every governed entity.
-
Issued and vouched below
Certificates, trust marks and a party's own root.
- Your PKI
- The authorities
- External parties
Key custody
Custody depends on the model. This estate declares three.
- Your platform pins the anchor from its own configuration.
- The holder keeps the private half in two of the three models. The setup tool makes each certified key and the deploy tool each supplied one.
- Connect certifies a public half from a signing request, or publishes a supplied key.
- Raidiam holds the anchor and authority signing keys on this tenant. Deployment evidence
- Connect signs the entity configuration of the one entity it hosts, with a key Raidiam holds. Deployment evidence
- 1The setup tool generates a key pair and a signing request.
- 2It sends the signing request to Connect.
- 3Connect issues an X.509 certificate for the public half.
- 4The superior publishes that key set in the subordinate statement.
The private half goes to the holder's service, as a deploy secret.The declaration names the holder for each entity: the catalogue for every agent, and a named service or party for the rest. Deployment evidence
- 1The deploy tool generates a key pair for the holder.
- 2The setup tool registers the public half on the record.
- 3Connect issues no certificate.
- 4Connect publishes the public key as it stands, and both ends compute the key identifier as its digest.
The holder's service holds the private half, as a deploy secret.Connect receives the public half alone, and nothing is issued against it. Deployment evidence
- 1Connect hosts the entity configuration.
- 2The entity sends no signing request.
- 3Connect signs that configuration with a key Raidiam holds.
- 4The catalogue holds the authentication key on the agent's behalf.
Raidiam holds the signing key for this entity's configuration.This is the model the first three claims are not true of, and it runs on this estate. Deployment evidence
| What | The design | This showcase deployment |
|---|---|---|
| Anchor per domain | Give each trust domain its own signing key | Two domains, one federation key and one authority key Not observed on this tenant |
| Entity keys | Certify a signing request, register a supplied key, or host the entity | All three run here at once Deployment evidence |
| Vouched key set | Vouch only the keys the subject publishes | A statement about an entity whose organisation holds no key vouches the tenant's hosted entity signing key Not observed on this tenant |
RSA PS256
Signs subordinate statements, resolve responses and both anchors' entity configurations.
Published in the anchor and authority entity configurations. Deployment evidence
EC ES256
Signs attestations, and the Quillon agent's entity configuration.
Published in the attester's attestation key set and in the agent's own configuration. Deployment evidence
Lattice ML-DSA-87
Not switched on in this tenant. The keystore serves one RSA key, and every statement here is signed classically.
The capability lives in Raidiam Connect: the keystore can publish a post quantum verification key beside the RSA one, which is a setting of the deployment. Available Raidiam Connect
What rebinds when a key is replaced
Each row is the act: who replaces the key and what has to rebind afterwards. The line under it says what this tenant has done.
-
Anchor signing key
Who replaces it
Raidiam, on the customer's instruction
What rebinds
Every consumer's pinned configuration. The anchor publishes both keys for an overlap window, and each consumer adds the new key identifier before the old one retires.
On this tenant: This tenant publishes one anchor key, and an overlap has yet to be exercised. Deployment evidence
-
Authority signing key
Who replaces it
Raidiam
What rebinds
The anchor's statement about the authority, signed again with the new key in the authority's key set. Consumers see it at their next resolve, inside the statement lifetime.
On this tenant: This tenant publishes one authority key. Deployment evidence
-
Entity keys
Who replaces it
The entity's operator, with a new signing request
What rebinds
Connect issues a new certificate, and the subordinate statement carries both keys for the overlap.
On this tenant: Raidiam's setup tool sends each signing request, from the estate declaration. Deployment evidence
-
Agent keys a party's own root vouches
Who replaces it
The party
What rebinds
The party's root publishes the new key in its statement about the agent. Connect receives nothing.
On this tenant: Raidiam's tools hold each of these keys. Deployment evidence
-
Supplied public keys
Who replaces it
The holder
What rebinds
The holder registers the new public key, Connect publishes both, and the holder retires the old one.
On this tenant: One supplied key for each recognised root and for each resource that holds its own. Deployment evidence
-
Attestation key
Who replaces it
The attester
What rebinds
The attestation key set carries both keys, and attestations already issued verify against the old key until they expire.
On this tenant: One attestation key today. Deployment evidence
-
Instance keys
Who replaces it
Each instance
What rebinds
A new key is a new instance, and it is attested afresh.
On this tenant: A copy on a workstation keeps its key on disk between runs. A new key there is a new instance. Deployment evidence
-
SVIDs
Who replaces it
SPIRE, on its own lifetime
What rebinds
The next binding proof uses the new SVID.
On this tenant: One hour, read from the SVID. Deployment evidence
This deployment
- Trust anchor
- Two anchors, each pinned from configuration
- Key storage
- A key management service Raidiam operates
- Certificate format
- X.509, issued from a signing request
- Rotation
- One anchor key published, no overlap run yet
- Deployment
- Raidiam operated, from one manifest
Where these keys are used
-
Identity where the software runs
A running copy generates its key in its own process. The attester binds that key in the attestation, and an SVID lives one hour.
Deployment evidence Read the runtime patterns -
Operated from one manifest
Every service on this estate, including the hosts that stand in for a third party, is deployed and operated by Raidiam from one manifest.
Deployment evidence How Connect is deployed -
Every claim, with its artefact
Observed, deployment evidence, available, or not observed on this tenant. Each row links what it was read from.
Open the evidence rows
Which of your signing keys would stay in a boundary you operate, and which would a tenant hold?
Ninety minutes, on the shape of your estate: which systems resolve first, which anchor each pins, and which key each party holds.