Abstraction for ASN.1 encoding subjectPublicKey and privateKey

[bhess]

Goal: add an abstraction and implementation to support ASN.1 encoding of P8/SPKI as specified by Internet-drafts:

https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/
https://datatracker.ietf.org/doc/draft-uni-qsckeys-dilithium/00/
https://datatracker.ietf.org/doc/draft-uni-qsckeys-falcon/00/
https://datatracker.ietf.org/doc/draft-uni-qsckeys-kyber/00/
https://datatracker.ietf.org/doc/draft-uni-qsckeys-sphincsplus/00/

API would contain:

• encode: take the "raw" keys used by libOQS internally, return the specified encoding.
• decode: take the encoding according to a specification, return the "raw" keys used by libOQS internally.

API should allow to encode/decode private keys with/without optional public key component (#88).

The drafts get their own encode/decode functions and ASN.1 wrapping / encoding / TLV will be hidden behind them. Encoding will be selected by ENV variable. It would make interop to different IETF-drafts and IETF-draft-versions easier.

[bhess]

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)

[baentsch]

@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?

[bhess]

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?

[baentsch]

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?

[bhess]

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.