Post-Quantum Cryptography: RS256-locked tokens and TLS curve preferences strip PQC key exchange

[netanmangal]

France's ANSSI will stop certifying non-PQC products from 2027. The US Executive Order 14409 mandates PQC for all federal systems, with key establishment by 2030 and digital signatures by 2031. Australia's ASD/ACSC has published post-quantum vendor guidance urging organizations to assess PQC readiness across their supply chain.

Two concrete PQC gaps

1. Token signing locked to RSA

src/pkg/token/options.go in NewOptions() only allows *jwt.SigningMethodRSA and RSAPSS in its switch statement, with the default case returning "only RSA methods are supported". GetKey() type-asserts *rsa.PrivateKey. Every robot account token and registry pull/push token is RS256-only. Not even ECDSA is reachable, let alone ML-DSA (FIPS 204).

2. TLS curves actively strip PQC

src/common/http/tls.go explicitly pins CurvePreferences: {P256, X25519}. Go 1.24+ includes X25519MLKEM768 in its default curve list when CurvePreferences is nil, but this explicit override removes it. Harbor is actively opting out of PQC key exchange that Go provides for free.

Proposal

1. TLS fix (quick win): Remove the explicit CurvePreferences or add tls.X25519MLKEM768 to the list. This restores Go's passive PQC key exchange.
2. Token signing (longer term): Extend the signing method switch to support ECDSA and eventually ML-DSA (RFC 9964) once Go 1.27 ships crypto/mldsa.
3. Documentation: Add PQC readiness notes to Harbor's security documentation.

References

• NIST FIPS 203 (ML-KEM)
• NIST FIPS 204 (ML-DSA)
• US Executive Order 14409
• Australia ASD PQC Vendor Guidance

[netanmangal]

I can contribute the TLS CurvePreferences fix as a quick win, and follow up with broader signing method support.