[TLS] Re: ML-KEM IANA and draft-connolly-tls-mlkem-key-agreement codepoint and inconsistencies
On Thu, Mar 6, 2025 at 11:30 PM John Mattsson wrote: > Great that X25519MLKEM768 and MLKEM1024 will be in the 3.5 LTS release > https://openssl-library.org/post/2025-02-04-release-announcement-3.5/ > > Also great to see DTLS 1.3 as a top priority for 3.6. > > https://openssl-communities.org/d/HCdTYIoN/priorities-for-3-6 > How we determine feature priorities within OpenSSL is a multi-step process involving community input to the OpenSSL Foundation (which is what you are linking to there) and to the OpenSSL Corporation and then discussions within the elected representatives of each community advising the Foundation and Corporation boards and then final decisions after that (with announcement). There is no sense as yet of "a top priority" as such and there is always more on the ask list for a new release that there are resources and time to be able to add everything in. However DTLS 1.3 is definitely in the mix of things being considered. It was also in the list of things for OpenSSL-3.5 but didn't make it - PQC support became a higher priority once NIST released the final standards for ML-KEM, ML-DSA and SLH-DSA. Joining the communities site and providing input via https://openssl-communities.org/ is how to influence these sorts of decisions and input and participation is very much welcome. Tim. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: ML-KEM IANA and draft-connolly-tls-mlkem-key-agreement codepoint and inconsistencies
On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski wrote: > May I know if you have a plan for FIPS certificaton for PQC after release? > Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation in April once the release is final - and that will include the PQC algorithms that have been added. Our testing for ML-KEM, ML-DSA and SLH-DSA uses ACVP published test data as the basis along with some interesting scripts to get the test data into a format our test suites support. There is also a multi-vendor KMIP PQC interop running this week that has vendors using OpenSSL-3.5 and Bouncy Castle Java 1.81 (beta) and that is exercising the same ACVP tests via KMIP between KMIP clients and KMIP servers - but that is in the context of the day job rather than OpenSSL - see https://groups.oasis-open.org/discussion/kmip-tc-interop-process-2025-for-pqcpdf-uploaded as a starting point for information on that activity. That testing also covers X25519MLKEM768 for those vendors which have that capability enabled. ML-DSA certificates are not within the scope of that test activity. There is also on-going discussion between vendors about a PKCS#11 v3.2 PQC focused interop but timing and participants for that haven't yet been figured out. Tim ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Allow using serverAuth certificates for mutual TLS (mTLS) authentication in server-to-server usages - updates rfc5280 and rfc6066
Many protocols use mutual authentication within TLS. One such protocol is KMIP - Key Management Interoperability Protocol - see https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip In KMIP mutual authentication at the TLS level is mandatory. I don't get the rationale for Google wanting to basically ban any CA that issues with an EKU for client authentication - but then the tendancy to be very web-centric and the poor handling of client authentication within browsers does lead to unfortunate decisions being made. It would also make logical sense I assume (from a Google perspective) to remove client authentication support entirely from the protocol. Redefining that certificates that operate as a client inside TLS client authentication to be packaged or presented as something other than what they are also seems like the wrong way to solve this issue to me. Calling a client a server for a specific context of usage does not seem like a "solution". Tim. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
I support adoption of the draft with or without an applicability statement. I do not see merit (or even consistency) in the arguments raised about prioritisation or that code points can simply be registered. I also see the arguments that certain individuals don't see a need for this as not at all compelling given that there are more than enough individuals that have voiced a need or desire. Not seeing a need yourself should not act as a blocker where others see a need. The reasons so far seem to distil down to a dislike for the algorithm or dislike for having a choice and concerns that publishing an RFC will encourage adoption. That is the point - there are enough individuals that want to do this and they should have a stable interoperable way to do it. Tim. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
