From a conceptual perspective, I think "creating a CSR" should be different than "signing a CSR with a given keypair", and on that reason alone I'd separate them, allowing some small code duplication.
The difference between "signing with a certified key" and "signing with its own key" is really just a matter of determining the IssuerDN to put into the tbsCertificate, and that can be either an automatic process (a flag on the certificate generation call, an automatic verification that the signing key matches the key to be signed, the certificate generation call being provided a NULL certificate or DN to identify the signer, or something else) or a manual process (require library clients to know the lore that a self-signed key also needs to copy the SubjectDN to the IssuerDN).
But, "generate a certificate" isn't something I'd personally put into the basic SSL or crypto handling libraries. The reason is because OpenSSL is still used in many embedded systems that will never use that functionality, and putting code paths in place that will never be used is both a waste of code space and potentially an invitation for attackers to exploit their presence. (The same goes for key generation, to a degree, but the value of new key generation can at be either limited to Denial of Service or, at best, reset the device for a new deployment.)
I know it'll never happen, but I'd love to see another libcrypto/libssl client library (libx509, maybe?) be used for the more esoteric aspects of creating and verifying certificates.
-Kyle H
On Tue, Dec 21, 2021, 22:25 Philip Prindeville <philipp_subx@xxxxxxxxxxxxxxxxxxxxx> wrote:
Hi,
I'm trying to add a library routine (or routines) to generate a CSR and make that available to users of Openssl at the API level.
I'm thinking the shortest path might be to extract code from apps/req.c as we know it's correct.
My only problem (so far) is dealing with the multiple places it bifurcates based on gen_x509 (versus newreq) -- which David pointed out to me in a separate mail thread back in mid-October.
What would be the downside to having two completely different code paths for handling -x509 (and gen_x509) i.e. a self-signed certificate versus generating a CSR?
The latter would allow me to move the CSR code into a library and have the app exercise that API.
The only downside I can see is that the self-signed certificate path might need to duplicate some of the library code.
Is that acceptable?
Thanks,
-Philip
