Mode 2 — PKI Drop-in
Mode 2 is for existing PKI consumers that need to migrate from single-party keys to threshold keys without touching the application layer. The application keeps talking PKCS#11, OpenSSL, JCE, or a TLS callback — Confium translates every operation into a threshold session behind the scenes.
When to choose Mode 2
- You have an existing TLS terminator, code signer, document signer, KMS, or HSM-backed service.
- You want threshold-key security without rewriting the consumer.
- You want to migrate to post-quantum algorithms via composite signatures.
The integration surface
Confium ships four adapters:
| Adapter | What it speaks | What it replaces |
|---|---|---|
confium-pkcs11-server |
PKCS#11 v3.0 | HSM |
confium-openssl-provider |
OpenSSL 3.0 provider | OpenSSL EVP_PKEY backend |
confium-jce-provider |
JCE provider | Java KeyStore / Cipher / Signature |
confium-tls-signer |
TLS 1.3 signature callback | TLS private-key operations |
Each adapter exposes the standard API; under the hood it dispatches to a Confium coordinator that runs a threshold session per operation.
Deployment shape
[ Existing consumer ] --- PKCS#11 / OpenSSL / JCE ---> [ Confium adapter ]
|
v
[ Coordinator ]
|
[ Party 1 ] [ Party 2 ] [ Party N ]
The consumer doesn’t know about threshold keys, quorum, or sessions.
It calls C_Sign() (or EVP_DigestSign(), or Signature.sign())
and gets back a signature. The adapter handles the rest.
Post-quantum migration
Mode 2 is the natural home for PQ migration via composite signatures:
- The deployment adds an ML-DSA-65 component to the existing classical algorithm (Ed25519 or ECDSA-P256).
- The composite signature is published alongside the existing single-algorithm signature.
- Upgraded verifiers check both components; legacy verifiers check only the classical component and continue to accept.
- Once all verifiers are upgraded, the classical component can be removed.
This is a software upgrade, not an HSM replacement. No new hardware, no re-issuance of every certificate, no flag day.