Composite sigs update

[feventura]

This PR include:

• Documentation requested by Missing Composite documentation #475
• Double OCTET STRING encoding for ED private key according with RFC 8410 pointed by The privateKey encoding for pure ml-dsa differs from the privateKey encoding for the ml-dsa part in composite ml-dsa-xxxx #466
• Some extra documentation updates that were missed when the composite code was migrated from "draft-ounsworth-pq-composite-sigs" to "draft-ietf-lamps-pq-composite-sigs"

[feventura]

Changed the logic on get_composite_idx to one that would not depend on the idx might be an issue if the two lists compared are not in sync, instead the search to get the OID is done by the algorithm name.
This would close #552 .

[baentsch]

Thanks for the update @feventura and sorry for the delay reviewing: I had hoped other committers take a look but after 2 weeks guess that won't happen (or they don't like the code :).

So, generally I'm OK with the diffs I understand -- but cannot claim I do understand all. But given this code is not for serious use but meant to support research and testing, that's arguably OK (unless someone objects?).

So my question to you (and maybe @praveksharma if you're still following the IETF interop hackathon?): Is this code working OK there (not just for composite but also for plain PQC and hybrid)? That for me would be enough of an indication to approve the PR. Merging this would also be a "functional change" justification to do a new release, agreed, @praveksharma ?

[baentsch]

Thanks for the update and explanations, @feventura . LGTM for now.

@praveksharma, would you be OK merging this and cutting an RC for 0.7.2 giving that some real reason for existence? Or would you want me to do that?

[praveksharma]

@praveksharma, would you be OK merging this and cutting an RC for 0.7.2 giving that some real reason for existence? Or would you want me to do that?

Thank you for reviewing this PR @baentsch, I will handle the 0.7.2 release.

[baentsch]

Thank you for reviewing this PR @baentsch, I will handle the 0.7.2 release.

Thanks @praveksharma ! Before doing that, can I repeat the question whether you (or anyone else) tested this functionally, e.g., in the IETF hackathon testbed?

[praveksharma]

Before doing that, can I repeat the question whether you (or anyone else) tested this functionally, e.g., in the IETF hackathon testbed?

I believe there is interop testing being done with composite signatures but not all participants have them implemented just yet (see here). As more participants implement composite sigs interop testing may uncover issues that need addressing. At the moment the oqs-provider implementation isn't being tested, I shall enable these tests along with making the switch to the R4 format during the hackathon this weekend.

[feventura]

@baentsch I missed you question about IETF hackathon.
We have a compatibility matrix (https://ietf-hackathon.github.io/pqc-certificates/), the automated test results show the interop results we generate in git actions, for oqs we use the this docker container (https://hub.docker.com/r/openquantumsafe/oqs-ossl3).
The automatic validation is done using oqs and bouncycastle, some of the composite is failing with oqs at this moment because some already implemented the changes for -03 and I haven't done that yet for oqs.
This matrix also include the pure PQ algorithms.
The manually-uploaded matrixes are not updated for oqs.

[baentsch]

@baentsch I missed you question about IETF hackathon. We have a compatibility matrix (https://ietf-hackathon.github.io/pqc-certificates/), the automated test results show the interop results we generate in git actions, for oqs we use the this docker container (https://hub.docker.com/r/openquantumsafe/oqs-ossl3). The automatic validation is done using oqs and bouncycastle, some of the composite is failing with oqs at this moment because some already implemented the changes for -03 and I haven't done that yet for oqs. This matrix also include the pure PQ algorithms. The manually-uploaded matrixes are not updated for oqs.

Thanks for the pointers, @feventura . Looking at the matrix it seems oqsprovider passes just MLDSA44ipd and some SLH-DSA algs or do I misunderstand something here? Not exactly positive... So is your statement that with this PR landed, oqsprovider will pass more?

[feventura]

@baentsch I missed you question about IETF hackathon. We have a compatibility matrix (https://ietf-hackathon.github.io/pqc-certificates/), the automated test results show the interop results we generate in git actions, for oqs we use the this docker container (https://hub.docker.com/r/openquantumsafe/oqs-ossl3). The automatic validation is done using oqs and bouncycastle, some of the composite is failing with oqs at this moment because some already implemented the changes for -03 and I haven't done that yet for oqs. This matrix also include the pure PQ algorithms. The manually-uploaded matrixes are not updated for oqs.

Thanks for the pointers, @feventura . Looking at the matrix it seems oqsprovider passes just MLDSA44ipd and some SLH-DSA algs or do I misunderstand something here? Not exactly positive... So is your statement that with this PR landed, oqsprovider will pass more?

Talking pure PQ, yes it is just passing MLDSA44ipd and some SLH-DSA algs, the MLDSA65ipd, MLDSA87, Falcon512 and Falcon1024 are failing on the bouncycastle interop. (you can see that by looking at the tables below the big one)
The other ones, the empty cells, there is no artifact from oqs generated using that alg.
The composite ones will not change with this PR, the main implementation of this PR relate to the private key, and the artifacts are self-signed certs.

[baentsch]

Thanks for the contribution and background information @feventura !