Add X.509 implementation using composite keys and sigs drafts

[dstebila]

• https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-keys/
• https://datatracker.ietf.org/doc/draft-ounsworth-pq-explicit-composite-keys/
• https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/

[christianpaquin]

Didn't we discuss prototyping the various hybrid approaches concurrently? I'd recommend doing this work in a separate branch, and not simply replace our current concatenation approach.

[baentsch]

I'd also second @christianpaquin maybe proposing as a compromise using the term "Add" instead of "Migrate" in this issue: Having both approaches (switchable by some means, e.g., environment variable) in one implementation/branch might be doable.

Reason from my side against dumping the current approach: A stable OQS-OSSL code base to establish interop with oqs-provider (currently working through open-quantum-safe/oqs-provider#2) would be better than changing this logic in two places at the same time. Also, this work already creates challenges (at least for me) as the OSSL3 provider API and OSSL X509 APIs are not yet perfectly in tune for external (provider) use. After a cursory glance at it this RFC might actually be more simple to implement with a completely new X509 code base only using the ASN.1 APIs rather than patching things...

[dstebila]

Good point re: trying in a separate branch for now. I didn't think too careful about the choice of word "migrate"; I'll change it to "Add".

[dstebila]

My understanding is that they're revisiting their approach, so there may be new drafts with different designs. Closing this until a clearer path forward emerges.