feat(pqc): add native Post-Quantum Cryptography support to Easy-RSA

[jaberansariali]

Summary

This PR introduces first-class Post-Quantum Cryptography (PQC) support
to Easy-RSA, enabling generation and verification of PQC and hybrid
certificates using NIST-standardized algorithms.

Key Features

• New pqc algorithm mode via EASYRSA_ALGO=pqc
• Support for NIST PQC standards:
  • ML-DSA (FIPS 204)
  • ML-KEM (FIPS 203)
  • SLH-DSA (FIPS 205)
  • Falcon (FIPS 206)
  • Hybrid classical + PQC algorithms
• Automatic OpenSSL capability checks (OpenSSL ≥ 3.5 or OQS provider)
• New PQC CLI commands:
  • list-pqc, pqc-status, pqc-set-algo
  • pqc-recommend, pqc-key-info, pqc-verify
  • pqc-migration, pqc-help
• Clear prevention of silent fallback to legacy RSA/EC algorithms
• Documented configuration in vars.example

Motivation

Easy-RSA currently supports only classical cryptography. With NIST PQC
standards finalized, adding native PQC support enables forward security
and crypto-agility for long-lived PKI deployments.

Compatibility

• Existing RSA/EC workflows are unaffected
• PQC is opt-in only
• Hybrid mode ensures backward compatibility

Requirements

• OpenSSL 3.5+ or
• Open Quantum Safe provider (oqsprovider)

Testing

• Generated PQC CA using ML-DSA-65
• Verified certificate signature and public key algorithms
• Tested hybrid and pure PQC modes

[jaberansariali]

Hi @TinCanTech,

Thank you for the feedback and for re-opening this in the new PR. I apologize for the initial confusion; I closed the first PR to ensure I was submitting from a dedicated branch rather than master, following the contributing guidelines.

I’m glad to hear this is being considered for the long term. I’m fully available to discuss the implementation, make adjustments based on your review, or split the changes into smaller parts if that helps the review process.

Looking forward to making Easy-RSA quantum-ready with your guidance!

[TinCanTech]

@jaberansariali thank you for this PR.

It will take some time to review, so please be patient.

[spatterIight]

https://words.filippo.io/crqc-timeline/

Based on the above article I think this would be a really much needed improvement! Thank you

[TinCanTech]

@jaberansariali FTR, init-pki pqc does not work.

Error: append PQC vars

Directions:

• The above error is caused by use of conditional &&, which must be replaced by a full if/then..
• EasyRSA does not use test [ -n string ], please drop the -n.

Also, I'm not happy for EasyRSA to maintain text lists of PQC algorithms.
This section will not be accepted as-is:

# ============================================================
# Post-Quantum Cryptography (PQC) Support for OpenSSL 3.5+
# ============================================================
# NIST-standardized and candidate post-quantum / hybrid algorithms
# supported by OpenSSL 3.5+ via built-in PQC or the OQS provider.
# ============================================================

# --- PQC Algorithm Definitions ---

...

[jaberansariali]

Dear @TinCanTech

Thanks for the feedback. I’ve pushed a follow-up commit addressing these points:

• Replaced the conditional && expressions in the init-pki pqc path with full if/then blocks.
• Removed the -n string tests and now use Easy-RSA’s existing [ "$var" ] style.
• Removed the maintained lists of PQC algorithm names. Easy-RSA now queries the active OpenSSL providers at runtime for the available signature and KEM algorithms.
• Updated vars.example and the PQC help text so they no longer contain a hard-coded algorithm inventory.
• Centralized the OpenSSL provider arguments through a wrapper so the selected provider and provider path are applied consistently.

The changes are in commit a461461.

Please let me know whether this runtime provider-based approach matches the direction you had in mind, or whether you would prefer any further adjustments.