Key ceremonies and KMIP

Mental model

A key ceremony is a procedure in which a root CA key is generated in front of witnesses, following a strict script. In the move from RSA to ML-DSA the general structure of this procedure (witnesses, script, video recording, M-of-N control) does not change; what changes are the physical and time assumptions of some steps inside the script.

What concretely changes

Key and signature size affect physical media planning. An ML-DSA-65 public key is 1952 B^SOURCED, many times a comparable-strength ECC key (64 B^DERIVED). A ceremony script usually includes steps for transcribing key fingerprints by hand or writing them to backup media (smart cards, USB tokens); the capacity and time assumptions of these steps must be reviewed before being copied from old scripts written for RSA/ECC.

Entropy consumption. Lattice-based key generation (ML-DSA, ML-KEM) consumes more randomness per operation than ECC key generation. Making sure an HSM’s random bit generator (RBG) can meet that demand is a new item to add to the pre-ceremony checklist.

The general structure of the ceremony does not change. Witness requirements, M-of-N access control, video recording and script approval stay the same; this is not a “PQC changes everything” story but a story of updating a specific, limited set of physical and operational assumptions.

Backup and export procedures. The step of exporting a key from an HSM by splitting it into shares (M-of-N secret sharing) is also affected by the size difference: the physical format each share will be written to (paper, smart card, USB token) may have been designed for RSA-4096’s key of a few hundred bytes; the same format and capacity assumptions must be tested in advance for ML-DSA-87’s much larger private key. This is another concrete example of why a ceremony script cannot be updated by “copy and paste”; whether each step really works with PQC sizes must be verified with a rehearsal before the real ceremony.

KMIP: progressing, but still a draft

KMIP (Key Management Interoperability Protocol) is a standard language for HSMs and key management systems to talk to each other. For PQC support, KMIP v3.0 defines two new operations (Encapsulate and Decapsulate, the same logic as the new functions in PKCS#11 v3.2) and adds a KEM Algorithm enumeration (including the ML-KEM-512/768/1024 variants). But unlike PKCS#11 v3.2 in the previous lesson, KMIP v3.0 has DRAFT2026-07-14 status: it is still at the Committee Specification Draft (CSD02) stage, not a fully approved OASIS Standard.

The difference matters: telling an architect “KMIP already supports PQC” carries a different certainty claim from “the draft of KMIP’s next version defines PQC support, but it is not final yet”. When planning key management system integration, the uncertainty about when this draft will be final must be carried openly; it is the “draft and final are different” discipline you see throughout this course, applied to KMIP.