> > Perhaps the below will help?
>
> > https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0 <https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0>
> > https://www.youtube.com/watch?v=OuH4vwmzP_o <https://www.youtube.com/watch?v=OuH4vwmzP_o>
>
> Oh, it absolutely does – thank you!
You're welcome, it is reasonable to guess you read the slides, and did
not watch the recording.
Guilty as charged. 😉
Though I’m pretty sure I will watch the recording later.
[from another post]
Once OpenSSL 3.5 is released, that'll be ML-KEM-1024, we'll be using the
NIST names for the algorithms. Only the TLS groups will be hyphen-free.
Now I’m getting PQ algorithms from the OQS provider available from Open Quantum Safe. Does the above mean that once OpenSSL 3.5 is released, I won’t need to use an extra provider, and OQS provider would be included in the standard distribution? Making the “outside” provider I’m currently using – obsolete?
> Perhaps you could clue me in regarding “(untrusted)” in the above?
The "untrusted" (not a priori trusted) certificates were not from the
trust store, I think I mentioned this during the presentation.
I’ll hold off my questions about this part until I watch the presentation then. I guess, merely stating “-trusted some_ca_cert.pem” on the command line isn’t going to cut it…
> My use case suggests (reasonably) long-term certificates, whose main
> difference from the traditional PKI for TLS or IPsec is that they’re
> used in implicit authentication, rather than for generating dynamic
> signatures during the handshake.
The main difficulty is that, as X.509 certs, verified in the usual way,
these would need to be issued by a trusted CA, whereas CAs willing to
issue KEM certs are pretty thin on the ground. With designs like
delegated credentials the EE key holder can mint their own.
Yes, quite right. But I expect this problem to be “resolvable” in my use case, at least when this actually gets deployed in the field. As I’m not the only one who needs to certify ML-KEM keys. 😉
This may not be a concern in your use-case, your mileage may vary...
Well, it is a concern – but I’m not a lone DonQuixote fighting an uphill battle against the current PKI. 😉
> Perhaps, I need to understand “delegated credentials” better. . . .
They're lightweight assertions that the key in the credential is
authorised to act on behalf of the signing EE cert key holder. They can
be issued by the EE key holder without involving any 3rd-party CA.
They require protocol support, the TLS extension needs to be implemented
on both ends.
Understood. Excellent, thank you!!
