OCPBUGS-109794: clarify FIPS-approved TLS groups in TLSSecurityProfile docs - #2983

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- source files ---'
sed -n '1,330p' config/v1/types_tlssecurityprofile.go

printf '%s\n' '--- related symbols and comments ---'
rg -n -C 4 'FIPS-approved|ML-KEM|TLSGroup|TLSProfiles|P256|P384|P521|X25519' \
  config/v1 payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml \
  payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml \
  payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml \
  payload-manifests/crds/0000_10_config-operator_01_apiservers-OKD.crd.yaml \
  payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml \
  payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-CustomNoUpgrade.crd.yaml \
  payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-Default.crd.yaml \
  payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-DevPreviewNoUpgrade.crd.yaml \
  payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-OKD.crd.yaml \
  payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-TechPreviewNoUpgrade.crd.yaml

printf '%s\n' '--- generator references ---'
rg -n 'types_tlssecurityprofile|payload-manifests|generate.*crd|crd.*generate|TLSProfiles' \
  --glob '!payload-manifests/crds/**' .

Repository: openshift/api

Length of output: 50370

🌐 Web query:

NIST FIPS 203 ML-KEM approved status and whether hybrid groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 are FIPS-approved or merely implementation-specific groups

💡 Result:

NIST FIPS 203, which specifies the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), is an official, approved Federal Information Processing Standard that became effective on August 14, 2024 [1][2][3]. Regarding the hybrid groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, these are not themselves "FIPS-approved" as standalone entities in the sense of being specified within a FIPS standard [4][5]. Instead, they are hybrid mechanisms defined in RFC 10024 that combine FIPS-approved elliptic curve algorithms with ML-KEM [4][5]. These hybrid groups are implementation-specific constructions designed to permit FIPS-compliant key derivation as per NIST SP 800-56C and NIST SP 800-135 [4][5]. The regulatory status of these groups depends on the underlying components [4][5]: 1. FIPS-compliance requirements: NIST SP 800-56Cr2 allows for the use of HMAC-based Key Derivation Functions (HKDF) with multiple shared secrets, provided that the first shared secret is generated by a FIPS-approved key-establishment scheme [4][5]. 2. Implementation dependencies: Because FIPS 140-3 certification requires the cryptographic schemes used to be certified, the certification requirement shifts based on the order of the shared secrets in the hybrid construction [4][5]. - For SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDHE shared secret is placed first; therefore, the ECDHE implementation must be FIPS-certified, while the ML-KEM implementation does not require it [4][5]. - For X25519MLKEM768, the ML-KEM shared secret is placed first; consequently, the ML-KEM implementation must be FIPS-certified [4][5]. In summary, these hybrid groups allow organizations to maintain FIPS compliance in their key establishment processes by strategically ordering components to ensure that the required FIPS-approved algorithms meet the necessary certification criteria [4][5].

Citations:

• 1: https://csrc.nist.gov/pubs/fips/203/final
• 2: https://www.govinfo.gov/content/pkg/FR-2024-08-14/html/2024-17956.htm
• 3: https://thefederalregister.org/documents/2024-17956/announcing-issuance-of-federal-information-processing-standards-fips-fips-203-module-lattice-based-key-encapsulation-mec
• 4: https://www.rfc-editor.org/rfc/rfc10024.txt
• 5: https://www.rfc-editor.org/info/rfc10024/

🏁 Script executed:

#!/bin/bash
set -eu

python3 - <<'PY'
from pathlib import Path
p = Path("config/v1/types_tlssecurityprofile.go")
lines = p.read_text().splitlines()
for start, end in [(1, 35), (160, 190), (270, 330), (330, 470)]:
    print(f"--- {p}:{start}-{end} ---")
    for n in range(start, min(end, len(lines)) + 1):
        print(f"{n}:{lines[n-1]}")
PY

printf '%s\n' '--- all TLSProfiles references and FIPS filtering candidates ---'
rg -n -C 3 'TLSProfiles|FIPS|fips|Groups|TLSGroup' --glob '*.go' --glob '!vendor/**' . \
  | rg -v 'payload-manifests|types_tlssecurityprofile.go' \
  | head -n 500

printf '%s\n' '--- module and Go version ---'
sed -n '1,100p' go.mod
rg -n 'crypto/tls|boring|fips|GOFIPS|FIPS' --glob 'go.mod' --glob '*.go' --glob '*.yaml' --glob '*.json' . \
  | head -n 300

Repository: openshift/api

Length of output: 50370

🌐 Web query:

site:rfc-editor.org/rfc/rfc9954 OR site:rfc-editor.org/rfc/rfc10024 X25519MLKEM768 SecP256r1MLKEM768 FIPS mode TLS supported groups

💡 Result:

• RFC 9954 defines the generic TLS 1.3 hybrid-key-exchange framework. Hybrid combinations are negotiated as individual NamedGroup values in TLS supported_groups. [1]
• RFC 10024 defines:
  • X25519MLKEM768 — code point 4588 / 0x11EC, Recommended: Y
  • SecP256r1MLKEM768 — code point 4587 / 0x11EB, Recommended: N
  • SecP384r1MLKEM1024 — code point 4589 / 0x11ED, Recommended: N [2]
• For FIPS-mode TLS, RFC 10024 identifies SecP256r1MLKEM768 as the practical choice when both components must use FIPS-approved mechanisms. Its ECDHE component must be implemented by a certified implementation; the ML-KEM component need not itself be certified under the described construction. [2]
• X25519MLKEM768 may also be implemented in a FIPS-approved manner, but RFC 10024 notes that the ML-KEM implementation must be certified, because ML-KEM is the first shared secret in the combiner. [2]

Bottom line: In FIPS mode, prefer SecP256r1MLKEM768 if your TLS/provider implementation supports it and has the required certification. X25519MLKEM768 is the broadly practical default outside that constraint.

[1] RFC 9954 (rfc-editor.org)
[2] RFC 10024 (auth48-transition.rfc-editor.org)

Citations:

• 1: https://www.rfc-editor.org/info/rfc9954/?utm_source=openai
• 2: https://auth48-transition.rfc-editor.org/authors/rfc10024.html?utm_source=openai

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- focused TLSProfiles callers ---'
rg -l 'TLSProfiles' --glob '*.go' . \
  | while IFS= read -r f; do
      case "$f" in
        config/v1/types_tlssecurityprofile.go) ;;
        *) printf '%s\n' "$f" ;;
      esac
    done

printf '%s\n' '--- focused FIPS/TLS profile references outside generated CRDs ---'
rg -n -C 3 'TLSProfiles|TLSGroupX25519MLKEM768|TLSGroupSecP256r1MLKEM768|TLSGroupSecP384r1MLKEM1024|FIPS|fips' \
  --glob '*.go' --glob '*.md' --glob '*.sh' --glob '*.yaml' --glob '*. Makefile' . \
  | rg -v 'payload-manifests/crds|zz_generated|vendor' \
  | head -n 500 || true

printf '%s\n' '--- generation metadata ---'
rg -n -C 3 'payload-manifests|crd.*gen|generate.*crd|update.*crd|operator.*crd|controller-gen' \
  Makefile hack config 2>/dev/null | head -n 400 || true

printf '%s\n' '--- count and unique copies of the disputed wording ---'
python3 - <<'PY'
from pathlib import Path
needle = "only the NIST P-curves"
matches = []
for p in Path(".").rglob("*"):
    if p.is_file() and "payload-manifests/crds" in p.as_posix() or p.as_posix() == "config/v1/types_tlssecurityprofile.go":
        try:
            n = p.read_text(errors="ignore").count(needle)
        except Exception:
            n = 0
        if n:
            matches.append((p.as_posix(), n))
print("files:", len(matches), "occurrences:", sum(n for _, n in matches))
for item in sorted(matches):
    print(item)
PY

Repository: openshift/api

Length of output: 42598

• config/v1/types_tlssecurityprofile.go#L18-L21 (this comment)
• config/v1/types_tlssecurityprofile.go#L173-L176
• config/v1/types_tlssecurityprofile.go#L281-L284
• payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml#L603-L606
• payload-manifests/crds/0000_10_config-operator_01_apiservers-CustomNoUpgrade.crd.yaml#L724-L727
• payload-manifests/crds/0000_10_config-operator_01_apiservers-Default.crd.yaml#L369-L372
• payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml#L603-L606
• payload-manifests/crds/0000_10_config-operator_01_apiservers-DevPreviewNoUpgrade.crd.yaml#L724-L727
• payload-manifests/crds/0000_10_config-operator_01_apiservers-OKD.crd.yaml#L369-L372
• payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml#L603-L606
• payload-manifests/crds/0000_10_config-operator_01_apiservers-TechPreviewNoUpgrade.crd.yaml#L724-L727
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-CustomNoUpgrade.crd.yaml#L189-L192
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-CustomNoUpgrade.crd.yaml#L310-L313
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-Default.crd.yaml#L268-L271
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-DevPreviewNoUpgrade.crd.yaml#L189-L192
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-DevPreviewNoUpgrade.crd.yaml#L310-L313
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-OKD.crd.yaml#L268-L271
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-TechPreviewNoUpgrade.crd.yaml#L189-L192
• payload-manifests/crds/0000_80_machine-config_01_kubeletconfigs-TechPreviewNoUpgrade.crd.yaml#L310-L313