Abstraction for ASN.1 encoding subjectPublicKey and privateKey about oqs-provider HOT 5 CLOSED

I was thinking about using cmake's ExternalProject function. It allows to fetch, build and patch (if needed) and therefore include external projects as part of a cmake build. This will be similar to a "copy_from_upstream" mechanism but better integrates with cmake.

from oqs-provider.

The code to be integrated is available here:
https://github.com/Quantum-Safe-Collaboration/qsc-key-rfc/tree/master/qsc-key-encoder
It supports Dilithium, Falcon, SPHINCS+ and Kyber and allows several cases:

• encode full PrivateKeyInfo / SubjectPublicKeyInfo (PKCS#8 / SPKI)
• encode only privateKey / subjectPublicKey parts of PKCS#8 / SPKI
• encode private key with optional public key
• encode private key without optional public key
• encode private key and/or public key
• decode private key and/or public key (including decode private key with optional public key part to raw public+private key)

from oqs-provider.

@bhess: Do you intend to integrate the code from the spec repo above here or what's the next step to come to closure of this issue?

from oqs-provider.

Yes, my intention is to integrate this code which implements the API described above (before the next IETF). Either linking to the library from the repo or replicating the code here. Any thoughts?

from oqs-provider.

Either linking to the library from the repo or replicating the code here. Any thoughts?

Unsure what you mean by this: (shared lib) linking would be bad for the provider: The goal for it should be that it is self-contained and does not depend on external libs for correct execution. Code replication in turn would be sub-optimal, too, from a maintenance perspective. What about creating sth similar to the "copy_from_upstream" mechanism if you want to keep maintaining the code (only) in your spec repo?

from oqs-provider.