Clemens
neverpanic@chaos.social@jarkko TLS in OpenSSL, GnuTLS, NSS are done, Go has key exchange shipped, signatures following soon.
OpenPGP just dropped a new RFC and @sequoiapgp has a branch. GnuPG will do something incompatible, so switching to a better implementation is probably in order.
Kernel either has a verification of ML-DSA signatures pending or already merged.
Beyond that, not much. Oracle promised something in Java second half of this year.
3
0
2
@jarkko for CAs for TLS, it seems Merkle Tree Certificates will be the way to go, but nobody has support for those yet and the standard isn't done.
0
0
1
@jarkko oh, and SSH also has key exchange already, both in OpenSSH and libssh. Signatures are currently being discussed in the IETF SSH WG.
0
0
1
I had issues on using Sequoia for kernel work but the specifics have been erased from my memory.
I would not mind to scraping GPG, and switching to Sequoia. After 17-20 years of proactive use or something like that, I still get lost in the configuration and forget what I was supposed to be doing 😅
GPG is also an over the top complex stack (gpg, pcscd, systemd services, gpgconf. ...). So yeah, it's bad 100% agree on that part :-) I don't have anything else good to say about GPG except compatibility...
1
0
0
1
0
0
@vbabka fancy for GPG ? :-)
1
0
2
Vlastimil Babka 🇨🇿🇪🇺🇺🇦
vbabka@mastodon.social@jarkko @neverpanic @sequoiapgp yeah can we instead of/in addition to PQC have a post-GPG cryptography?
1
0
1
1
0
1
Clemens
neverpanic@chaos.social@jarkko @sequoiapgp @vbabka There's still room for improvement, but given that we're looking for an alternative to put into RHEL 11, we're planning to take a swing at it over the next year or two.
1
0
0
So... not yet any actual effort done to verify but I'd figure that if sq fails somwhere it would be the defacto key topology most kernel maintainers use:
1. Public keys are at ~/.gnupg
2. The root key is offline
3. Private subkeys reside only inside the smartcard.
For most probably if sq scales to handle this type of topology with no gotchas and compromises. If not, sq is unsable for kernel development.
That is like THE edge case.
2
0
1
0
0
1
Clemens
neverpanic@chaos.social@jarkko @sequoiapgp @vbabka No idea about offline root keys, maybe @nwalfield knows. Smartcard support exists but needs some more polishing.
1
0
0
GPG semantics with any possible private blob is "try to use a private key"; i.e. not "use a private key".
And unlike I said earlier, this is universal for any private blob accress the key hierarchy.
Public blobs are never offline i.e. key hierachy is *always* available without sentinel data essentially.
1
0
1
If there is a huge delta, I'd rather roadmap this for the long-term. We don't have rush in kernel, I'd scrape GPG any day when the locking is gone.
1
0
0
Enterrprise distro schedule does not really connect either when it is about kernel dev because they are our "target device" not the "development platform". I'm just wondering a bit why RHEL schedule is that important in this discussion.
One more thing.
If you design this feature make it provider agnostic. It should be easily backed by smartcards, TPM2 chips, possibly even TEEs or enclaves (SGX.TDX, SNP etc.). I.e. how now private blob is read should really be one of t he adapters in this framework.
1
0
0
