Uploaded image for project: 'OpenShift API for Data Protection'
  1. OpenShift API for Data Protection
  2. OADP-6073

[OADP] Evaluate Readiness Requirements for PQC

XMLWordPrintable

    • Evaluate readiness requirements for PQC in OADP
    • Product / Portfolio Work
    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • To Do
    • OCPSTRAT-2194[OADP] Evaluate Readiness Requirements for PQC
    • ToDo
    • 0
    • Very Likely
    • 0
    • None
    • Unset
    • Unknown

      Outcome Overview

      Once all Features and/or Initiatives in this Outcome are complete, what tangible, incremental, and (ideally) measurable movement will be made toward the company's Strategic Goal(s)?

      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 outcome is considered complete when OpenShift & Layered products offer 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/crypto17.
      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/crypto17.
      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.

       

      Definition of Done (2026)

      What is the success criteria for this strategic outcome?  Avoid listing Features or Initiatives and instead describe "what must be true" for the outcome to be considered delivered.

      Success means:

      1. Our customers can use PQC algorithms to check the  digital signature of OCP & Layered bits
      2. Our customers can run PQC enabled web-based sessions, from their browser to the OCP application (and anything in between)
      3. Red Hat cloud services supports PQC algorithms (jjung@redhat.com will clarify this requirement in Q1 2026, lacking info as of OCT 2025)
      4. OpenShift’s internal CAs and PKI are PQC-capable, and the platform can be configured to use PQC algorithms for its own communications.
      5. The necessary upstream changes in Kubernetes have been contributed and merged.

       

      Expected Results (what, how, when)

      What incremental impact do you expect to create toward the company's Strategic Goals by delivering this outcome?  (possible examples:  unblocking sales, shifts in product metrics, etc. {}{} provide links to metrics that will be used post-completion for review & pivot decisions). {}For each expected result, list what you will measure and +when you will measure it (ex. provide links to existing information or metrics that will be used post-completion for review and specify when you will review the measurement such as 60 days after the work is complete)

      This is NIST roadmap to support PQC, and not following it creates risks:

      1. Failure to comply would jeopardize our NAM Public Sector customers, who must obey the NIST roadmap.
      2. 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.
      3. 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.

      Post Completion Review – Actual Results

      After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).

       

              wnstb Wes Hayutin
              julim Ju Lim
              Wes Hayutin
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: