NIST PQC certification composite vs hybrid approach.

[suresh043]

Hi Experts,

I've been going through draft versions of PQC x509 authentication implementation. I came across mainly composite certificates and hybrid certificates. In composite certificates PQ/T parameters are concatenated and in hybrid we have "alternative" extensions for PQ.

Now if I want to add PQC certificate based authentication for TLS (ML-DSA with some traditional one) which one I can choose to implement composite or hybrid ? Since both are not interoperable with each other (IMO).

Considering above had some questions:

1. Once approaches get finalize by NIST. Will it allow both hybrid and composite approaches or only one. ? (In your opinion).
2. Any idea which one may get approved or industry is adopting. ?
3. Does liboqs providers supports for both ? I believe yes.
4. From point 1 if both gets approved what about interoperability. If only one gets approved what about entireties which supporting non-approved implementation.?

cc: @feventura

Thank in advance. And please correct if I misunderstood anything.
Suresh Jadhav :-)

Ref:
https://lamps-wg.github.io/draft-composite-sigs/draft-ietf-lamps-pq-composite-sigs.html
https://www.mhlw.go.jp/content/10808000/001012539.pdf #section 9
https://pkic.org/pqccm/

[baentsch]

Hi Suresh,

I'm pretty far away from following standardization activities, so I don't dare to offer an answer to 1 or 2, but suggest to ask that question at a project more closely following IETF, namely the OpenSSL project, e.g. here or in the specific context of ML-DSA here. Also, of course @feventura is very actively following all IETF activities, so he'll probably have an opinion to share. @praveksharma : Are you also still active in the IETF hackathon and have something to contribute?

On item 3, I do think the answer is Yes as folks are using oqsprovider for interop testing in both contexts. It's an undecided issue whether oqsprovider will keep doing that as standardization progresses: See #610 if you'd like to chime in to the discussion.

Item 4 IMO is nothing this project can answer, but how/whether interoperability is specified and tested.

[suresh043]

Thanks @baentsch for responding. I've raised similar question on OpenSSL forum too #26435
But happy to hear from @feventura , @praveksharma. if they have anything interesting.

[johngray-dev]

Composites are on track for standardization as they were adopted by IETF. We are doing a push to try and get all the outstanding issues resolves by the next IETF and plan to publish a version 4 of the composite signatures draft and a version 6 draft of the composite KEM draft in the coming weeks. We anticipate any changes after that will be minor and that standardization should follow after a few rounds of mostly minor editorial changes.

https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/03/
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/05/

[feventura]

Hello @suresh043 , as John wrote, Composite are very close to standardization from IETF and I'm not aware if hybrids are going to be standardized.

As for question 2, I anticipate that the industry will use what is standard, and that should be Composite, but its hard to tell. As for an example, SWIFT already made a statement supporting Composite sigs and kems, and the tls hybrid design: https://mailarchive.ietf.org/arch/msg/spasm/JKpavEtFH4d711_M1SlOKpAni70/

For the interop the ietf hackathon group has been testing existing implementations: https://github.com/IETF-Hackathon/pqc-certificates

[suresh043]

It helped! thanks a lot for your input @johngray-dev and @feventura

[baentsch]

Thanks for the heads-up @johngray-dev @feventura . If you should consider contributing corresponding code again, you might eventually also consider contributing to OpenSSL a pure composite provider similar to openssl/openssl#25884 and openssl/openssl#25990 (not for ML-KEM, but for ML-DSA, of course): The advantage would be that that then could use the standard, production level code via the OpenSSL EVP APIs (and default/fips provider) and not be tied to the research grade OQS-implementations for ML-DSA in oqsprovider. FWIW, sample keymanagement code here; composite signature operation logic would need to go to the signature function set and may be worth while modelling after the KEM hybrid logic here.