DMTF
Have certificate parsing and processing be its own library
spdm_crypt_lib.h currently encompasses
- Cryptography algorithms.
- x.509 certificate parsing and processing.
- Random number generation.
However there may be topologies where the Requester does not support any x.509 processing and instead offloads it to the Verifier, while still supporting cryptography operations. This can be more easily accomplished if x.509 processing is its own library. Also, the cryptography libraries libspdm currently supports, MbedTLS and OpenSSL, provide both cryptography and x.509 processing. However there will be cases where an integrator chooses, for example, Library A to perform cryptography and Library B to perform x.509 processing, and this cleanly separates the backing libraries.
Related issues https://github.com/DMTF/libspdm/issues/184 https://github.com/DMTF/libspdm/issues/496
Hi Steven, I would like do some research on this issue and this is a demo: https://github.com/liyi77/libspdm/pull/10, its work model is:
- Use cmake -G"NMake Makefiles" -DX509_PARSER=<mbedtls|openssl> to choose which parser you needed.
- If no X509_PARSER define, will use parser same as CRYPTO.
If someone would like to use a parser which not based on ssl lib, he/she could add own parser, like x509_parser_null.
Does it fit your vision? I would like do more research on *1117 If this patch doesn't misunderstand this issue.
Hi @liyi77. Yes it would be something like this, although as you know we'd need to fix #1117 before this could be implemented. Also, we should have the requirement that if decoupling the cryptography and certificate libraries causes performance or code size issues, that selecting a single library for both cryptography and certificates should bring in the expected optimizations like we're doing now.
With respect to your PR, I'd rename X509_PARSER to something like CERT_LIB since SPDM may support non-x509 certificates in the future.
