What this implementation is
The executable alpha turns a bounded part of Research Framework v1 into running code. It is a research vehicle for testing request semantics, policy resolution, broker enforcement, provider execution, lifecycle behavior, evidence and explicit failure. It is not production middleware or proof that two independent systems interoperate.
Request-to-execution path
Implemented coverage
| Area | Current executable evidence | Claim boundary |
|---|---|---|
| Policy and broker | Policy-bundle evaluation, pinned decisions, tenant binding, capability and key-state checks | Local research policy; external provenance and rollback protection remain open |
| Signing | Ed25519 and ML-DSA-65 key creation, sign and verify | No HSM/KMS adapter or production key custody claim |
| Lifecycle | Same-profile rotation and Ed25519-to-ML-DSA-65 successor transformation | Transformation creates new key material; it does not convert a private key |
| Evidence | Separately signed execution records and standalone verification | No durable append-only store or trusted production anchor |
| Idempotency | Conflict and replay behavior within one broker process | Not restart-safe or distributed |
| Apache case | Local RSA-2048 to ML-DSA-65 certificate selection, config validation, graceful reload and new TLS handshake | Local test environment; not public-Web ecosystem interoperability |
| Alpha vectors | Five candidate vectors exercise ML-DSA, negative verify, rotation, transformation, conflict and evidence checks | One named implementation; not independent conformance certification |
Alpha conformance evidence
The repository includes a candidate CALI Alpha Reference Conformance v1 definition, vectors and executable runner. The current report records five passing vectors. Passing establishes behavior of the named repository commit and environment. It does not establish cross-implementation interoperability, production security, formal correctness or certification.
.venv/bin/python implementation/conformance/run_conformance.pyThe strongest next test is an independent implementation executing the same positive and negative vectors without private coordination.
The application contract
An application integrates once with an intent such as application-authentication. It does not own provider selection or scatter algorithm names through business code.
const result = await cali.sign({
intent: 'application-authentication',
expectedPolicy: { profileId: 'workload-signing', profileVersion },
keyRef,
message,
});The policy authority can move that intent through RSA, ECC, overlap and ML-DSA profiles while the call shape remains stable. Protocol and verifier compatibility still require coordinated engineering.
Classical starting points
RSA-PSS and ECDSA P-256 illustrate two common starting states. A CALI inventory record should capture algorithm profile, key provider, key usage, certificate or public-key distribution, verifier population, performance limits and owner.
{
"intent": "application-authentication",
"currentProfile": "ecdsa-p256-sha256",
"keyRef": "key_ecc_generation_12",
"verifiers": ["gateway", "partner-api", "audit-replay"],
"migrationTarget": "mldsa-65"
}ECC to ML-DSA: what actually changes
The migration does not convert an ECC private key. It creates a new ML-DSA key under an approved provider, distributes the new public verification material, enables an overlap policy, observes verifier readiness, changes the preferred signer and later retires ECC signing while retaining verification for the required historical window.
Find every signer, verifier, certificate, format, size limit, provider and owner.
Generate a new ML-DSA-65 key. Keep both private keys opaque and provider-bound.
Publish ML-DSA verification material and validate protocol, message, storage and observability limits.
Use an explicit overlap profile. Never interpret ML-DSA failure as permission to sign with ECDSA.
Disable ECC signing, preserve verification as policy requires, then destroy or archive keys under lifecycle policy.
Migration policy example
{
"profileId": "workload-signing",
"profileVersion": "2026-08-pqc",
"decision": {
"sign": "mldsa-65",
"verify": ["mldsa-65", "ecdsa-p256-sha256"],
"fallback": "forbidden"
},
"validUntil": "2026-12-31T23:59:59Z"
}Signing is ML-DSA-only after activation. Verification accepts both formats during the explicit historical compatibility window. This is coexistence, not silent fallback.
PQC engineering checks
- Validate signature, public-key, certificate and message sizes end to end.
- Test HSM/KMS/provider support rather than trusting an algorithm list.
- Measure latency and throughput with the actual provider and workload.
- Confirm parsers, schemas, databases, logs, queues and gateways accept larger artifacts.
- Coordinate verifier and protocol support before changing the signer.
- Preserve rollback as an explicit policy version, never an automatic algorithm downgrade.
Provider adapter responsibilities
Adapters translate a resolved CALI operation to OpenSSL, JCA, PKCS#11, KMIP, a cloud KMS or another provider. They must preserve non-exportability, usage constraints, error detail and algorithm identifiers. An adapter must not substitute a mechanism because the requested one is unavailable.
Apache RSA-to-ML-DSA case study
The reference service now implements SelectCertificate. An Apache deployment helper asks the broker for a certificate reference. It does not choose a certificate from the file system.
The latest local case begins with Apache presenting an RSA-2048 certificate. Strict CALI policy selects an already available ML-DSA-65 certificate, Apache configuration validation returns Syntax OK, the server gracefully reloads, and a new local TLS handshake presents ML-DSA-65. The standalone verifier accepts the signed selection evidence.
This is certificate selection and deployment, not certificate issuance. ACME or another CA workflow must obtain, renew and revoke certificates. The result is bounded to the local Apache/OpenSSL environment and does not prove browser, client or public-PKI interoperability.
sh implementation/examples/apache-login-pqc/run_demo.shRead the policy and broker walkthrough
Current limitations
Production identity, durable key storage, restart-safe idempotency, signed external policy distribution, rollback protection, HSM/KMS adapters, CA enrollment, production ACME orchestration, ML-DSA-44 execution, encryption/MAC/KEM execution, independent interoperability, formal verification and production performance evaluation remain unimplemented.