Checklist

• I have checked the issues list
  for similar or identical feature requests.
• I have checked the pull requests list
  for existing proposed implementations of this feature.
• I have checked the commit log
  to find out if the same feature was already implemented in the
  main branch.
• I have included all related issues and possible duplicate issues
  in this issue (If there are none, check this box anyway).

Related Issues and Possible Duplicates

Related Issues

• None

Possible Duplicates

• None

Brief Summary

France's ANSSI will [stop certifying security products without post-quantum cryptography starting in 2027 (https://gizmodo.com/the-quantum-threat-to-encryption-is-coming-france-just-set-a-2027-deadline-2000773650) - the first hard regulatory deadline of its kind globally. Additional mandates: US NSA CNSA 2.0 (2027), NIST IR 8547 (deprecation by 2030, disallowed by 2035), EU critical infrastructure (2030).

Summary

Celery uses public-key cryptography for message signing (security serializer) with RSA/ECDSA - both quantum-vulnerable. Broker TLS connections (RabbitMQ, Redis) also lack PQC documentation or configuration guidance.

Two Gaps

1. Message Signing (security serializer)

Celery's security serializer signs task payloads with classical signatures. An attacker who captures signed tasks could forge them with a quantum computer. ML-DSA (FIPS 204) should replace RSA/ECDSA for message signing.

2. Broker TLS

Celery's broker_use_ssl passes TLS options to the broker client library. With OpenSSL 3.5+, PQC key exchange (X25519MLKEM768) works passively, but there is no documentation, testing, or explicit configuration guidance.

Context

• 29K stars — THE Python distributed task queue
• NIST FIPS 204 (ML-DSA)
• pyca/cryptography 47+ provides ML-DSA bindings

Design

Architectural Considerations

None

Proposed Behavior

Proposed UI/UX

Diagrams

N/A

Alternatives

None