Loading...

Type: Outcome
Resolution: Unresolved
Priority: Major
Fix Version/s: openshift-4.20
Affects Version/s: None
Component/s: None
Labels:
- PQC_Status

Activity Type:
Product / Portfolio Work
Hierarchy Progress Bar:

0% To Do, 0% In Progress, 100% Done
Status Summary:
Hide

[2025-10-03]:

1.) Risks/Blockers:

Go upstream confirmed ML-DSA will NOT be part of Golang 1.26 (planned FEB 2026), so we won't have ML-DSA in OCP 4.22 (planned late JUN 2026), goal moves to OCP 4.23 (a year from now). There is nothing we can do.

TLS 1.3 support is inconsistently enforced; further analysis in progress (see https://issues.redhat.com/browse/OCPSTRAT-769), but the lack of proper TLS 1.3 means a lack of PQC support.

ML-KEM support in ServiceMesh depends on UBI 9.7, and SM3 being rebased on UBI 9.7 --> work moving to OCP 4.21, on 4.20 only a blog explaining how to enable this in a dev preview fashion would happen.

2.) Accomplishments:

Testing of ML-KEM support in Golang in OCP 4.20 proved that only etcd does not support it because it uses Go 1.23. Controller, api, kcm, scheduler, and kubelet worked properly.

3.) Focus areas for the upcoming weeks:
Formal testing of ML-KEM support in OCP 4.20:

Components: 6 (api, etcd, kcm, scheduler, kubelet, controller)

test scenarios:
                                                - hybrid algorithm negotiation
                                                - backward compatibility with only non-PQC algorithm
                                                - Pure PQC algorithm negotiation
                                                - regression check by runs of TLS-based test suites

4.) Further details:

We made a happy discovery reading https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/ and checking if we could reproduce those results with dev build of OCP 4.20. We could! --> early ML-KEM support with Go-based code in OCP 4.20 is possible.
Show
[2025-10-03] : 1.) Risks/Blockers: Go upstream confirmed ML-DSA will NOT be part of Golang 1.26 (planned FEB 2026), so we won't have ML-DSA in OCP 4.22 (planned late JUN 2026), goal moves to OCP 4.23 (a year from now). There is nothing we can do. TLS 1.3 support is inconsistently enforced; further analysis in progress (see https://issues.redhat.com/browse/OCPSTRAT-769 ), but the lack of proper TLS 1.3 means a lack of PQC support. ML-KEM support in ServiceMesh depends on UBI 9.7, and SM3 being rebased on UBI 9.7 --> work moving to OCP 4.21, on 4.20 only a blog explaining how to enable this in a dev preview fashion would happen. 2.) Accomplishments: Testing of ML-KEM support in Golang in OCP 4.20 proved that only etcd does not support it because it uses Go 1.23. Controller, api, kcm, scheduler, and kubelet worked properly. 3.) Focus areas for the upcoming weeks: Formal testing of ML-KEM support in OCP 4.20: Components: 6 (api, etcd, kcm, scheduler, kubelet, controller) test scenarios: - hybrid algorithm negotiation - backward compatibility with only non-PQC algorithm - Pure PQC algorithm negotiation - regression check by runs of TLS-based test suites 4.) Further details: We made a happy discovery reading https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/ and checking if we could reproduce those results with dev build of OCP 4.20. We could! --> early ML-KEM support with Go-based code in OCP 4.20 is possible.
Blocked:
False
Blocked Reason:

Hide

None

Show
None
Ready:
False
Size:
None

SFDC Cases Counter:
SFDC Cases Open:
SFDC Cases Links:

Intelligence Requested:
Market:

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)?

This outcome is about OpenShift 4.20+ support of Post Quantum Computing (PQC) algorithms in 2025 to support the NIST Commercial National Security Algorithm (CNSA) 2.0 deployment timeline. In 2025, the requirements are:

Support and prefer PQC algorithms for software/firmware signing
Support and prefer PQC algorithms for Web browser, Web servers and cloud services

This outcome is considered complete when OpenShift & Layered products offer a PQC method for digital signing, web-based transaction can use end-to-end PQC algorithms, and Red Hat cloud services also support PQC algorithms.

Success Measure

Q3: Complete testing of ML-KEM support in the OCP 4.20 control plane (100%)

Q4: Support ML-KEM in Service Mesh 3.x with OCP 4.20 + UBI 9.7 in an early dev preview mode

Further Information

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

Also of interest:

Google Willow announcement blog: https://blog.google/technology/research/google-willow-quantum-chip/

Success Criteria

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:

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, lacking info as of DEC 16, 2024)

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:

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 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).