This looks good to me FWIW, but my experience with Transit and PQC is limited at best.

I do think some tests would be nice, likely in these locations:

• builtin/logical/transit/path_keys_test.go
• helper/keysutil/policy_test.go

Working on it

Hey @f-hc! I've expressed this in a few places, though, apparently not on #496 which is unfortunate... but I think waiting until Go toolchain natively supports ML-DSA & friends is perhaps our best approach.

As much as I appreciate the work of the Cloudflare team, ultimately the Go team will only face pressure to add it when the community declines to use third-party libraries for it. Ultimately, using a third-party crypto library isn't feasible, as crypto/x509 isn't pluggable and so many places require it externally. So we need the Go standard library to support these algorithms as they're unlikely willing to make x509 externally pluggable.

While we could enable thus merge this for Transit, I think Transit has ultimately best served as a Go standard crypto library package.

(There's also a tangential discussion of if we should be using circl or liboqs, a fellow Linux Foundation project and consortium of many other vendors.)

All this to say, I don't know what I think. I was hoping, at the time I wrote that RFC initially, that PQC would be within the next year or so. It has now been over a year and we've not seen positive progress.

The actionable part, though, is ML-KEM if you're interested in that instead! That's already part of the standard library, and some discussion of key exchange has occurred, e.g., in the context of #655.

Hello @cipherboy, thank you for the clarification.
I'll convert this PR to draft and be waiting for the RFC.

Hello @cipherboy, thank you for the clarification. I'll convert this PR to draft and be waiting for the RFC.

@f-hc @DanGhita If there's general appetite for a PQC ahead of Go standard library... We do have openbao-plugins. 🤔

We could fork Transit+keysutil into a PQC-only (experimental?) plugin, that could ultimately be folded into this version, depending freely on liboqs or circl or whatever we want.

My biggest worry is that key storage might differ between Go and liboqs/... (and I've not been overly happy with how keysutil does this today anyways for that matter), so there may not be a clean upgrade path.

At any rate, it'd let us iterate towards a long-term solution, though perhaps requiring an import+export operation once this version is improved.

Thoughts?