-
Initiative
-
Resolution: Unresolved
-
Major
-
None
Feature Overview (aka. Goal Summary)
Make Installer PQC-capable for secure connections by integrating PQC hybrid key exchange (ML-KEM) capabilities provided by the underlying RHEL platform and the Go 1.24+ toolset to meet the following outcome: Making Core OpenShift 4.22 & Layered OpenShift 4.23 PQC-Capable (opt-in) for secure connections by integrating PQC hybrid key exchange (ML-KEM) capabilities provided by the underlying RHEL platform and the Go 1.24+ toolset.
The 2026 NIST requirements are:
- Support and prefer PQC algorithms for software/firmware signing (2025)
- Support and prefer PQC algorithms for Web browser, Web servers and cloud services (2025)
- Support for networking equipment - including software, VPNs, IPsec... (2026) --> impact on IPsec usage in OCP
This includes ensuring Installer offers a PQC method for digital signing, web-based transactions can use end-to-end PQC algorithms, and Red Hat cloud services also support PQC algorithms & OpenShift networking protocols also support PQC algorithms.
To understand Post Quantum Cryptography and see a Kubernetes-based demo, please watch this IBM session from Kubecon NAM 2024: https://www.youtube.com/watch?v=6eQA15r6IHY (36 minutes)
- Red Hat Links:
https://www.redhat.com/en/blog/red-hats-path-post-quantum-cryptography
https://www.redhat.com/en/blog/how-red-hat-integrating-post-quantum-cryptography-our-products
Expectations & Goals
| Q2 2026 |
| Core OCP components are rebuilding using PQC-enabled key encapsulation (ML-KEM) go/crypto. |
| OCP begins integrating the PQC-capable IPsec libraries (i.e. from the core implementation of PQC ML-KEM for IPsec (libreswan) in RHEL 10.2 release). |
| OCP 4.22 enforces TLS configurations, TLS 1.3 & ML-KEM is supported. |
| Core OCP 4.22 components are re-built using PQC-enabled key encapsulation (ML-KEM) go/crypto. |
| Q3 2026 |
| OCP 4.22 integrates RHEL PQC capabilities (RHEL 9.8+). OCP complete their integration and testing of ML-KEM PQC for IPsec. |
| Layered products consuming OpenSSL, NSS, and GnuTLS from RHEL test TLS 1.3 with ML-KEM key exchange and ML-DSA certificates is complete. |
| Q4 2026 |
| Go 1.27 with ML-DSA support is integrated into the OCP build root and PRs for PQC certificate support are submitted upstream to Kubernetes. |
| Final verification of PQC for TLS (1.3 with ML-KEM key exchange and ML-DSA certificates) and SSH (ML-KEM Key exchange) across OpenShift (and RH) is complete. |
| OCP support ML-KEM PQ-enable IPsec is anticipated for release in OCP 4.23. |
| OCP 4.23 supports ML-KEM in the OpenShift layered products. |
Goals (aka. expected user outcomes)
Success means:
- Our customers can use PQC algorithms to check the digital signature of OCP & Layered bits
- Our customers can run PQC enabled web-based sessions, from their browser to the OCP application (and anything in between)
- Red Hat cloud services supports PQC algorithms (jjung@redhat.com will clarify this requirement in Q1 2026, lacking info as of OCT 2025)
- OpenShift’s internal CAs and PKI are PQC-capable, and the platform can be configured to use PQC algorithms for its own communications.
- The necessary upstream changes in Kubernetes have been contributed and merged.
Requirements (aka. Acceptance Criteria):
- This is NIST roadmap to support PQC, and not following it creates risks:
-
- Failure to comply would jeopardize our NAM Public Sector customers, who must obey the NIST roadmap.
- We already have customer inquiries, meaning we need to provide a roadmap and progress to support PQC or risk letting competitors occupy the space we don't fill.
- Quantum Computer progress is dynamic, and the roadmap NIST provides (full PQC support by 2030-2032) is based on the current estimated progress of the technology. A breakthrough might require switching to PQC algorithms sooner than planned, and we cannot fall behind the NIST timeline.
This outcome aligns with the company's strategic goals of enhancing security measures and ensuring systems remain secure even as quantum computing advances. This is a must-do, not an optional functionality.
| Deployment considerations | List applicable specific needs (N/A = not applicable) |
| Self-managed, managed, or both | |
| Classic (standalone cluster) | |
| Hosted control planes | |
| Multi node, Compact (three node), or Single node (SNO), or all | |
| Connected / Restricted Network | |
| Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | |
| Operator compatibility | |
| Backport needed (list applicable versions) | |
| UI need (e.g. OpenShift Console, dynamic plugin, OCM) | |
| Other (please specify) |
Questions to Answer (Optional):
Out of Scope
Background
- “If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use. This would seriously compromise the confidentiality and integrity of digital communications on the Internet and elsewhere. The goal of post-quantum cryptography (also called quantum-resistant cryptography) is to develop cryptographic systems that are secure against both quantum and classical computers, and can interoperate with existing communications protocols and networks.” ([Source|https://csrc.nist.gov/Projects/post-quantum-cryptography)]
- clones
-
OCPSTRAT-2194 [OADP] Evaluate Readiness Requirements for PQC
-
- New
-