For our post-quantum cryptography effort, we need component owners to test whether their components need some changes for PQC key-exchange or they work out of the box.

The goal of this testing is to answer this question:
If I enable PQC through crypto-policies, on both server and client, will then ML-KEM key exchange (or hybrid thereof) actually be used in all the TLS connections that happen as part of this component?

For setup-type components, the question changes to: Do all the workflows in this component setup the environment in which TLS connections will use ML-KEM key exchange (or hybrid thereof) if PQC is enabled through crypto-policies (even if it's enabled after the workflow is finished, host registered etc.)?{}

Test on Satellite 6.18.

This is how you enable PQC on the clean Satellite server on RHEL 9.6:

# cat <<EOF >>/etc/yum.repos.d/rhel97.repo
[rhel97-baseos]
name = RHEL 9.7 BaseOS
baseurl = https://<DOWNLOAD>/rhel-9/nightly/RHEL-9/latest-RHEL-9.7/compose/BaseOS/x86_64/os/
metadata_expire = 1
enabled = 1
gpgcheck = 0

[rhel97-appstream]
name = RHEL 9.7 AppStream
baseurl = https://<DOWNLOAD>/rhel-9/nightly/RHEL-9/latest-RHEL-9.7/compose/AppStream/x86_64/os/
metadata_expire = 1
enabled = 1
gpgcheck = 0
EOF
#
# satellite-maintain packages unlock
# dnf update openssl crypto-policies curl
# update-crypto-policies --set DEFAULT:PQ
# reboot 

On RHEL 10 clients, you can enable PQC using these steps: https://www.redhat.com/en/blog/post-quantum-cryptography-red-hat-enterprise-linux-10

After enabling PQC, you can do whatever you're testing, capturing the communication so you can verify it used PQC KEX, which is MLKEM a.k.a. CRYSTALS-Kyber used in a hybrid schema X25519MLKEM768 a.k.a. group 4588. When you see this has been used, it's good. (When you disable everyting non-mlkem, even better; that would require a custom crypto-policy and it's said by the authors of crypto-policies that they themselves refuse to do it because it breaks things.)

So, in the simplest case, you can just

openssl s_client -connect <FQDN>:443 | grep -i mlkem 

where you can conclude that the TLS connection has been initiated with MLKEM if you see:

Negotiated TLS1.3 group: X25519MLKEM768

Usually, things are harder though, simulating with openssl won't cut it. Then you can

# dnf install wireshark-cli
# tshark -f "tcp port 443" -i any -w /tmp/test.pcap 

(now do the thing you are testing)
Then stop capturing, copy that .pcap file to your local machine and open it in Wireshark. In the TLS packet with handshake, in the key share entry, you should see that X25519MLKEM768 (group 4588) has been used.

What is "the thing"? Whatever you're testing. When I test Global Registration, I run registration. If I tested Hammer, I'd run some Hammer command.

We are interested in all the possible TLS connections in a given component between the host and Satellite.
We are not interested in any other connections than TLS.
We are not interested in TLS connections between Satellite services or cloud.

Expected outcome is one of:

• PQC KEX supported out-of-the-box (when PQC KEX is enabled on both sides, it will simply work without any further actions){}
• PQC KEX supported with minor changes: (config or template changes needed, specify what needs to change)
• PQC KEX not supported (code changes needed)

When you are done, please CLOSE the subtask and put the results in its description, together with analysis and description of what you did.

If this is not applicable to your component (because there is no TLS communication between host and Satellite in that component), then PQC is considered suppported in that component (because supporting it is a no-op).

(If you want to go above and beyond, you can also test PQC KEX in TLS connections to external services (CDN, RH Cloud), SSH connections, and TLS connections within the Satellite itself. Even more, you can test whether the component works with ML-DSA certificates. For this, I'm not writing a guide right now (because there are too many problems expected) so you'll be on your own. But it can save you time in the future because this testing will also be needed in the next stages.)

For example of how you can do things, see the Remote Execution subtask. The method is up to you, you are the expert at your own component! For crypto-related issues, ask the PQC effort owner - lhellebr.