From Theory to Practice: Real-World Lessons in Post-Quantum Cryptography Migration NISHIKAWA, Akihiro Cloud Solution Architect, Microsoft 

Seven acts, because app crypto is broader than TLS Agenda Act 1: Why migration starts now Act 2: Java platform reality Act 3: Inventory Act 4: Evidence Act 5: Five migration tracks Act 6: From handshake proof to production proof Act 7: Rollout plan All commands, code points, worksheets, and vendor questions: Appendices A–P 

Migration is not one switch – it is five tracks PQC (Post-Quantum Cryptography) • Algorithms that run on today's computers, built to resist future quantum attacks 5 tracks • Track T: TLS and HTTPS key exchange • Track S: signed/encrypted objects – JWT, CMS, key wrap • Track C: certificates and PKI • Track K: KeyStores, HSMs, KMS platforms • Track P: partner protocols AS2, AS4 Five tracks, five definitions of done. 

Monday: one service, one inventory, one reversible pilot One pilot you can start. Five tracks you will not forget. • Pick: one real Java service • Find: its cryptographic touchpoints • Sort: each one into a track • Name: the five fields from Act 3 • Choose: one reversible Track T pilot 

Act 1 The clock has already started 

Public-key crypto breaks first, not AES or SHA-2 Not every algorithm changes. Find every public-key decision point At risk: RSA, Diffie-Hellman, ECDH, ECDSA (public-key crypto) • They agree keys, sign messages, prove identity Not the first target: AES, SHA-2, SHA-3, HMAC (symmetric and hashing) • Review key sizes and policies 

A customer case: the runtime was never the bottleneck cryptographic touchpoints Java versions 3,000+ 4 (17, 11, 8, even 7!) • Libraries, keys, certificates, and integrations sat outside the obvious security module; ownership was fragmented. • No JDK release can find an owner, update a partner agreement, rotate a key, or confirm that a production path changed. 

Lead time, not one deadline No single date fits every Java system. • NIST, NSA, and UK NCSC publish for different scopes. Their work spans this decade and the 2030s. • Your date = system + data lifetime + jurisdiction + regulator • Plan backwards from the date the system must be ready • Month one is discovery, ownership, vendor checks, partner dialogue • NIST IR 8547 remains an Initial Public Draft dated 12 November 2024. • CNSA 2.0 primarily applies to US National Security Systems. • NCSC milestones are UK guidance. 

Confidentiality and authenticity run on different clocks Do not choose. Sequence them. Confidentiality – “How long must data stay secret?” • Harvest Now, Decrypt Later • Hybrid TLS 1.3 = clear first pilot • Rank by secrecy lifetime, not convenience Authenticity – “How long must identity stay trusted?” • Forged certs, JWTs, receipts • Certificate and signature migration answers this • Own deadlines, own plan 

Act 2 JEP 527 moves TLS, nothing else 

JEP 527 integrates only TLS – the rest stays your work Not “Does Java support PQC?” but “which surface, which use case, which build?” Building blocks • ML-KEM · ML-DSA · KDF – ingredients, not a migration Protocol integration • JEP 527: hybrid TLS 1.3 key exchange in SunJSSE 

The wire format and the JDK are final But your route is not yet proven. RFC 10024 • Standardises three ECDHE-MLKEM groups. No longer a draft. JDK 27 • JEP 527 delivered. Generally available since September 2026. Oracle LTS roadmap • JDK 8–25 PQC updates, first target 20 October 2026 – still planned as at 25 September 2026, not deployed. 

One hybrid handshake: break both, or break nothing Three groups, one idea: a classical curve + ML-KEM X25519MLKEM768 (listed first in SunJSSE) SecP256r1MLKEM768 SecP384r1MLKEM1024 • Client offers the hybrid group; server may select it • New sessions gain a post-quantum component • Record protection unchanged – normal TLS 1.3 authenticated encryption (AEAD) 

Both secrets feed one HKDF input One combined input. Both parts must fail. 🖥 Client 🌐 Server 1. ClientHello offers a hybrid group (e.g. X25519MLKEM768) 2. ServerHello selects the group and returns a hybrid key share 3. Each side derives both shared secrets, then concatenates them: ML-KEM || X25519 4. HKDF takes that one combined input and derives the handshake secret For X25519MLKEM768: K_combined = K_MLKEM || K_X25519 Note: The exact order is group-specific. The other two groups, SecP256r1MLKEM768 and SecP384r1MLKEM1024, put ECDHE first. 

JDK 27 offers hybrid first, but a default is not proof The classical fallback needs an owner and an end date. A default says what the runtime may do. Focused proof says what one real route did, at the boundary that terminates it. • Hybrid keeps a classical component while adding a post-quantum one • Start from a stable TLS 1.3 baseline; TLS 1.2 is a separate problem • JDK 27 SunJSSE lists X25519MLKEM768 first by default • Keep x25519 during rollout, with an end date 

Act 3 Nothing moves before it is found 

Cryptography is hidden in application systems • Framework defaults, HTTP clients, database drivers • KeyStores, TrustStores, JWT signing • Security sets policy. Platform ships approved providers • Application teams know which change breaks production • Migration is shared work 

Four layers surface the crypto that code search misses Make each layer a search you can run before lunch. 1. Dependencies – crypto libraries and TLS implementations 2. Source – crypto calls and algorithm strings 3. Config – KeyStores, TrustStores, TLS settings, endpoints 4. Runtime and evidence – focused proof from the route or object → Act 4 Record five fields • track, owner, control point, behaviour, evidence 

Demo 1: four layers on one small Spring Boot service src/main ├── java/com/example/pqcdemo │ ├── config │ │ └── SecurityConfig.java │ ├── controller │ │ └── ApiController.java │ ├── PqcDemoApplication.java │ └── service │ ├── EncryptionService.java │ ├── HmacService.java │ ├── JwtService.java │ └── LicenseService.java └── resources ├── application.properties └── keystore.p12 

One small service, 22 crypto touchpoints Only four were visible from a quick look at the code, but... Quantum vulnerable 5 Need review Low risk Total 14 3 22 (in this demo) 

Act 4 Layer 4 in depth — only executed evidence counts 

3 different claims: capability, configuration, and evidence Do not mix the three. Capability – What can this exact platform do? Supported protocols, cipher suites, and named groups Configuration – What does this process ask for? JVM flags, java.security policy, per-connection settings Evidence – What happened on the real route? JFR telemetry, debug trace, approved capture Where TLS terminates outside the JVM, ask these three questions there. 

Only the live connection shows the real offer – and an offer is not yet the outcome A provider list is a gate, not proof. Then three places: launch, policy file, live connection. JVM flags – set at launch, owned by the platform team -Djdk.tls.namedGroups -Djdk.tls.client.protocols -Djava.security.properties JSSE properties – policy file, system properties, per-connection settings java.security entries such as disabledAlgorithms, plus values set on an SSLSocket or SSLEngine. Effective parameters – what the live connection really holds getSSLParameters(): protocols, cipher suites, named groups in order 

JFR telemetry proves TLS happened, not which group 

Demo 2: hybrid-only on both ends proves the group Close the gap: constrain both ends so only one outcome is possible. CLIENT SUCCESS PROVES SERVER Hybrid only X25519MLKEM768 Hybrid only TLS 1.3 was selected TLS 1.3 ClientHello offer + ServerHello selection = focused proof 

ClientHello ServerHello ClientHello offers it, ServerHello selects it – that is the proof 

JDK 27 Until JDK 28, the group lives in a debug trace, not in JFR JDK 28 

‘Ready’ starts at Level 3, and only per track Level 3 is the first level you may report 1. Capability – a provider list includes it 2. Configuration – a launch flag or property requests it 3. Focused proof – a handshake trace or a signed artefact shows it 4. Business proof – the real client or partner accepts it 5. Operational proof – monitoring, rollback, owner, expiry 

Act 5 One seam, five definitions of done 

Crypto agility means configuration, not code changes Keep algorithm policy in configuration, not in business code. • New and old data follow different rules during migration • Each stored format needs its own written coexistence rule • Every exception is written down, with an owner and an expiry Bad pattern • Algorithm names hard-coded in business logic Signature.getInstance("SHA256withRSA"); 

Policy in one file lets each track move on its own schedule Each track, its own schedule, one file. tls: • Separate modes by key-exchange-mode: hybrid migration track named-groups: [X25519MLKEM768, x25519] • Use standard names, complete transformations certificates: mode: classical • Keep TLS named-group order outside code application-signatures: mode: classical • Keep message-protection policy outside code message-protection: • Business code asks for a cms-smime-mode: classical-baseline use case; policy supplies provider: BC the rest 

Track T: a JDK upgrade is a route-level rollout Find the boundary before you measure. Track T pilot checklist ❶ Baseline: Start from stable TLS 1.3 ❷ Boundary: Find the real TLS termination point ❸ Evidence: Prove the selected group at that boundary ❹ Coverage: measured shares, not assumptions (Act 6) ❺ Recovery: Pilot one route / Rehearse rollback Edge termination: platform team / JVM termination: service team JDK 27: A routine upgrade may introduce a larger hybrid-first ClientHello. Treat the upgrade as a route-level rollout. 

Track S: protect the objects, not just the connection Every consumer, or it is not done. • Tokens, CMS messages, documents, encrypted fields • Signed: sign-new, verify-old-and-new during coexistence • Encrypted: encrypt-new, decrypt-old-and-new • Record creator, consumer, key, and how long old objects live • Done only when the real format works end to end – and rejects bad input 

Track C: certificates fix impersonation, not session secrecy A hybrid handshake is not a PQC certificate. • In TLS 1.3 the session key comes from the ephemeral exchange • An RSA or ECDSA certificate can still use the hybrid group • Certificates solve a different problem: future impersonation • Plan CA hierarchy, TrustStore, renewal, revocation, pinning, validation 

Track K: new keys are created, never converted Keys block every other track. • You cannot convert an RSA key into ML-DSA or ML-KEM • New keys, new aliases, new rotation schedule • Check the real path: key types, provider, rotation, backup, recovery, audit • Certificates, signatures, and partners all depend on keys • An RSA exception is one row in the exception register (Act 7) 

Track P: the message layer needs its own proof The partner gateway holds the second decision. • Another organisation is involved • Transport may follow Track T – the message layer is separate • Name partner, gateway, security profile, test artefact, fallback, cutover • AS2 and AS4 use different message-security stacks • Complete only when both organisations verify the new path 

The operating model transfers; the mechanism does not The operating model is reusable, not the handshake. • Choose a boundary. Name the owner. Agree the exit criteria • Run a small pilot. Collect proof. Compare with the baseline • Define rollback. Monitor exceptions • T proves a route; S proves a format; C proves a trust path • K proves a lifecycle; P proves a partner 

Act 6 A handshake is not production proof 

One handshake proves one path, one moment, one leg One handshake is not production. Three gaps in the proof – then three traps in the measurement. One path: not every route One moment: not every session One leg: not every boundary 

A split hybrid ClientHello fails as a timeout, not as a TLS error Gap 1/3 · Measure the whole handshake on the real route. classical X25519 share 32B hybrid share ~1.2kB(≈40x) (sizes from FIPS 203 / RFC 10024) ~1.5kB ClientHello > ~1,460B TCP segment limit (MSS) • The first TLS message may cross a segment boundary. • Old middleboxes may drop a split ClientHello. • No alert. No group. Just a timeout. • Measure timeouts as outcomes, not only SSLHandshakeException. 

One full handshake is not every session Gap 2/3 · “This handshake chose hybrid” – never “every resumed byte”. SunJSSE on JDK 27: psk_dhe_ke only. No psk_ke. No 0-RTT. • Fresh exchange picks hybrid: new 1-RTT traffic is covered • Ticket lineage: authenticity still depends on the old handshake • psk_ke elsewhere: another product, another rule • 0-RTT elsewhere: bytes protected by the PSK alone 

One request. Four TLS legs. Four owners of the truth. Gap 3/3 · Evidence belongs where TLS ends. • Client settings show what Java offered, not what the peer chose. CDN leg Gateway leg JVM as client JVM as server public TLS proof lives there its own handshake, its own proof the peer selects, not you the only leg where SunJSSE is valid evidence Prove one. Count all. focused proof of one handshake – coverage over every attempt 

Three traps make a clean dashboard mean nothing Missing data pauses expansion. It never authorises it. The empty denominator “Zero failures” – out of how many? Policy does not move existing traffic Old pools keep their old key exchange. Rollback is not free It is a repair action and a security event. 

Act 7 Expansion waits for evidence 

Discover in parallel, change in sequence Discover all tracks in parallel. Change one controlled boundary at a time • Track T first: one route already under your control • Track K discovery now – keys underpin everything • Track P early – bilateral agreement is slow Dependencies decide the order – not a template. 

No pilot expands until four gates pass No gate, no expansion. Gate 1 (L1 to L2): Scope – route, TLS boundary, owner, cohort Gate 2 (L2 to L3): Security – hybrid proven, classical fallback measured Gate 3 (L3 to L4): Compatibility – real clients finish real work Gate 4 (L4 to L5): Operability – baseline, thresholds, rollback A metric without a threshold is not a gate. 

Without continuous control, old algorithms come back quietly Passing the pilot is not the end. • The same evidence controls the next cohort • Watch negotiation, timeouts, and key lifecycle • Start-up and CI checks stop the drift back • Every exception: owner, reason, review date, expiry Yesterday's proof is today's control. 

Every PQC claim needs a track, a boundary, and evidence Track. Boundary. Evidence. • “Java supports PQC” – which track? • “The provider supports it” – which route or object? • “The partner is ready” – which profile, which test? A claim without executed proof is preparation, not completion. 

Expansion is earned, not scheduled Start on a decision. Expand on evidence. Plan five tracks. Change one boundary. Expand only on evidence. 

Slides and sample code are on these two links Presentations Sample code speakerdeck.com/logico_jp/confitura2026 github.com/anishi1222/find-crypto-usages 

Appendix 

Appendix map – which appendix answers which question Question Appendix What gates a Track T pilot? [A] Track T pilot worksheet Which feature release or Oracle LTS update changes which surface? [B] JDK release map What is final, draft, or still only planned today? [C] Status snapshot Where are the primary sources? [D] Sources What should we inventory, and what does the demo prove? [E] Four-layer inventory Which three views does Layer 4 need? [F] Layer 4 Which JVM flags and JSSE properties matter? [G] JVM flags and JSSE properties How can JDK 27 prove the selected group? [H] Selected-group proof What claim can we make at each evidence level? [I] Five-level evidence ladder What does a crypto-agile policy file look like? (application.yml) [J] Policy file What must one migration decision record contain? [K] Migration decision record What does done mean for S, C, K, and P? [L] Track S, C, K, and P checklists What are the exact Track T wire sizes, session modes, evidence sources, and operational caveats? [M] Track T production reference What should we ask vendors and partners? [N] Vendor and partner questions Which claims should we avoid? [O] Claim guardrails Which evidence word means what, and which x25519 spelling applies? [P] Evidence vocabulary 

[A] Track T pilot worksheet – entry criteria • Use this worksheet with the exact session, evidence, measurement, drain, and rollback notes in Appendix M. • Gate one in the main deck, scope, is covered by the entry criteria below; gates two to four expand into the six operational checks in the gate table on the next page. This worksheet is this deck's own model for a Track T pilot, not a published standard. Entry criteria • Identify the implementation that terminates each TLS leg. • Limit the pilot to a named route and reversible cohort. • Record the exact JDK/provider or product build and effective group, protocol, and constraint settings. • Choose the selected-group evidence source at the TLS boundary. • Define the handshake-attempt population. JFR on JDK 27 cannot supply this denominator or failed-attempt count; see [M] measurement, drain, and rollback. • Capture a comparable classical baseline using the same boundary, window, and failure definition. • Approve thresholds, pause authority, rollback authority, and maximum pause duration. • Rehearse rollback and measure how long it takes, including restart and connection drain. Back to Monday: one service, one inventory, one reversible pilot 

[A] Track T pilot worksheet – gate table Gate Example signal Pass condition Security outcome Hybrid selection coverage; classical-fallback share; any prohibited group or protocol Meets approved target; no prohibited outcome Evidence quality Selected-group evidence coverage; missing or conflicting records Meets approved minimum Compatibility Real client and critical workflow result Passes positive and required negative tests Reliability Handshake-failure rate, including timeouts with no TLS alert Within approved change from comparable baseline Performance p95/p99 handshake latency, CPU, memory Within approved deltas Operability Alert routing, owner, rollback, recovery check Exercised and within service allowance The gates and their thresholds are this deck's own model for a Track T pilot, not a published standard; they build on the evidence ladder in [I]. Back to Monday: one service, one inventory, one reversible pilot 

[B] JDK release map – what each release adds, and what it does not prove JDK release / surface Status as at 25 September 2026 Helps with Does not prove JDK 21: KEM API, JEP 452 Final standard API Standard API shape for key encapsulation Built-in ML-KEM or protocol migration JDK 24: ML-KEM and ML-DSA, JEP 496 / 497 Final Post-quantum KEM and signature primitives JWT, CMS, JAR, HSM, or partner interoperability JDK 24: KDF API, JEP 478 Preview in JDK 24 Standard key-derivation API shape A stable production API contract in JDK 24 JDK 25: KDF API, JEP 510 Final; finalises the JDK 24 preview Standard key derivation, including HKDF Protocol choice or rollout boundary JDK 27: JEP 527 Final; GA in JDK 27 Hybrid TLS 1.3 key exchange in OpenJDK SunJSSE Certificates, objects, keys, partners, or a productionsupported runtime in your environment JDK 28: JFR namedGroup EA; present from build b03 via JDK-8301626; no JDK 27 backport Named-group field in completed TLSHandshake events JDK 27 evidence, failed attempts, or resumption lineage Back to JEP 527 integrates only TLS – the rest stays your work 

[B] JDK release map – JEP 527 scope and default overrides • JEP 527 is scoped to OpenJDK's SunJSSE implementation in JDK 27. For any exact build, check separately: • a vendor JDK with different defaults or backports; • an application-installed JSSE provider; • an OpenSSL-backed or other native connector inside the JVM process; • a CDN, gateway, proxy, mesh, database, or broker that terminates a different TLS leg. • JDK 27 SunJSSE puts X25519MLKEM768 first in its default named-group list [JEP 527]. Existing settings can still change that: • jdk.tls.namedGroups process-wide, SSLParameters.setNamedGroups(...) per connection since JDK 20, jdk.tls.disabledAlgorithms and other algorithm constraints, or a protocol pin that holds either leg on TLS 1.2. See [G] for what each control sets and its JDK 27 default. • SunJSSE's hybrid implementation is internal to the TLS stack, so a provider list stays Level 1. See [I] for the ladder. • Production guardrail: JDK 27 is GA, but a vendor build, an early-access build, or a local rebuild may not be. Use any nonGA or unsupported build only for lab evidence. Repeat interoperability, route, performance, negative-path, and rollback tests on the exact supported GA or vendor build before production. Back to JEP 527 integrates only TLS – the rest stays your work 

[B] JDK release map – Oracle JDK LTS update roadmap Target date Oracle JDK line Planned addition 20 October 2026 25 Post-Quantum Hybrid Key Exchange for TLS 1.3; PKCS12 PBMAC1 support 20 October 2026 21, 17 ML-KEM and ML-DSA First half of 2027 21, 17 Post-Quantum Hybrid Key Exchange for TLS 1.3; PKCS12 PBMAC1 support Second half of 2027 11, 8 ML-KEM, ML-DSA, Post-Quantum Hybrid Key Exchange for TLS 1.3, PKCS12 PBMAC1 Second half of 2027 8 X25519 and X448 key agreement • PBMAC1 is KeyStore modernisation listed beside the PQC work; it is not a PQC algorithm. The Oracle configuration guidance says applications using javax.net.ssl are intended to benefit from the hybrid algorithms by default without code changes after the relevant update. Oracle encourages proactive testing before planned changes become defaults. Default capability is Level 1; see [I]. • These are Oracle JDK plans for Oracle-shipped providers, and can change with little or no warning [Oracle Cryptographic Roadmap, updated 3 July 2026]. As at 25 September 2026 the 20 October 2026 rows have not yet shipped; re-check the Oracle release notes after that date. They are not delivery dates for every JDK vendor, and API parity with later feature releases is separate. Oracle's configuration page links to JEP 527, but each older-line row is separate update work. Confirm the exact update release, provider, defaults, and release notes; do not assume the JDK 27 implementation is identical. Back to JEP 527 integrates only TLS – the rest stays your work 

[C] Status snapshot – standards and drafts Source Status as at 25 September 2026 Use it for Scope guardrail NIST FIPS 203 / 204 / 205 Final standards, 13 August 2024 ML-KEM, ML-DSA, and SLH-DSA Algorithms, not an application migration plan NIST IR 8547 Initial Public Draft, 12 November 2024; no later revision published Proposed transition and deprecation planning Draft guidance; not a universal obligation RFC 9846 Standards Track, July 2026; obsoletes RFC 8446 Current TLS 1.3 base specification, including PSK, resumption, and 0-RTT Does not define PQ/T hybrid groups RFC 9954 Informational, July 2026 Generic hybrid key-exchange construction for TLS 1.3 Does not assign concrete groups RFC 10024 Standards Track, August 2026 Three concrete ECDHE-MLKEM groups for TLS 1.3 Publication is Level 1; see [I] RFC 9881 / 9882 Standards Track, October 2025 ML-DSA identifiers for X.509 and CMS An identifier is Level 1; see [I] RFC 9935 / 9936 Standards Track, March 2026 ML-KEM identifiers for X.509 and CMS Same product-readiness guardrail RFC 9964 Standards Track, May 2026 ML-DSA in JOSE and COSE Every producer and verifier still needs testing draft-ietf-tlsmldsa-05 Internet-Draft dated 6 July 2026; IESG-approved, not yet an RFC; intended status Informational; expires 7 January 2027 ML-DSA signature schemes in TLS 1.3 Separate from RFC 10024, X.509 identifiers, and deployed interoperability Back to The wire format and the JDK are final 

[C] Status snapshot – vendor and policy Source Status as at 25 September 2026 Use it for Scope guardrail Oracle LTS PQC announcement Published 6 August 2026; current Oracle direction PQC across the supported Oracle JDK LTS lines: 25, 21, 17, 11, and 8 Directional commitment, not delivery or application-migration evidence Oracle JRE/JDK Cryptographic Roadmap Updated 3 July 2026; all PQC update-release entries remain planned as at 25 September 2026; the first target, 20 October 2026, has not yet been reached Oracle JDK release-line planning and early testing Plans can move; applies only to Oracle-shipped security providers CNSA 2.0 / CNSSP 15 Scope-specific US National Security System policy baseline; the primary CNSSP 15 document is not publicly retrievable, so the secondary reference used is NSA Post-Quantum Cybersecurity Resources, accessed 25 September 2026 US National Security System requirements Verify the current CNSSP 15 baseline directly UK NCSC 2028 / 2031 / 2035 milestones Guidance published 20 March 2025 and updated 3 August 2026; milestones unchanged Discovery, priority migration, and completion planning Apply the relevant jurisdiction and sector rules Back to The wire format and the JDK are final 

[C] Status snapshot – IANA hybrid groups Decimal Hex Group IANA Recommended flag 4587 0x11EB SecP256r1MLKEM768 N 4588 0x11EC X25519MLKEM768 Y 4589 0x11ED SecP384r1MLKEM1024 N • RFC 10024 assigns the IANA TLS Supported Groups values above; that registry was last updated on 10 August 2026 [IANA TLS Supported Groups registry, accessed 25 September 2026]. The Recommended flag is a registry property; see [I] for what it does and does not claim. Apply the policy and validated-module requirements that govern the route. • For public Web PKI, do not claim either universal readiness or universal impossibility. Verify the chosen CA product, certificate profile, chain, client TrustStores, browsers or runtimes, TLS stack, and route. A published X.509 identifier alone proves none of those. Back to The wire format and the JDK are final 

[D] Sources – standards and guidance • CSRC Topics - post-quantum cryptography | CSRC • FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard | CSRC • FIPS 204, Module-Lattice-Based Digital Signature Standard | CSRC • FIPS 205, Stateless Hash-Based Digital Signature Standard | CSRC • Black-box validation of Falcon key generation under numerical instability | CSRC • IR 8547, Transition to Post-Quantum Cryptography Standards | CSRC • NSA Post-Quantum Cybersecurity Resources • Timelines for migration to post-quantum cryptography | National Cyber Security Centre • RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 • RFC 9954: Hybrid Key Exchange in TLS 1.3 • RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 • IANA Transport Layer Security (TLS) Parameters Back to The wire format and the JDK are final 

[D] Sources – standards and guidance • RFC 9881: Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) • RFC 9882: Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS) • RFC 9935: Internet X.509 Public Key Infrastructure - Algorithm Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) • RFC 9936: Use of ML-KEM in the Cryptographic Message Syntax (CMS) • RFC 9964: ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) • draft-ietf-tls-mldsa-06 - Use of ML-DSA in TLS 1.3 Back to The wire format and the JDK are final 

[D] Sources – Oracle and OpenJDK • Post-Quantum Cryptography in Long-Term Support JDK Releases • Oracle JRE and JDK Cryptographic Roadmap • Configure Oracle's JDK and JRE Cryptographic Algorithms • JEP 452: Key Encapsulation Mechanism API • JEP 478: Key Derivation Function API (Preview) • JEP 496: ML-KEM • JEP 497: ML-DSA • JEP 510: Key Derivation Function API • JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 • JDK 27 project and schedule • JDK 27 early-access builds • JDK-8301626: Capture Named Group information in TLSHandshakeEvent All Oracle and OpenJDK pages accessed 25 September 2026 Back to The wire format and the JDK are final 

[E] Four-layer inventory – what to check and record at each layer • A match is a candidate, not proof of production use. No match is not proof of absence. Frameworks, reflection, native code, runtime configuration, and external termination can hide cryptography. The four layers are this deck's own model for organising discovery, not a published standard. Layer Representative checks Record 1 Dependencies Security frameworks, JSSE/JCE providers, database and broker drivers, KMS SDKs, JOSE/CMS/XML libraries, native TLS bindings Dependency, version, owner, expected use 2 Source KEM, KeyAgreement, Signature, Cipher, KeyStore, SSLContext, SSLE ngine, SSLParameters, and framework APIs Call path, format, algorithm, key source, track 3 Config KeyStores, certificates, named groups, protocol pins, algorithm constraints, partner endpoints, database TLS Control point, requested behaviour, owner, expiry 4 Runtime and evidence Effective parameters, real handshakes, serialised objects, certificates, and audit events Boundary, peer or consumer, observed behaviour, proof source Back to Four layers surface the crypto that code search misses 

[E] Four-layer inventory – what the demo proves, and what it does not • The repository includes 01-PQC/demo/crypto-audit-demo. The table below sets out its current evidence boundaries. • This is a discovery demo, not a production reference architecture. Track / touchpoint What the demo proves What it does not prove T: local inbound HTTPS The Spring Boot service starts over HTTPS and completes a request The selected group on a real route T: PostgreSQL TLS Configuration discovery finds database TLS settings; the demo profile excludes the DataSource A live database connection, effective sslmode, identity checks, or selected group S: JWT/JWS Nimbus issues and verifies RS256 tokens A post-quantum format or every-verifier interoperability S: CMS SignedData Payload and signature integrity using the embedded certificate That the signer is an authorised licence issuer S/K: Tink AEAD and HMAC Local AES-256-GCM and HMAC round trips Durable key storage, rotation, recovery, or multiinstance operation C/K: PKCS12 An RSA key, RSA-signed chain, and shared key entry are discoverable Production PKI, purpose-separated keys, HSM/KMS, renewal, or revocation P: partner protocol No path exists; the absence is recorded AS2, AS4, S/MIME, or a bilateral test Back to Four layers surface the crypto that code search misses 

[E] Four-layer inventory – commands that show capability, and what JFR cannot show • Useful commands: # From the repository root: cd 01-PQC/demo/crypto-audit-demo mvn clean package ./scripts/crypto-audit.sh . java scripts/CryptoAuditJce.java • CryptoAuditJce.java in this demo and CipherSuiteCheck.java in the sibling ciphercheck-demo show capability. • JFR can show completed TLS activity when the required events are enabled; for what it does not record on JDK 27, see [M] measurement, drain, and rollback. Back to Four layers surface the crypto that code search misses 

[F] Layer 4 – capability, configuration, and evidence Capability Capability answers what this exact build can offer. It proves availability only, never what a connection did. SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites() / .getNamedGroups() • Per socket: sslSocket.getSSLParameters().getNamedGroups() Configuration Configuration answers what this process asks for, JVM-wide or per connection. It proves intent, not the outcome. SSLParameters.setNamedGroups(...) java -Djdk.tls.namedGroups=... Evidence Evidence answers what the real route did. In TLS 1.3 the cipher suite does not identify the key-exchange group, and jdk.TLSHandshake on JDK 27 does not record it, so JFR proves that TLS happened, but not which group was selected. • JFR events: TLSHandshake / X509Certificate • From JDK 20, also: SecurityProviderService • Clear named-group proof: JSSE debug or an approved packet capture java -Djavax.net.debug=ssl:handshake:verbose ... Back to 3 different claims: capability, configuration, and evidence 

[G] JVM flags and JSSE properties – what each control sets and its JDK 27 default Every setting is the offer, not the outcome; defaults are from JDK 27 java.security and JSSE. Setting What it controls Default in JDK 27 -Djdk.tls.namedGroups Launch flag. Ordered list of key-exchange groups the process offers, for example X25519MLKEM768. Not set. The built-in group list and order apply. -Djdk.tls.client.protocols Launch flag. Protocol versions the client offers. TLS 1.3 is required for the hybrid group; a pin on either leg holds TLS 1.2. Not set. TLS 1.3 and TLS 1.2 are enabled. -Djava.security.properties Launch flag. Points at an override file. One equals sign overrides individual properties; two replace java.security. Not set. java.security ships with security.overridePropertiesFile =true, so an override file applies. jdk.tls.disabledAlgorithms java.security entry. Blocks protocols, cipher suites, and groups, whatever the application asks for. Not empty. Legacy algorithms are already blocked. jdk.certpath.disabledAlgorithms java.security entry. Blocks signature and key algorithms on the certificate path, so it reaches Track C before Track T. Not empty. Weak digests and small keys are blocked. -Djavax.net.debug=ssl:handshake Launch flag. Writes the ClientHello offer and the ServerHello selection – the evidence artefact. Not set. No handshake trace is written. SSLParameters.setNamedGroups() Per-connection API, JDK 20 and later. Sets the groups for one SSLSocket or SSLEngine. Null unless set. The JVM-wide list applies. SSLSocket.getSSLParameters() Per-connection API. Reads the effective protocols, cipher suites, and named groups actually offered. Read-only. Returns what this connection will offer. Back to Only the live connection shows the real offer – and an offer is not yet the outcome 

[H] Selected-group proof – Terminal A: server permits only the hybrid group • Start the server with only X25519MLKEM768 permitted, so a completed handshake on this route proves the selected group rather than a default. # From the repository root: cd 01-PQC/demo/PQC-enabled-SpringBoot-App mvn clean package # Set the keystore variables from the README first. export APP_TLS_NAMED_GROUPS="X25519MLKEM768" java -jar target/pqchybridtls-0.0.1-SNAPSHOT.jar --spring.profiles.active=tls Back to Demo 2: hybrid-only on both ends proves the group 

[H] Selected-group proof – Terminal B: client with a restricted debug sink • The client forces TLS 1.3 and offers only X25519MLKEM768. The server also permits only that group. A successful handshake therefore proves the selection. The debug log supplies the raw artefact. • --trust-all is for this local self-signed laptop demo only. For any real pilot, use an approved TrustStore and preserve hostname and certificate validation. # From the repository root: cd 01-PQC/demo/PQC-enabled-SpringBoot-App install -d -m 700 logs umask 077 java -Djavax.net.debug=ssl:handshake \ -cp target/classes \ dev.logicojp.example.pqchybridtls.client.HybridTlsClient \ --url 'https://localhost:8443/api/hello' \ --named-group X25519MLKEM768 \ --trust-all \ 2>logs/jsse-client.log Back to Demo 2: hybrid-only on both ends proves the group 

[H] Selected-group proof – Terminal C: the offer and the selection • Keep the ClientHello offer and ServerHello selection together. A ClientHello offer alone is not proof of final selection. • Treat the debug file as sensitive operational evidence. Obtain approval where required, restrict access, minimise the capture window, set retention, and verify deletion. Debug field names can change between builds, so retain the raw artefact and record the full java -version output. • At another boundary, use that product's selected-group log or an approved handshake-only packet capture; see [M] evidence by TLS boundary. # From the repository root: cd 01-PQC/demo/PQC-enabled-SpringBoot-App rg -i 'supported_groups|key_share|x25519mlkem768' logs/jsse-client.log Back to Demo 2: hybrid-only on both ends proves the group 

[I] Five-level evidence ladder – from capability to operational proof • The five-level ladder below is this deck's own model for grading evidence, not a published standard; each level names the proof it requires. Level Question Minimum proof Claim allowed 1: Capability Can this exact build support the algorithm or group? Release notes, provider documentation, local capability check Capability only 2: Configuration Is it requested and permitted at this boundary? Effective group list, protocol, provider, and algorithm constraints Configuration intent 3: Focused proof What did the real route, object, or key operation do? ServerHello selection, serialised identifiers, sign/verify result, or executed key operation Confirmed technical behaviour 4: Business proof Did the real workflow and consumer accept it? Critical-path end-to-end test Business-path compatibility 5: Operational proof Can the team observe, pause, reverse, and retire it? Coverage, thresholds, owner, rehearsed rollback, exception expiry One bounded production decision Back to ‘Ready’ starts at Level 3, and only per track 

[J] Policy file – one mode line per track keeps change and rollback configuration # Each block moves on its own schedule; the RSA-OAEP block is today's classical baseline, not PQC. tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519] certificates: mode: classical application-signatures: mode: classical message-protection: cms-smime-mode: classical-baseline provider: BC content-cipher: AES/GCM/NoPadding key-wrap: RSAES-OAEP oaep-digest: SHA-256 oaep-mgf: MGF1 oaep-mgf-digest: SHA-256 oaep-label: empty pqc-pilot-target: ML-KEM-based CMS recipient flow when provider and peers are ready legacy-verify-allowed: true Back to Crypto agility means configuration, not code changes 

[K] Migration decision record – minimum required fields • Use one record for one bounded route, object format, trust path, key path, or partner profile. Section Required fields Identity and scope Record ID, track, boundary or object, environment, route or consumer Ownership Technical owner, risk owner, control point, approval authority Risk and target Purpose, data sensitivity, confidentiality/authenticity lifetime, current state, target state, deadline Implementation Exact product, JDK, provider, build, key type, format, peer versions, and effective policy Evidence Positive and negative artefacts, source boundary, population or sample covered, timestamp, result, reviewer Gates Comparable baseline, approved threshold per metric, workflow pass definition Recovery Pause and rollback triggers, authority, procedure, measured time, recovery validation Closure Legacy retirement evidence, or a time-bounded exception with owner, reason, review date, and expiry • Minimum row: • record_id, track, boundary, technical_owner, risk_owner, control_point, current_behaviour, target_behaviour, evidence • Blank is not N/A. If an owner, control point, evidence source, or rollback path is missing, the decision is not productionready. Store the raw artefact, not only a parsed summary. The required fields are this deck's own model for a decision record, not a published standard. Back to Policy in one file lets each track move on its own schedule 

[L] Track S, C, K, and P checklists A published identifier, vendor roadmap, or signed agreement is preparation. Executed evidence on the real object, trust path, key operation, or partner workflow is proof. The per-track checklists below are this deck's own model, not a published standard. Track Transition rule Done means Minimum evidence S: signed objects Sign-new; verify-old-and-new during approved coexistence Every producer and verifier accepts the target; prohibited signers, keys, and formats fail; legacy production stops Producer/consumer matrix, positive and negative object tests, retirement record S: encrypted objects Encrypt-new; decrypt-old-and-new during approved coexistence New objects work; retained old objects remain readable only within policy; wrong recipient/key and prohibited formats fail Round trips, retained-object test, negative tests, retention decision C: certificates / PKI Introduce and distribute the target trust path alongside the old where supported Expected identities and purposes validate; expired, revoked, wrong-identity, and wrongpurpose credentials fail Chain, identity, lifecycle, pinning, and rollback tests K: keys / secrets Create new ML-DSA or ML-KEM key material; there is no conversion path from an existing RSA key Generation, activation, rotation, recovery, failover, coexistence, access, audit, destruction, and rollback pass Exact provider/HSM/KMS lifecycle and negative-path tests P: partner protocols Agree transport and message profiles before production change Both organisations pass the target profile; legacy works only during the approved window Bilateral artefacts, versioned profile, sign-off, runbook Back to Policy in one file lets each track move on its own schedule 

[M] Track T production reference – wire sizes • Hybrid TLS changes the TLS 1.3 key exchange. It does not replace the record-layer AEAD cipher, and it does not make the certificate post-quantum. Item ML-KEM-768 encapsulation key X25519 ephemeral share X25519MLKEM768 client KeyShareEntry.key_exchange Size 1,184 bytes 32 bytes 1,216 bytes Meaning Client-side ML-KEM public material Classical component 1,184 + 32 Separate classical x25519 client share 32 bytes Also sent by the default JDK 27 client for compatibility Two default JDK 27 client payloads 1,248 bytes Payloads only; +14 bytes key_share framing = 1,262 X25519MLKEM768 server KeyShareEntry.key_exchange 1,120 bytes ML-KEM ciphertext 1,088 + X25519 32 SecP256r1MLKEM768 Client 1,249 bytes Server 1,153 bytes Implemented, but not in the JDK 27 default list SecP384r1MLKEM1024 Client and server 1,665 bytes Implemented, but not in the JDK 27 default list • The two default client entries occupy 1,262 bytes once the key_share extension and entry framing are included. The complete ClientHello is commonly around 1.5 kB, depending on SNI, ALPN, cipher suites, and other extensions. It may exceed a common 1,460-byte TCP maximum segment size and span multiple TCP segments. Component key and ciphertext sizes are from [FIPS 203]; the hybrid group definitions from [RFC 10024]. The combined payload, framing, and ClientHello totals are this deck's own calculation from those sizes. Back to Track T: a JDK upgrade is a route-level rollout 

[M] Track T production reference – session and early-data paths Path Fresh key exchange Evidence needed for the claim New full handshake Yes Selected group on the completed handshake Resumed 1-RTT with psk_dhe_ke Yes Fresh selected group for confidentiality; PSK or ticket lineage and lifetime for resumption authenticity Resumed 1-RTT with psk_ke No PSK or ticket lineage for both confidentiality and resumption authenticity 0-RTT early data No server-selected fresh group before those bytes Offered PSK lineage and the product's early-data evidence Resumption modes and 0-RTT early data are defined by the TLS 1.3 base specification. [RFC 9846, sections 2.2 and 4.2.11] Back to Track T: a JDK upgrade is a route-level rollout 

[M] Track T production reference – session and early-data limits on JDK 27 • OpenJDK SunJSSE on JDK 27 offers psk_dhe_ke, not psk_ke, and does not implement 0-RTT [JEP 527; SunJSSE]. Confirm the exact provider and boundary before applying that statement to another product. • JDK 27 exposes neither PSK identity nor ticket lineage through a public API. JDK 28's JFR namedGroup field does not close that gap either: it carries the selected named group alone, so it proves neither PSK identity nor ticket lineage [JDK8301626]. Its population limits, including the completed-handshake-only scope that hides failed attempts, are set out on the measurement, drain, and rollback page in this appendix. • Stopping new ticket issuance does not invalidate tickets already held by clients. A bounded pilot must expose the relevant lineage, use approved focused evidence, or disable resumption and prove that old tickets have drained. Back to Track T: a JDK upgrade is a route-level rollout 

[M] Track T production reference – evidence by TLS boundary • Identify the implementation that terminates each leg before choosing the control or evidence source. Evidence from one leg, alternate route, or sample does not describe another. The boundary-by-boundary mapping is this deck's own model, not a published standard. Boundary Continuous signal Focused proof CDN, gateway, reverse proxy, load balancer Product selected-group, attempt, fallback, and failure metrics where available Product log or approved sampled capture JVM on JDK 27 SunJSSE Protocol/cipher baseline and service metrics; the JFR limits on the measurement, drain, and rollback page of this appendix apply Time-boxed JSSE debug or approved capture JVM on JDK 28 EA JFR namedGroup for completed handshakes in lab evidence Debug or capture where offer path, failure, or lineage matters In-process native or third-party TLS stack That stack's configuration, logs, and metrics That stack's handshake log or approved capture JVM as TLS client to database, broker, or partner API Client-side service metrics; the peer participates in selection Client-side debug or capture plus peer evidence Service mesh, database, or broker Per-leg platform metrics Per-leg log, real connection, identity check, and failover test Partner message layer Profile validation and business-flow metrics Object identifiers, validation result, and profile receipt Back to Track T: a JDK upgrade is a route-level rollout 

[M] Track T production reference – measurement, drain, and rollback • Define the handshake-attempt population. With the required events enabled, JFR records completed TLS activity – protocol, cipher suite, and certificate events – but on JDK 27 TLSHandshake records no selected named group and no attempt that fails before completion, so it supplies neither this denominator nor the failed-attempt count. JDK 28 EA adds a namedGroup field, but it is populated only for handshakes that complete, so the failed-attempt gap remains on both releases. [JDK-8301626] • An empty denominator is reported as not applicable, and the reason is stated: no triggering events, or insufficient approved evidence. Insufficient evidence pauses expansion. • Count connect and read timeouts as well as SSLHandshakeException. A middlebox may drop a split ClientHello before a TLS alert exists. • Define how HTTP pools, JDBC connections, gRPC channels, broker sessions, and resumption tickets will drain. A policy change affects new handshakes, not established connections. • Record the classical exposure window reopened by rollback. Rollback is both a repair action and a security event. Back to Track T: a JDK upgrade is a route-level rollout 

[N] Vendor and partner questions – transport and platform For every answer, record the respondent, issue date, exact product and version, validity period, and revalidation trigger. • Which exact named groups, TLS versions, provider modes, and validated configurations does this version support? • Is support enabled by default, or by which explicit control? • Which implementation terminates each primary and failover leg? • Which fields expose ClientHello offers, HelloRetryRequest, final selected group, resumption mode, outcome, and failure? • What is the handshake-attempt counter and its scope? • How are policy rollback, connection drain, ticket invalidation, and recovery tested? • Which peer stacks and versions have passed interoperability and negative tests? Back to Discover in parallel, change in sequence 

[N] Vendor and partner questions – trust, formats, keys, and partners • Which certificate algorithms and profiles can the CA issue, and which clients accept them? • Which HSM/KMS parameter sets, operations, providers, firmware, recovery, failover, access controls, and audit paths are supported? • Which RFC identifiers do JOSE, CMS, XML, and certificate tools implement, from which version? • Which producers, consumers, retained objects, and partner profiles have passed positive and negative tests? • What coexistence window, fallback, rollback, retirement date, and authorised sign-off apply? Do not accept ‘PQC supported’ without a dated version, boundary, algorithm or format, evidence source, owner, rollback path, and expiry or retirement plan. Back to Discover in parallel, change in sequence 

[O] Claim guardrails – readiness and scope claims Claim to avoid Better claim Evidence question Java supports PQC, so the application is ready. Java supplies building blocks, and JEP 527 gives OpenJDK SunJSSE a Track T path. Which track and bounded decision passed? JEP 527 migrates the application. JEP 527 changes TLS 1.3 key exchange in SunJSSE. What about objects, certificates, keys, and partners? We enabled the hybrid group, so the route is quantum-safe. Configuration is intent; new, resumed, and early-data paths need the right evidence. What did the real leg select, and what was the evidence coverage? The provider or CA supports the algorithm. Support is preparation. Did the real route, key lifecycle, object, or trust path pass? Hybrid TLS means the certificate is post-quantum. Key exchange and certificate authentication are separate tracks. What chain and identity evidence exists? The partner path is ready because HTTPS is ready. Transport and message profiles need separate bilateral proof. Which profile, version, artefact, and rollback plan passed? Oracle's roadmap lists our JDK line, so the application is ready. A roadmap row is a vendor target; confirm delivery, the exact provider, and the real boundary. Which update shipped, and which evidence level passed? We proved it on a JDK 28 earlyaccess build, so production is covered. An early-access, non-GA, or locally rebuilt runtime is lab evidence only; repeat interoperability, route, performance, negative-path, and rollback tests on the exact supported GA or vendor build. Which supported build carried the evidence, and was it retested there? These readiness and scope guardrails are this deck's own model, not a published standard; each better claim names the track, boundary, or build it is limited to. Back to Every PQC claim needs a track, a boundary, and evidence 

[O] Claim guardrails – evidence and coverage claims Claim to avoid Better claim Evidence question JFR shows no failures, so the rollout is healthy. On JDK 27, JFR proves neither the attempt population nor the selected group; see [M]. What counted attempts, failures, and selected groups? One hybrid handshake proves production readiness. One handshake proves a path; production needs coverage, workflow, thresholds, and rollback. Which Level 4 and Level 5 evidence passed? The ClientHello offered the hybrid group, so the connection used it. An offer is intent. Only the ServerHello selection, or the product's selected-group record, proves the outcome; a HelloRetryRequest can change it. Which record shows the server's selection, not just the offer? Resumed sessions inherit the hybrid protection of the first handshake. Only psk_dhe_ke performs a fresh key exchange; psk_ke and 0-RTT early data do not, and JDK 27 exposes no PSK or ticket lineage; see [M]. Which resumption path was it, and what lineage evidence exists? Coverage is 100 per cent, so the route is proven. A share is only as good as its stated population and period; an empty or unstated denominator is reported as not applicable, not as success. Which population, which window, and which evidence source? The gateway logs the hybrid group, so the whole path is hybrid. Evidence from one TLS boundary does not describe another leg, an alternate route, or a different sample; see [M] evidence by TLS boundary. Which leg produced the record, and which legs still have none? These evidence and coverage guardrails are this deck's own model, not a published standard; each better claim names the evidence level it requires – see [I]. Back to Every PQC claim needs a track, a boundary, and evidence 

[P] Evidence vocabulary – each evidence word and x25519 spelling Four evidence words, four jobs – plus one spelling rule, used consistently across the deck Term Where it is used What it means in this deck Evidence Act 3 onwards The umbrella term: any record that shows what a real route, object, key, or trust path did Focused proof Act 2 onwards One handshake, object, or trust path proven at the boundary that terminates it Coverage Acts 5 and 6 The share of a defined population of attempts over a stated period Evidence source Act 3 onwards Where the record comes from: JFR telemetry, a time-boxed debug trace, or an approved capture x25519 (lower case) Named-group lists and selections The TLS named group registered as x25519(29): what a process offers and a peer selects [IANA TLS Supported Groups; RFC 9846] X25519 (capital) Key-exchange internals The RFC 7748 key-agreement function and its 32-byte share, including the classical half of X25519MLKEM768, whose registered name keeps the capital X [RFC 7748; RFC 10024] Back to One request. Four TLS legs. Four owners of the truth. 

Thank you!