@Philip,
it should not be hard to copy the core code from apps/req.c and
cut out all parts not needed for generating a PKCS#10 CSR
(including its self-signature).
Yet beware that a general-purpose library function that has (at
least) the flexibility offered by that app would need a
non-trivial set of parameters.
I do not like to separate the code sections that handle the
alternative case of generating a self-signed cert
because there are strong similarities with generating a PKCS#10
CSR, so a split would introduce quite some redundancy.
(The code would deserve some further cleanup, but this is a
general issue that holds for many, if not all, those apps.)
@Kyle,
your comments regarding the (self-)signature key to be used for
CSR signing vs. cert signing are not really to the point being
asked.
Also your comments on OpenSSL library code size are a side topic
here, though I fully agree that it would be great if
the crypto lib was relieved from much bulk (to which various
people including myself have added quite a bit recently)
that would much better fit in higher-level library. I suggested
this 4 years back, but so far the project members have not
found time for this. Later I re-phrased the issue later as a major
FR: https://github.com/openssl/openssl/issues/13440
Regards,
David
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
