You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 1, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 1, 2026. It is now read-only.
Dual certificate support does not cover keyring-provided client certificates #151
ktls-utils 1.3.0 added client-side dual certificate support (commit facd084) so that a client can present a post-quantum certificate alongside a traditional RSA certificate. That work covers only certificates loaded from /etc/tlshd.conf. When an NFS client specifies alternate certificates at mount time (-o xprtsec=mtls,cert_serial=...,privkey_serial=...), the certificate and private key arrive via the .nfs keyring, and there is currently no way to provide or select a PQ certificate for the handshake.
Design questions raised in the linux-nfs / kernel-tls-handshake discussion of this gap:
Add separate PQ certificate and PQ private key parameters to the handshake upcall, or
Store lists of both PQ and RSA certificates and private keys under the existing keys and teach tlshd to parse both out of them (feasibility unverified).
The keyring-based mount UI itself is being reworked; whatever replaces it needs to carry PQ authentication material as well.
ktls-utils 1.3.0 added client-side dual certificate support (commit facd084) so that a client can present a post-quantum certificate alongside a traditional RSA certificate. That work covers only certificates loaded from /etc/tlshd.conf. When an NFS client specifies alternate certificates at mount time (
-o xprtsec=mtls,cert_serial=...,privkey_serial=...), the certificate and private key arrive via the.nfskeyring, and there is currently no way to provide or select a PQ certificate for the handshake.Design questions raised in the linux-nfs / kernel-tls-handshake discussion of this gap:
The keyring-based mount UI itself is being reworked; whatever replaces it needs to carry PQ authentication material as well.
Reported by Sagi Grimberg and triaged by Scott Mayhew:
https://lore.kernel.org/all/fd4aaf4e-b1b7-4ca2-bc93-955c31fab317@grimberg.me/
https://lore.kernel.org/all/afUKzeUYPhb97DX4@aion/
Related: #113 (original PQC support, closed).