Key lifecycle: creation, rotation and revocation
Development status: Planned — The planned design would allow cryptographic keys to be created, rotated and revoked under policy, with hardware-backed custody; this is not yet implemented. A managed lifecycle for keys used in confidential computation is part of the design being explored, and the experimental prototype only simulates key handling for it, so no data is protected by those keys. Nothing is publicly available for live use.
Before you read: Identity, keys and access: concepts.
How would keys be created, rotated and revoked, including keys used for confidential computation? The planned design would manage keys through a lifecycle — creation, rotation and revocation under policy — with hardware-backed custody. None of this is implemented. Keys for confidential computation are a separate case with a different status: a managed lifecycle for them is part of the design being explored, and the experimental prototype only simulates their handling. This page explains the planned stages, what hardware-backed custody is intended to add, and the lifecycle events that applications, organisations and operators should expect to plan around.
Why keys need a managed lifecycle
Keys are long-lived secrets. Over time they may be exposed or lost, or need replacing when people or devices change. Without agreed rules, each of these events has to be handled on the spot, under pressure.
A managed lifecycle defines how keys come into use, are replaced and are withdrawn, under rules set in advance. Keeping identity separate from keys is what would let keys change without changing who is acting; see Participant identity.
The planned lifecycle
Status of this section: Planned — not implemented.
The planned lifecycle has three stages, all governed by policy:
- Creation — keys would be created under policy.
- Rotation — keys would be replaced by new keys under policy, on a schedule or after an event.
- Revocation — keys would be withdrawn from use, for example after a suspected compromise.
The policy behind these stages would be set in advance; its content is not described. None of this is implemented.
Hardware-backed custody
Status of this section: Planned — not implemented.
In the planned design, keys would be held in dedicated hardware designed to protect them, rather than in ordinary software storage. The intention is that a key’s protection should not depend only on the software and systems around it.
Which keys this would apply to, and who would operate such hardware, is not described. For the separate question of how an organisation could choose who holds the keys behind its funds, see also Custody options for organisations.
No hardware-backed custody exists in the experimental implementation, and key handling there must not be relied on for security.
Keys for confidential computation
Status of this section: Being explored; simulated in the experimental prototype — no data is protected by these keys today.
- Confidential computation would rely on keys that protect data while it is processed; see Confidential computation.
- A managed lifecycle for these keys — generation, rotation and revocation — is part of the design being explored.
- The experimental prototype only simulates key handling for confidential computation, so no data is protected by these keys today.
- Key types, how they would be controlled, and their parameters are not described.
Lifecycle events to plan around
Status of this section: Planned — conditional guidance; nothing here can be exercised today.
Once this capability is implemented, enabled and publicly released, applications, organisations and operators would need to plan around these lifecycle events:
- Rotation. A key may be replaced while the identity it acts for stays the same. Applications should not depend on any one key staying in use — for example, they should not treat a particular key as a permanent stand-in for an identity.
- Revocation. How quickly a revocation would take effect, and how others would learn of it, is not described, and no immediate-revocation property is claimed. Applications should not assume that a withdrawn key stops being usable at any particular moment.
- Loss. Whether an identity can continue after losing keys would depend on a recovery path arranged in advance; see Participant identity.
- Responsibilities. Organisations would set key policies and choose custody arrangements. Operators would follow whatever key-handling requirements accompany a release; none is published.
Assumptions, trust and limitations
- Hardware-backed custody would rely on the hardware and on whoever operates it. These trust assumptions are not yet described; the categories of trust roots this documentation uses are covered on Cryptographic foundations and trust roots.
- No rotation frequency, revocation timing or key-protection property is published.
- Key handling in the experimental prototype must not be relied on for security, and key handling for confidential computation there is simulated.
Not yet available, and how this page will grow
Key types, procedures and requirements would accompany a supported release. Further technical reference is not yet available. Open questions — such as how rotation would affect data already protected under earlier keys — are recorded for research on Assumptions and open questions. The page label and block labels would change only with evidence of implementation and release.
What this page does not claim
This page does not describe any key type, algorithm, parameter, rotation interval or procedure, and it names no custody provider. It claims no protection guarantee, and it does not claim that any key in the experimental implementation is protected or hardware-backed. Anything not stated here as available should be treated as unavailable.
Related pages
- Participant identity — why keys can change without changing the identity, and pre-arranged recovery.
- Custody options for organisations — who would hold the keys behind an organisation’s funds.
- Confidential computation — the capability whose key handling is simulated today.
- Cryptographic foundations and trust roots — categories of cryptography and trust roots that key handling would rest on.
- Assumptions and open questions — where open research questions about key rotation are recorded.
Glossary
References
No approved public references yet.
