JavaZone 2026

Quantum-Ready Java:A Practical Guide to Post-Quantum Cryptography Migration @ JavaZone 2026

Transcript

1. Quantum-Ready Java A Practical Guide to Post-Quantum Cryptography Migration NISHIKAWA, Akihiro Cloud Solution Architect, Microsoft
2. Agenda Act 1: Why migration starts now Act 2: Java platform reality Act 3: Inventory and evidence Act 4: Five migration tracks Act 5: Rollout plan
3. Answer first
4. You do not need to be a cryptographer PQC = algorithms that run on today's computers, built to resist future quantum attacks • This is engineering work, not a maths lecture • Start with TLS. Then check what TLS does not cover • Byte-level detail lives in the appendix
5. What you can take back on Monday PQC migration is not one switch. • JEP 527: a strong pilot path for hybrid TLS 1.3 in SunJSSE • It helps HTTPS key exchange — it does not migrate the app • Pick one real Java service. Find every crypto touchpoint • Name an owner and evidence for each one • Choose one reversible hybrid TLS pilot
6. Five-track model Guardrail: never hide application encryption under TLS • Track T: TLS and HTTPS key exchange • Track S: signed/encrypted objects — JWT, CMS, XML, JWE • Track C: certificates and PKI • Track K: KeyStores, HSMs, KMS platforms • Track P: partner protocols AS2, AS4, S/MIME, OFTP2
7. Act 1 – Why migration starts now
8. What Is at Risk – and What Is Not Not every algorithm must change - find the public-key decision points first • 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 & hashing) • Review key sizes and policies
9. Why now? Lead time, not panic • NIST, NSA, UK NCSC point across this decade and the 2030s • Scoped guidance — not one universal deadline • Your date depends on system, jurisdiction, regulator • Work backwards from the date you must be ready • Month one is discovery, ownership, vendors, partners 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.
10. A customer case: why lead time matters • Thousands of touchpoints across apps, JDKs, libraries, keys, certs • Most sat outside the security module. Ownership was fragmented • Manual review did not scale • What worked: a four-layer inventory • What failed: runtime capability treated as route evidence — the edge terminated TLS
11. HNDL – Harvest Now, Decrypt Later • Record protected traffic today, break the public-key part later • For recorded TLS, the decision that matters is key exchange • Hybrid TLS 1.3: clear scope, reversible change • But the first pilot is not always the biggest risk • Rank stored data by how long it must stay secret
12. Two clocks: confidentiality and authenticity Two clocks, two problems. • Forgeable signatures mean impersonation — certs, JWTs, receipts • That is not the same as decrypting old captured traffic • Confuse the clocks and you delay the work that helps HNDL • The answer is not either-or. It is sequencing
13. Act 2 – Java platform reality
14. Java PQC platform map Ask "which surface?", not "does Java support PQC?" • Building blocks: ML-KEM, ML-DSA, KDF • JEP 527 connects them to one surface: hybrid TLS 1.3 in SunJSSE • JEP 527 helps Track T — not objects, certs, KeyStores, HSM, partners • Oracle plans hybrid TLS across LTS lines, JDK 8 to 25 • A vendor roadmap is not deployed evidence
15. Primitive APIs are not application migration • A JDK primitive gives you ML-KEM or ML-DSA — nothing more • Each use case still needs a standard, a library, key material • Plus an owner and evidence • JWT, CMS, XML Signature, JAR signing, KeyStores mature separately • Track readiness per use case, not as one Java-wide status
16. What JEP 527 changes in TLS What changes • Client offers a hybrid group such as X25519MLKEM768 • Session secret combines classical X25519 and ML-KEM • An attacker must break both — that is the HNDL reduction What does not change • Record protection still uses normal AEAD ciphers • RFC 10024 puts the three ECDHE-MLKEM groups on the Standards Track RFC • Delivered in JDK 27; GA planned 15 September 2026
17. Why hybrid, not pure PQC? • Compatibility and risk management • Classical fallback may be permitted — visible, owned, time-bounded • Hidden fallback means unmeasurable HNDL exposure • TLS 1.2 is a separate problem: move candidates to 1.3 first
18. Hybrid TLS 1.3: X25519MLKEM768 Only what you need to know 🖥 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. For the NIST-curve hybrid groups, ECDHE comes first.
19. Act 3 – Inventory and evidence
20. 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
21. Four-layer inventory Make each layer a search you can run before lunch. • Build — crypto libraries and TLS implementations • Source — crypto calls and algorithm strings • Config — KeyStores, TrustStores, TLS settings, endpoints • Runtime — evidence from the real route or object • Record owner, control point, and evidence for each hit
22. One service, one inventory record • Five fields: track, owner, control point, behaviour, evidence • Track T · edge platform · public gateway · TLS 1.3 X25519 · gateway log • Blank owner, control point, or evidence = not ready for a decision • One service by hand teaches the method • You scale it with an automated crypto inventory in CI
23. Demo beat 1: four-layer inventory Inventory finds the work, but It doesn’t prove the selected group. ❶ Build: Spring Security, JDBC driver, Bouncy Castle, JDK providers ❷ Source: explicit crypto calls and algorithm strings ❸ Config: TLS settings, KeyStores, certificates ❹ Runtime: JFR: TLS + certificate activity Hidden crypto becomes a backlog. Next: negotiated proof
24. How many crypto touchpoints are hiding? 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
25. What the audit finds - dependencies • Review first • JWT signing libraries • database drivers using TLS • general-purpose crypto providers 🔴 Quantum-vulnerable as used 🟡 Needs review 🟢 Low-risk 🔴 Nimbus JOSE+JWT used here for RSA (RS256) JWS 🟡 Bouncy Castle General-purpose crypto provider 🟡 Google Tink Algorithm hidden in key template 🟡 Spring Security BCrypt, crypto utilities 🟡 PostgreSQL JDBC TLS via driver configuration - easy to miss in code review 🟢 Commons Codec Hashing/encoding utilities 🟡 JDK built-in JCA/JCE Always available
26. What the audit finds - source Crypto is often hidden behind framework APIs. 🔴 Spring Security: NimbusJwtEncoder signs JWTs with RSA. 🟡 Bouncy Castle: JcaContentSignerBuilder takes the signing algorithm as an argument. 🟡 Spring Boot: server.ssl.* enables TLS with almost no Java code. Keyword grep alone is not enough. • Read framework configuration and builder calls.
27. What the audit finds – Config Quantum-vulnerable material, but not the full TLS story 🔴 RSA-2048 server key 🔴 RSA-signed certificate chain Used for HTTPS authentication in this service. Same keystore is also referenced by JWT and licence flows in this demo. Needs review for certificate and signature migration. Does not prove the negotiated TLS named group.
28. Layer 4 Needs Three Views Capability SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites() or, per sockets: sslSocket.getSupportedSSLParameters().getNamedGroups() Configuration SSLParameters.setNamedGroups(...) -Djdk.tls.namedGroups=... Runtime JFR: jdk.TLSHandshake / jdk.X509Certificate / jdk.SecurityProviderService (since JDK20) Clear named-group proof: JSSE debug (-Djavax.net.debug=ssl:handshake:verbose) or packet capture: Outside the JVM: Edge TLS / Managed crypto / External identity
30. What the audit finds – JFR runtime audit • Static analysis can miss runtime-only crypto behaviour. • Enable these JFR events below • Capture with jcmd JFR.start or a recording template. Events Helps with jdk.TLSHandshake TLS protocol version, cipher suite, peer, and certificate id jdk.X509Validation certificate-chain validation jdk.X509Certificate certificate inventory: subject, issuer, signature algorithm, key type, key size, validity jdk.SecurityPropertyModification security-property changes jdk.Deserialization deserialization-related security events jdk.SecurityProviderService provider, service type, and algorithm lookup
31. Demo result — one small Spring Boot service • One small service: 22 crypto touchpoints. • Most were not obvious from business code. Quantum vulnerable 5 Need review Low risk Total 14 3 22 (in this demo)
32. Demo beat 2: deterministic hybrid TLS proof Close the gap: prove the negotiated group. CLIENT SUCCESS PROVES SERVER Hybrid only X25519MLKEM768 Hybrid only TLS 1.3 was selected TLS 1.3 ClientHello offer + ServerHello selection = negotiated proof
33. ClientHello ServerHello
34. Java 27 Java 28
35. Evidence ladder for PQC readiness 1. Capability — the runtime can do it 2. Configuration — the service asks for it 3. Technical proof — the real route or object shows it 4. Business proof — the real client or partner accepts it 5. Operational proof — monitoring, rollback, owner, expiry Level 1 or 2 is preparation, not migration complete
36. Crypto-agility makes migration possible policy, not hard-coding • New and old data follow different rules during migration • Encrypt-new, decrypt-old. Sign-new, verify-old • Every exception needs an owner, a reason, and an expiry ❌ algorithm names hard-coded in business logic Signature.getInstance("SHA256withRSA"); ✅ business code asks for a use case; policy supplies the rest • algorithm, provider, key alias, validity, rollback • JWT policy: RS256 today, move only when everyone is ready
37. Configuration – e.g. application.yml tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519] certificates: mode: classical application-signatures: mode: classical Keep four things in configuration: 1. Separate modes by migration track 2. Use standard names and complete transformations 3. Keep TLS named-group order outside code 4. Keep message-protection provider and message-protection: policy outside code 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
38. Act 4 – Five migration tracks
39. Track T – TLS / HTTPS key exchange • Start from a stable TLS 1.3 baseline • Pilot hybrid key exchange • Keep the hybrid group and classical fallback visible • Level 3 only when proof comes from the route you care about • Clear risk model, clear boundary
40. Track T pitfalls • Enabling a group does not prove a session negotiated it • Resumed sessions do not show the same signal — test both • Larger ClientHello: middleboxes may drop it, showing as timeouts • JDK 27 puts the hybrid group first by default • Treat the JDK upgrade itself as a route-level rollout item
41. Choose the rollout boundary Where does TLS actually terminate? • If traffic ends at a CDN or LB, backend JVM settings change nothing • Service-to-service: SunJSSE may be the control point • Mesh, database, broker, partner gateway own part of the decision • Name five things: boundary, control point, evidence, fallback metric, rollback • Collect evidence at the same boundary as the control point
42. Track S – Signed and encrypted application objects • Not the pipe — the objects the app creates, stores, sends • 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
43. Track C – Certificates / PKI • 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
44. Track K – Key and secret management Track K is often the blocker. • You cannot convert an RSA key into ML-DSA or ML-KEM • Create new key material alongside the old • Check the real path: key types, provider, rotation, backup, recovery, audit • Certificates, signatures, and partners all depend on keys • An untracked fallback is a downgrade, not a safe mode
45. Track P – Partner protocols • 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 • An HTTPS upgrade alone proves nothing about the message path
46. Same discipline, different mechanisms The operating model is reusable, not the handshake. • Choose a boundary. Name the owner. Find the control point • Run a small pilot. Collect proof. Keep fallback visible • Define rollback. Monitor exceptions • T is the reference case; S coexists objects; C plans PKI • K coexists keys; P tests bilaterally
47. Act 5 – Rollout plan
48. Production change order A dependency model, not one fixed plan. • Track T often moves first — it reduces HNDL and you control it • Track K discovery starts in parallel: everything depends on keys • Track P cuts over late, but the conversation starts early • The goal is not solving every track at once
49. Pilot success gates • Scope and owner are named • Security: the real route proves negotiation and visible fallback • Compatibility: real clients complete the workflow • Operations: baseline, thresholds, rollback action, owner • A metric without a threshold is observation, not a gate
50. Observability and policy PQC migration is not a single ticket. • Standards, libraries, providers, and partners keep changing • Start-up checks, runtime telemetry, policy exceptions, CI checks • Exceptions need an owner, a reason, and an expiry • Without observability, old algorithms return through a dependency bump • Watch negotiation, fallback, cert and key lifecycle, exceptions
51. Final guardrail: ask for evidence Every PQC claim needs a boundary and evidence. • "Java supports PQC" — which track? • "The provider supports it" — did the real route or object use it? • "The partner is ready" — which version, profile, test, rollback owner? • These questions protect the plan from over-claiming
52. Key takeaways – the Monday test Five things to remember: Monday: • Quantum risk starts with public-key crypto One service, five fields, one reversible Track T pilot • JEP 527 gives Track T a path — not the whole application • Readiness is evidence, not capability • Plan all tracks in parallel; sequence production • New service? Put the seams in before release
53. Sample codes github.com/anishi1222/find-crypto-usages
54. Appendix
55. Appendix map Question Go to What is final, draft, or release-candidate today? A — Status snapshot Which feature release or Oracle LTS update changes which surface? B — Java release map How large are the hybrid key shares? C — Wire sizes What should we inventory, and what does the demo prove? D — Inventory and demo How can JDK 27 prove the selected group? E — Selected-group proof What claim can we make at each evidence level? F — Evidence ladder What must one migration decision record? G — Decision record What gates a Track T pilot? H — Pilot gates What about resumption and 0-RTT? I — Resumption What does ‘done’ mean for S, C, K, and P? J — Other tracks Where should evidence come from? K — Controlling boundary What should we ask vendors and partners? L — Questions Which claims should we avoid? M — Guardrails Where are the primary sources? N — Sources
56. [A] Status snapshot (as of 2026-08-12) — standards • Everything in this section is dated. Source Status at the review cutoff Use it for Scope guardrail NIST FIPS 203 / 204 / 205 Final standards ML-KEM, ML-DSA, and SLHDSA Algorithms, not an application migration plan NIST IR 8547 Initial Public Draft, 12 Nov 2024 Proposed transition and deprecation planning Draft guidance; not a universal obligation 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 A published RFC does not prove product or route support RFC 9881 / 9882 Standards Track, October 2025 ML-DSA identifiers for X.509 and CMS Identifier availability is not interoperability 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 at this cutoff ML-DSA signature schemes in TLS 1.3 Separate from RFC 10024 and X.509 identifiers
57. [A] Status snapshot — vendor, policy and IANA groups • For public Web PKI, claim neither universal readiness nor universal impossibility. Verify CA product, profile, chain, TrustStores, clients, TLS stack and route. Source Status at the review cutoff Use it for Scope guardrail Oracle LTS PQC announcement Current Oracle direction PQC across Oracle JDK LTS lines: 25, 21, 17, 11, 8 Directional commitment, not delivery or migration evidence Oracle JRE/JDK Cryptographic Roadmap Updated 3 July 2026; future update-release targets Oracle JDK release-line planning and early testing Plans can move; Oracle-shipped providers only CNSA 2.0 / CNSS Policy 15 Current guidance for systems in scope US National Security System requirements Not a global enterprise deadline UK NCSC 2028 / 2031 / 2035 Current UK guidance Discovery, priority migration, completion planning Apply the relevant jurisdiction and sector rules RFC 10024 → 4587 / 0x11EB SecP256r1MLKEM768 IANA Recommended flag: N Registry property, not a deployment mandate RFC 10024 → 4588 / 0x11EC X25519MLKEM768 IANA Recommended flag: Y Apply policy and validatedmodule requirements RFC 10024 → 4589 / 0x11ED SecP384r1MLKEM1024 IANA Recommended flag: N Verify the route, not the registry
58. [B] Java release map • Production guardrail: use the JDK 27 release candidate for lab evidence only. Repeat every test on the exact supported GA or vendor build. Java release / surface Status at the review cutoff Helps with Does not prove Java 21: KEM API, JEP 452 Final standard API Standard API shape for key encapsulation Built-in ML-KEM or protocol migration Java 24: ML-KEM and MLDSA, JEP 496 / 497 Final Post-quantum KEM and signature primitives JWT, CMS, JAR, HSM, or partner interoperability Java 24: KDF API, JEP 478 Preview in Java 24 Standard key-derivation API shape A stable production API contract in Java 24 Java 25: KDF API, JEP 510 Final; finalises the Java 24 preview Standard key derivation, including HKDF Protocol choice or rollout boundary JDK 27: JEP 527 Delivered; build 34 is an RC/EA build; GA planned 15 Sep 2026 Hybrid TLS 1.3 key exchange Certificates, objects, keys, in OpenJDK SunJSSE partners, or a supported runtime before GA JDK 28: JFR namedGroup EA; from build b03 via JDK8301626; no JDK 27 backport Named-group field in completed jdk.TLSHandshake events JDK 27 evidence, failed attempts, or resumption lineage
59. [B] Oracle JDK LTS update roadmap • PBMAC1 is KeyStore modernisation, not a PQC algorithm. Default capability is still not proof of selection on a real TLS leg. 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
60. [C] Wire sizes • A complete ClientHello is commonly around 1.5 kB and may span multiple TCP segments. Measure the real route. Item Size Meaning ML-KEM-768 encapsulation key 1,184 bytes Client-side ML-KEM public material X25519 ephemeral share 32 bytes Classical component X25519MLKEM768 client key_exchange 1,216 bytes 1,184 + 32 Separate classical x25519 client share 32 bytes Also sent by the default JDK 27 client Two default JDK 27 client payloads 1,248 bytes Payloads only, not the full ClientHello X25519MLKEM768 server key_exchange 1,120 bytes ML-KEM ciphertext 1,088 + X25519 32 SecP256r1MLKEM768 Client 1,249; server 1,153 Implemented, not in the JDK 27 default list SecP384r1MLKEM1024 Client and server 1,665 Implemented, not in the JDK 27 default list
61. [D] Four-layer inventory: checks and records • A match is a candidate, not proof of production use. No match is not proof of absence. Layer Representative checks Record Build Security frameworks, JSSE/JCE providers, database and broker drivers, KMS SDKs, JOSE/CMS/XML libraries, native TLS bindings Dependency, version, owner, expected use Source KEM, KeyAgreement, Signature, Cipher, KeyStore, SSLContext, SSLEngine, SSLParameters, and framework APIs Call path, format, algorithm, key source, track Configuration KeyStores, certificates, named groups, protocol pins, algorithm constraints, partner endpoints, database TLS Control point, requested behaviour, owner, expiry Runtime Effective parameters, real handshakes, serialised objects, certificates, and audit events Boundary, peer or consumer, observed behaviour, proof source
62. [D] crypto-audit-demo: 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 profile excludes the DataSource A live 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
63. [E] Selected-group proof — server and client • Terminal A — server permits only the hybrid group 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 • Terminal B — client with a restricted debug sink • NOTE: --trust-all is for this local self-signed laptop demo only. Any real pilot uses an approved TrustStore with hostname and certificate validation. 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?name=JavaZone' \ --named-group X25519MLKEM768 --trust-all 2>logs/jsse-client.log
64. [E] Show the offer, selection and artefact • Terminal C — filter the restricted debug log cd 01-PQC/demo/PQC-enabled-SpringBoot-App rg -i 'supported_groups|key_share|x25519mlkem768' logs/jsse-client.log • Evidence hygiene • NOTE: At another boundary, use that product's selected-group log or an approved handshake-only capture. Never use evidence from one TLS leg to describe another. Keep the ClientHello offer and the ServerHello selection together. An offer alone is not proof of final selection. Treat the debug file as sensitive operational evidence: approval, restricted access, minimal capture window, retention, verified deletion. Debug field names change between builds - retain the raw artefact and the full java -version.
65. [F] Five-level evidence ladder • For TLS, a JDK default or jdk.tls.namedGroups is Level 2. The selected group on the real leg is Level 3. 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: Technical proof What did the real route, object, ServerHello selection, serialised or key operation do? 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, rollback exercise, exception expiry One bounded production decision
66. [G] Minimum migration decision record • Blank is not N/A. Minimum row: record_id, track, boundary, technical_owner, risk_owner, control_point, current_behaviour, target_behaviour, evidence. 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, 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, expiry
67. [H] Track T pilot gates — 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 controlling boundary • Define the handshake-attempt population — JDK 27 jdk.TLSHandshake records only completed handshakes • Capture a comparable classical baseline: same boundary, window and failure definition • Approve thresholds, pause authority, rollback authority and maximum pause duration • Rehearse rollback and measure it, including restart and connection drain
68. [H] Track T pilot gates — gate table • An empty denominator is never 0% and never a pass. Insufficient evidence pauses expansion. 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
69. [I] Resumption and 0-RTT Do not infer that every session is hybrid from one new full handshake. • A new full handshake is protected by its selected group • Resumed 1-RTT data: a fresh hybrid exchange in psk_dhe_ke, or hybrid lineage from the issuing session • psk_ke has no fresh key exchange and depends on PSK lineage • 0-RTT early data is protected by the offered PSK — a later hybrid exchange does not fix those bytes • JDK 27 SunJSSE offers psk_dhe_ke, not psk_ke, and does not implement 0-RTT • JDK 27 exposes neither PSK identity nor lineage through a public API
70. [J] Track S, C, K and P checklists • A published identifier, vendor roadmap or signed agreement is preparation. Executed evidence is proof. 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 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, wrongidentity and wrong-purpose credentials fail Chain, identity, lifecycle, pinning and rollback tests K: keys / secrets Create new key material; don't convert an old 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
71. [K] Evidence follows the controlling boundary • Identify which implementation terminates the leg before choosing the control or evidence source. 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; JFR has no named group or failed-attempt count 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 thirdparty TLS stack That stack's own configuration, logs and metrics That stack's handshake log or capture JVM as TLS client to database, Client-side service metrics; the peer controls broker or partner API 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, failover test Partner message layer Profile validation and business-flow metrics Object identifiers, validation result and profile receipt
72. [L] Questions — transport and platform • 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?
73. [L] Questions — trust, formats, keys, 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? • Never accept "PQC supported" without a dated version, boundary, algorithm or format, evidence source, owner, rollback path and expiry
74. [M] Guardrails — platform and configuration Claim to avoid Better claim Evidence question Java supports PQC, so the application Java supplies building blocks, and JEP is ready. 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 coverage? The provider or CA supports the algorithm. Support is preparation. Did the real route, key lifecycle, object or trust path pass? Oracle's roadmap lists our JDK line, so we are ready. A roadmap row is a vendor target; confirm delivery, provider and boundary. Which update shipped, and which evidence level passed?
75. [M] Guardrails — certificates, partners, telemetry • Narrow the claim. Name the boundary. Ask for evidence. Claim to avoid Better claim Evidence question 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? JFR shows no failures, so the rollout is healthy. JDK 27 JFR records only completed handshakes and no named group. 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?
76. [N] Sources — standards and guidance • NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) • NIST IR 8547: Transition to Post-Quantum Cryptography Standards (Initial Public Draft) • NSA Post-Quantum Cybersecurity Resources • UK NCSC: Timelines for migration to post-quantum cryptography • RFC 9954 (hybrid key exchange) and RFC 10024 (ECDHE-MLKEM groups) • IANA TLS Supported Groups registry • RFC 9881, 9882, 9935, 9936, 9964; draft-ietf-tls-mldsa
77. [N] Authoritative sources — Oracle and OpenJDK • Oracle: 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 (KEM API), JEP 478 / 510 (KDF API) • JEP 496 (ML-KEM), JEP 497 (ML-DSA) • JEP 527 (Post-Quantum Hybrid Key Exchange for TLS 1.3) • JDK 27 project, schedule and early-access builds • JDK-8301626: Capture Named Group information in TLSHandshakeEvent
78. Thank you!