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.

[ounsworth]

@baentsch Interesting question; I can see the advantage of implementing composite at the higher level so that it can inherit any RSA / ECC / ML-DSA implementation from any provider.

However, composite algorithms, for example id-MLDSA44-ECDSA-P256 is itself an algorithm that a given provider may or may not recognize the OID for, or it may contain component algorithms that the provider may or may not support. If you do this at the provider level then this is very clean: if the provider advertises support for id-MLDSA44-ECDSA-P256, then you expect it to work. So if composite was moved to core openssl, then how would the error path work if openssl recognizes the OID for id-MLDSA44-ECDSA-P256 and begins processing it, but then it cannot find a provider for MLDSA44?

[baentsch]

So if composite was moved to core openssl,

This is not my suggestion. My proposal was to consider doing a "composite" provider using openssl core mechanisms, not OQS ones for PQC ops. It's for example straightforward to find out in a provider whether other algorithms are supported (provided by any other currently active provider) or not and correspondingly react (e.g., to not advertise corresponding composite algorithms). A generalized proposal in #631 fyi.

[ounsworth]

That actually makes a lot of sense!
A provider that does only composites. It would not itself contain any algorithms, but would request ML-DSA, ECDSA, SHA256, etc from the OpenSSL provider ecosystem. That way the composite provider could be outside a FIPS boundary, for example. That actually makes a lot of sense.

[baentsch]

Good to hear. Please let me know if/when/as you become aware of such software becoming available: I'd gladly welcome a PR to remove this functionality from oqsprovider then: This would ease the effort implementing #375 and reduce the scope of #631 suitably.