PQ-future of CCF

[Max (maxtropets)]

⚠️ This has been heavily modified in the current edit, here's the previous version.

---

Roadmap

In the current goals:

• Create new PQ-safe ledgers
• Recover existing ledgers to gain PQ safety

Not in the current goals:

• Live code update support for PQ elevation
  • Depends on a currently non-existent identity sharing protocol
  • Tracked in Flexible service identity rotation #8264

The rest of this document covers only the current goals.

What defines PQ safety

Each item has its own umbrella issue to track progress.

• The ledger is double-signed with CLASSICAL and PQ keys (ML-DSA signatures in CCF #7848)
• N2N is switched to TLS with PQ certs and hybrid secret exchange (PQ-safe TLS in CCF #8061)
• Server PQ auth: PQ TLS certs are used on the CCF (server) side (PQ-safe TLS in CCF #8061)
• Client auth is PQ-safe (no-issue-yet)
  • PQ user certs are accepted in TLS
  • Governance is COSE-signed with PQ keys
• PQ-safe member share encryption (no-issue-yet)

How it is achieved

• The CCF service gets an extra PQ cert in addition to the CLASSICAL one, which is currently EC with a 384-bit curve by default.
• CCF switches to using the service cert for server TLS, rather than node certs.
• The attestation format changes to describe key type|format|purpose, so users can retrieve the attested service TLS keys, and nodes can do the same on join and/or N2N TLS.
• The ledger is double-signed with PQ and CLASSICAL signing keys, which are a 1<->1 match with the public keys of the service certs.
• Service identity endorsements and trust chains are extended to support PQ signing keys too.
• All COSE-signed proposals must support PQ signatures. The simplest way is to switch to PQ COSESign1; signing with both may require ad-hoc additions.
• Member shares are undecided for now.
  • 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.
  • In addition, targeting a combined ML-KEM + OAEP scheme would require a second ciphertext and a secret combiner, so that it remains resistant if one key is leaked or compromised.

Migration

• There are no plans to support a CLASSICAL+PQ -> CLASSICAL downgrade.
• New ledgers will start with the corresponding PQ config option enabled, and will serve their PQ identity in the same manner as the CLASSICAL one.
• Existing ledgers can be DR-ed in the same way with the corresponding new recovery config option.

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.

Links

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

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.

[Pallab Paul (PallabPaul)]

This is very detailed, thanks for writing this up Max (@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!

[Max (maxtropets)]

Pallab Paul (@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 Amaury Chamayou (@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.

[Max (maxtropets)]

Re: Switching to multiple identities

After moving forward with the implementation, several limitations came up. Let’s define them first:

• Creating a new service key anywhere other than during single-node network creation is currently impossible without storing signing keys in the ledger.
  • There is no rollback-safe way to distribute them, which directly conflicts with the proposal’s on-join identity creation.
• Adding and removing identities freely is a no-go, as identities could have intermittent lifetimes within the same epoch until the next DR.
  • The endorsement chain becomes a mess. There is no well-defined “previous” identity because gaps may exist, meaning some transactions may have no previous identity.

My current thinking is to make the following changes:

• Switch from distributing the key itself to distributing a secret from which the key is derived, potentially one per identity type to avoid cross-vulnerabilities, but it's up to discussion
• Support only adding new identities for now, which fully covers the EC -> EC+PQ case.
• Drop flexible policies for N identity types and use a COSE-style switching mechanism, with each node having a baked-in identity choice.

This allows:

• Live code updates without availability issues.
• Relatively simple identity endorsement changes:
  • Identities can now be endorsed on non- create-service  transactions.
  • They still cannot be endorsed more than once per epoch. Gaps are unsupported; only monotonic presence is allowed.
  • Therefore, chain reconstruction remains unambiguous, and strict gap validation can be retained.