PQ-future of CCF

[maxtropets]

Post-Quantum Support

This page defines the target shape for post-quantum support in CCF, not the current state of it.

Goals

The target design provides post-quantum safety for user-to-node TLS, node-to-node communication, ledger signatures, receipts, endorsements trust chain, member governance signatures, and user and member certificate authentication.

Identity type disclaimer

Identity references use identity_type, not type-agnostic IDs.

• identity_type is a CCF-specific enum, not the concrete crypto, e.g. ML-DSA-65 or EC384.
• It identifies the identity variant, not the purpose, but if needed, two enum values may still point to identities with the same crypto shape, although there are no use cases for this at the moment. E.g. ML-DSA-65-1, ML-DSA-65-2.

Reasons for that are:

• It allows a clear previous identity endorsement chain per type, so it is clear who endorses whom.
• It allows a straightforward upgrade story, where each node advertises the [T1, ..., TN] identities it requires, making it possible to tell them apart in order to create/share missing ones.
• It allows identifying them in attestation reports.

Switching to multiple identities

Service identity material is split by purpose, each purpose in its own identity_type-keyed table.
We bind identity_type to a purpose, and identities are not shared across purposes unless the same key material is deliberately reused.

service_info (public:ccf.gov.service.info) stays a single, identity-independent value.
It keeps the service-wide metadata (status, recovery_count, current_service_create_txid, service_data) and may also track endorsement versions, but no longer holds identity or key material.

The identities move into two new per-purpose tables:

KV map	Key (identity_type)	Value
signing_identity	0 = EC384, 1 = ML-DSA-65, ...	Identity
tls_identity	0 = EC384, 1 = ML-DSA-65, ...	Identity

Type	Schema
Identity	{ kind: Kind, bytes }
Kind	CCF enum, e.g. 0 = x509 raw key, 1 = cose key, 2 = jwk
identity_type	CCF enum, e.g. 0 = EC384, 1 = ML-DSA-65, ...

These tables hold only the public identity material. Private keys are stored the same way as today, in memory in NetworkState rather than in the KV.

All identity_types present in a purpose's table are used for that purpose. For example:

• For signing, the service signs with every identity_type in signing_identity.
• For TLS, the service offers every certificate in tls_identity, and the TLS protocol selects one according to the client's capabilities.

Nit. Users are mapped 1<->cert, so in order to get PQ TLS they'll need to have a PQ cert issued.

Node-to-node identity is separate

N2N is node-scoped, not service-scoped.
It is not listed in service.identity_bindings.

Current node identity state is split across node tables:

KV map	Key	Value
public:ccf.gov.nodes.info	node_id	NodeInfo
public:ccf.gov.nodes.endorsed_certificates	node_id	Service-endorsed node cert

Current NodeInfo already stores the node's quote, encryption public key, status, CSR, and public key.
The node_id is derived from the node public key.

The N2N migration should be orthogonal: eventually replace the custom N2N channel with a PQ-safe transport via QUIC.
The internal node communication identity shape is left opaque for now.

During a rolling N2N upgrade, new nodes join with the communication identity required by their config and old nodes retire.
Since this is internal node communication, there is no need to offer several N2N identities in parallel, and the complete transition design is to be sorted out later.

Introducing and removing identities

Identity material and purpose bindings are introduced or removed atomically.

• Join - nodes advertise the service identity types they support when they join
• Service create/recovery - the node sets them straight away in the KV, with a corresponding join policy

Join policy is also expressed in terms of service identity types and purposes.
It should distinguish required, allowed, and disallowed combinations.
If both EC and PQ signing are required, EC-only and PQ-only joiners are both rejected.
The concrete policy can be JSON/Rego.
The rollout shape mirrors the COSE-only ledger upgrade.

Stage	Purpose bindings / node config	Join policy	Effect
Before	EC -> [TLS, SIGN]	required EC -> [TLS, SIGN]	EC TLS and EC signing.
Policy upgrade #1	EC -> [TLS, SIGN]	required EC -> [TLS, SIGN]; allowed PQ -> [SIGN]	PQ signing identities may join, but are not mandatory yet.
Upgrade	new nodes use EC -> [TLS, SIGN]; PQ -> [SIGN]	same as policy upgrade #1	New nodes keep EC TLS and add PQ signing.
Retire old nodes	EC -> [TLS, SIGN]; PQ -> [SIGN]	same as policy upgrade #1	Nodes without PQ signing leave the network.
Policy upgrade #2	EC -> [TLS, SIGN]; PQ -> [SIGN]	required EC -> [TLS, SIGN]; required PQ -> [SIGN]	New EC-only and PQ-only nodes are rejected.
Completed	EC -> [TLS, SIGN]; PQ -> [SIGN]	same as policy upgrade #2	Network signs with both EC and PQ and keeps EC TLS.

Mixed identity periods are expected during the rolling update window.
This is an intentional design choice, not a temporary inconsistency.

If a joining node advertises an allowed identity type and the service does not have that identity yet, the identity must be created in the same join transaction.
The identity is then reused for future joiners of the same type, and its private material is shared with trusted nodes the same way service private material is shared today.
On recovery, the existing join policy is preserved.
On service creation, the initial join policy is operator-set in the current design; deriving it automatically from the configured service identities is still to be defined.

Previous identity endorsements

Only signing identities are endorsed.
Their endorsements are stored separately from the identity tables, keyed by identity_type, so each signing identity has its own continuity chain: a T1 identity endorses only the next T1 identity, and each type stays within its own chain.
TLS identities are not endorsed and have no continuity chain.
Signing identities are created on each service create/recovery, the same as the service identity today.

DR:    0         1         2         3

A:     A0 <----- A1 <----- A2
       ^  \
       +---+

B:                         B2 <----- B3
                           ^  \
                           +---+

Attestation

Today, CCF uses AMD SEV-SNP report_data as a node-identity binding:

0                                32                               64
+--------------------------------+--------------------------------+
| SHA256(node_public_key_der)    | unused (0-filled)              |
+--------------------------------+--------------------------------+

The rest of quote verification is separate: CCF verifies the AMD endorsements, the security policy in host_data, the measurement or UVM endorsements, and the TCB version.

With multiple identities, report_data should carry both the identity digest and the binding metadata:

0        7          16                                               64
+--------+----------+-----------------------------------------------+
| LAYOUT | RESERVED | DIGEST (zero padded if SHA-256)               |
+--------+----------+-----------------------------------------------+

Field	Meaning
LAYOUT	7-byte binding metadata: version, attestation type, identity_type, kind, purpose, algorithm suite, hash algorithm
RESERVED	9 bytes, must be zero
DIGEST	48-byte digest slot: SHA-256 digest followed by 16 zero bytes, or SHA-384 digest

LAYOUT is:

byte:    00 01 02 03 04 05 06
layout:  V  A  T  K  P  S  H

Field	Meaning
V	Binding format version
A	Attestation type: service or node
T	CCF identity_type
K	Identity material kind: key, cert, or another kind
P	Purpose or purpose bitmask
S	Signing or certificate algorithm suite
H	Hash algorithm

Examples:

identity material: DER bytes of EC service TLS certificate
A = service
H = SHA-256
K = cert
T = ec_p384
P = UserTLS
S = ecdsa_p384_sha384

DIGEST = SHA256(ec_service_tls_cert_der)

identity material: DER SubjectPublicKeyInfo bytes of PQ signing key
A = service
H = SHA-384
K = key
T = mldsa65
P = Signing
S = mldsa65

DIGEST = SHA384(mldsa65_signing_public_key_der)

For node join, attestation must bind the node identity used to request trust:

identity material: DER SubjectPublicKeyInfo bytes of node N2N TLS PQ key
A = node
H = SHA-384
K = key
T = mldsa65
P = N2N
S = mldsa65

DIGEST = SHA384(node_n2n_tls_mldsa65_public_key_der)

SHA-256 leaves 16 digest-slot bytes unused, so they must be zero.
SHA-384 consumes the whole 48-byte digest slot.
SHA-512 is not used because it would consume all 64 bytes of report_data.

The layout keeps 16 bytes for binding metadata and reserved space.
The verifier checks the digest and the metadata, so it can tell which identity type and purpose were attested.

Members and users

Members and users should mirror the current model.
Users use certificate authentication with PQ-enabled certificates.

Members use certificate authentication where needed, and governance messages are COSE-signed with PQ or composite COSE signatures.
Registering a new PQ-enabled cert creates a new user/member identity, same as any cert rotation today.

Member shares

For recovery shares, moving from RSA-OAEP to PQ is not a direct primitive swap. RSA-OAEP currently encrypts the raw share directly to the member's RSA encryption public key, and the member later decrypts that ciphertext with their RSA private key.

ML-KEM is different: it does not encrypt arbitrary share bytes. It encapsulates a shared secret to the member's ML-KEM public key. That shared secret must then be passed through a KDF and used with symmetric AEAD to encrypt the actual share.

For a real hybrid RSA+PQ design, we should not store independent RSA-wrapped and ML-KEM-wrapped copies of the same share, because either one would be sufficient to recover it and the weaker path would dominate. Instead, derive one share-wrapping key from both a classical RSA-protected secret and an ML-KEM-protected secret, then AEAD-encrypt the share once with that combined key.

This changes the stored share format from a single RSA ciphertext into a versioned envelope containing the RSA ciphertext, KEM ciphertext, KDF/AEAD metadata, nonce, ciphertext, and tag. It also requires corresponding member key-generation, registration, HSM/Key Vault, and recovery-tooling support.

Current platform and standards support

The standards RFCs/drafts possibly targeted by this design are:

• draft-ietf-lamps-pq-composite-sigs for Composite-ML-DSA X.509 certificates
• draft-reddy-tls-composite-mldsa for Composite-ML-DSA authentication in TLS 1.3.
• draft-ietf-jose-pq-composite-sigs for JOSE/COSE composite signatures.
• RFC 9881 for pure ML-DSA X.509 certificates.
• RFC 9964 for pure ML-DSA JOSE/COSE signatures.
• FIPS 204 for the ML-DSA algorithm itself.
• OpenSSL 3.5 ML-DSA key support and OpenSSL 3.5 ML-DSA signature support for implementation details.

CCF will target Azure Linux 4 and OpenSSL 3.5, so here is the list of what is currently supported and not supported:

• OpenSSL 3.5 supports ML-DSA keys and signatures.
• OpenSSL 3.5 supports ML-KEM, SLH-DSA, and TLS hybrid KEX.
• OpenSSL 3.5 does not support LAMPS Composite-ML-DSA certificates or Composite-ML-DSA authentication in TLS.

Azure Linux 4 confirmation

This was confirmed on Azure Linux 4 with OpenSSL 3.5, without SymCrypt yet.

Confirmed support:

• Pure ML-DSA-65 X.509 certificates can be generated, DER-parsed, and verified with X509_verify.
• ML-DSA-65 and SLH-DSA-SHA2-128s signatures can be generated and verified.
• ML-KEM-512, ML-KEM-768, and ML-KEM-1024 encapsulation and decapsulation work.
• TLS 1.3 can negotiate the X25519MLKEM768 hybrid group with an ML-DSA-65 server certificate, mldsa65 CertificateVerify, and client certificate verification.
• Composite ML-DSA X.509/TLS is not supported by this stock OpenSSL build. No provider composite algorithms are exposed, composite keymgmt/signature candidates cannot be fetched, and TLS rejects composite signature algorithm names. Without an EVP_PKEY keymgmt and signature provider implementation, X.509 and TLS have no composite primitive to use.

Composite certificates can be encoded, but stock OpenSSL 3.5 cannot use them as normal certificates.
OpenSSL has no Composite-ML-DSA key, signature, X.509, or TLS SignatureScheme support.
CCF therefore cannot ask OpenSSL to generate, verify, select, or present a Composite-ML-DSA certificate in TLS.

Composite COSE signatures are technically possible with stock OpenSSL 3.5, but not as one OpenSSL algorithm.
The JOSE/COSE draft reuses the LAMPS composite key and signature encoding, carried as AKP pub/priv bytes.
CCF can implement the draft combiner and use OpenSSL only for the ML-DSA and classical component signatures.
This is draft-compliant if CCF pins the draft version, labels, prehash, key encodings, and COSE algorithm values.

The component keys must still be a single composite key.
The drafts require fresh component key generation and forbid reusing those keys in other contexts or as standalone keys.
For certificate-backed identities, x5chain/x5c should refer to a LAMPS composite X.509 certificate.
Stock OpenSSL cannot create that certificate form, so this needs custom tooling or another provider/library.
It is not RFC-standard yet: RFC 9964 only standardizes pure ML-DSA for JOSE/COSE.

Path forward

Start with a PQ-only extra identity for RFC 9964 ML-DSA COSE signing.
Keep the existing classical identity and signature during migration.
For TLS confidentiality, enable OpenSSL 3.5 ML-KEM hybrid groups, starting with X25519MLKEM768.
Gradually move to PQ certs unless composites are possible.

Leave composite support for later.
Composite TLS depends on composite certificate and TLS signature support that stock OpenSSL does not provide.
For signing, require two COSE signatures for now: one classical and one ML-DSA.

[PallabPaul]

This is very detailed, thanks for writing this up @maxtropets! Whenever you have some time (not urgent at all) I had some questions based off of this and impacts to ACL. Also, some questions may be a bit naive or the answer may not be fully thought out yet and I am happy to brainstorm some solutions.

1. For a ledger that already exists (created years ago on EC only), how does it get a PQ identity? Does it only happen on the next recovery/ code upgrade, or can we add it to a running service through governance?
2. Recovery shares are wrapped to each member's encryption key. Is moving that to a PQ KEM in scope, or is it deferred to member key rotation / Azure Key Vault PQC (when it is available)? I didn't see it mentioned in the design.
3. When a receipt has two signatures (classical + ML-DSA), is that two separate COSE envelopes or one with two signers? Essentially trying to figure out what our SDKs will need to parse. Also, will a client have to verify both signatures, or is either one enough? I assume either, as it will be a hybrid approach for now.
4. The dual-signature scheme adds an ML-DSA-65 signature alongside the existing ECDSA one on every receipt/ledger entry. Have you measured the impact on ledger size, snapshot/recovery payloads, and consensus throughput? (I assume not yet and I am happy to help with these tests, especially within our infra) And is the classical signature dropped once PQ is enforced, or carried indefinitely?
5. After a ledger upgrades, old receipts are signed by the old EC identity and new ones by the new PQ identity. What does a client need to do to verify a receipt from before the upgrade and will the client have to walk the identity chain?

Thanks!

[maxtropets]

@PallabPaul thank you for reviewing.

1. For a ledger that already exists (created years ago on EC only), how does it get a PQ identity? Does it only happen on the next recovery/ code upgrade, or can we add it to a running service through governance?

It is supposed to be set via each node's configuration and joining them to the network, where the latter is described under ## Introducing and removing identities.

Via-recovery path would presume much simpler workflow, as it only starts from one fresh node with the desired config set.

2. Recovery shares are wrapped to each member's encryption key. Is moving that to a PQ KEM in scope, or is it deferred to member key rotation / Azure Key Vault PQC (when it is available)? I didn't see it mentioned in the design.

That's a very good point which I have initially missed. I have added ### Member shares to address that, although the design is currently vague and details to be defined. In this particular case it will also depend on which key material variants can be kept in AKV, etc.

3. When a receipt has two signatures (classical + ML-DSA), is that two separate COSE envelopes or one with two signers? Essentially trying to figure out what our SDKs will need to parse. Also, will a client have to verify both signatures, or is either one enough? I assume either, as it will be a hybrid approach for now.

We intent to produce N receipts, one per identity, each of COSESign1 type. Trusting each individual identity will be attestation-based.

4. The dual-signature scheme adds an ML-DSA-65 signature alongside the existing ECDSA one on every receipt/ledger entry. Have you measured the impact on ledger size, snapshot/recovery payloads, and consensus throughput? (I assume not yet and I am happy to help with these tests, especially within our infra) And is the classical signature dropped once PQ is enforced, or carried indefinitely?

I have done a bit of initial benchmarking some time ago, although it was very preview-ish Azure Linux 4 image, with no SymCrypt installed atm (still not there, actually).

We surely intend to do more, and are thinking of backup options like configurable signing interval per identity for larger/slower algorithms, although pure ML-DSA signing turned out to be of similar speed as ECDSA.

The other drawback could be serializing and replicating much more data due to signature size, but it could be also partially mitigated by signing intervals.

Furthermore, there are plans to rework the Merkle tree format to enable resigning older data with PQ, but this's currently TBD, although @achamayou may want to elaborate more on this.

5. After a ledger upgrades, old receipts are signed by the old EC identity and new ones by the new PQ identity. What does a client need to do to verify a receipt from before the upgrade and will the client have to walk the identity chain?

New ones are to be signed by both. The old EC identity will be still endorsed by the new one, and we will keep providing all signing keys per identity type.

Also can be addressed by the aforementioned Merkle tree tiling, as in resigned with PQ in blocks and serving PQ receipts even if the signature at a time wasn't PQ.