[Umbrella] Supporting ML-DSA for PQC requirements

Description

This issue is intended to be used as a scoping/tracking issue for all the changes that would be necessary to support configuring ML-DSA for PQC adherence within Kubernetes.

Adding support for configuring the usage of ML-DSA was discussed in the September 3rd, 2026 sig-arch community meeting.

Scope

Pre-requisites

• Bump to Go 1.27 - Go 1.27 introduced native support for ML-DSA crypto: https://go.dev/doc/go1.27#crypto_mldsa . This is actively being done in https://github.com/kubernetes/kubernetes/pull/141663

JWT Verification

Support for JSON Object Signing and Encryption (JOSE) with ML-DSA is a proposed standard: https://www.rfc-editor.org/info/rfc9964

In order to support verification of JWTs, support for this standard will need to be added to the underlying libraries we rely on for JWT verification:

• gopkg.in/go-jose/go-jose.v2. We currently rely on v2 of this package which is now considered obsolete. Support for the proposed standard is already being proposed for v4 of this package in https://github.com/go-jose/go-jose/issues/272 .
• github.com/coreos/go-oidc. This package will first need to be updated to pickup and support the new ML-DSA algorithms as part of it's token verification logic. It will also need to be bumped to use the lastest changes from gopkg.in/go-jose/go-jose.v4 with support for the ML-DSA standard. We currently rely on an old release of the package (v2.5.0) which relies on an older version of the go-jose package. We will need to bump this dependency to the latest version.

Additionally, we will need to update https://github.com/kubernetes/kubernetes/blob/62a78fd86a6c100edae95f159d31fb4b435075c8/staging/src/k8s.io/apiserver/plugin/pkg/authenticator/token/oidc/oidc.go#L246-L257 to add the ML-DSA algorithms to the list of supported algorithms.

ServiceAccount Token Generation

In order to support generation of JWTs signed with ML-DSA we will need to support the standard proposed in https://www.rfc-editor.org/info/rfc9964 for the OpenID JWKS data. In order to do this, we will need to use a version of the go-jose library that supports this. Once we are using the new go-jose library with support for this standard, we can update https://github.com/kubernetes/kubernetes/blob/62a78fd86a6c100edae95f159d31fb4b435075c8/pkg/serviceaccount/openidmetadata.go#L311-L334 to return the correct algorithm based on the public key type.

Additionally, we will need to add a new signer to https://github.com/kubernetes/kubernetes/blob/62a78fd86a6c100edae95f159d31fb4b435075c8/pkg/serviceaccount/jwt.go#L64-L91 for the new *mldsa.PrivateKey type.

Certificate Verification

For the most part, anywhere that verifies certificates using Go's native crypto libraries will inherently be able to verify ML-DSA signed certificates when using Go 1.27.

Certificate Generation

kubelet

kubelet itself will need to be updated to support configuring the type of private key that should be used when generating its bootstrap certificates. The logic for generating the CertificateSigningRequest for bootstrapping certificates will need to be updated to generate new private keys for signing its CSR data based on the configured private key type.

Similarly to the bootstrap certificates, the PodCertificates functionality within the kubelet will need to be updated to generate an ML-DSA private key when specified.

kubeadm

Similarly to kubelet, kubeadm will need updates to allow specifying that bootstrap certificates should be generated using ML-DSA. This will require a new encryption type option and additional key generation and signer implementations for kubeadm. When using ML-DSA, kubeadm must not add keyEncipherment to the certificate.

APIs / Validation

The PodCertificate API will need to be updated to allow a PKCS#10 CSR using the ML-DSA subject public key types.

Additionally, the PodCertificateProjection API will need to be updated to allow specifying the ML-DSA key types.

CertificateSigningRequest spec validation should be updated to not allow the usage field to contain any of the following usages as defined by https://www.rfc-editor.org/rfc/rfc9881.html#name-key-usage-bits:

• key encipherment
• key agreement
• data encipherment
• encipher only
• decipher only

Tasks

• Bump to Go 1.27 - (Done) - https://github.com/kubernetes/kubernetes/pull/141663

  • Update PodCertificate API to allow ML-DSA subject public key types, update PodCertificateProjection API to allow specifying the ML-DSA key types, and update kubelet PodCertificate functionality to generate an ML-DSA private key for CSR generation when ML-DSA key type is requested. - (In Progress) - https://github.com/kubernetes/kubernetes/pull/142108
  • Update kubeadm to allow an ML-DSA encryption type configuration and new signer implementation to generate ML-DSA bootstrap certificates. - (In Progress)
    • https://github.com/kubernetes/kubernetes/pull/142038 (client-go changes)
    • https://github.com/kubernetes/kubernetes/pull/142037 (kubeadm changes) (blocked on client-go changes)
  • Update the CertificateSigningRequest spec validation to disallow usage field bits that are not allowed by https://www.rfc-editor.org/rfc/rfc9881 - (In Progress) - https://github.com/kubernetes/kubernetes/pull/142196

• Bump to latest gopkg.in/go-jose/go-jose.v4 and github.com/coreos/go-oidc in preparation for ML-DSA support future releases - (Done) - https://github.com/kubernetes/kubernetes/pull/142012

  • Bump to version of gopkg.in/go-jose/go-jose.v4 and github.com/coreos/go-oidc that supports ML-DSA
    • Update token authenticator to allow ML-DSA signature algorithms on JWTs. Blocked on Go 1.27 bump.
    • Update service account token and open-id metadata generation to generate ML-DSA signed tokens. Blocked on Go 1.27 bump.

• Update kubelet configuration to allow specifying the key type that should be used to generate bootstrap certificates - (In Progress) - https://github.com/kubernetes/kubernetes/pull/142046

  • Add ML-DSA key types as allowed options. Blocked on Go 1.27 bump. - (In Progress) - https://github.com/kubernetes/kubernetes/pull/142046

Note: Items at the top-level can be done in parallel. Anything nested below these top-level items are blocked on the top-level items (and may be blocked on other top-level items).