@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
<https://github.com/openssl/openssl/pull/4992> 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
<https://github.com/openssl/openssl/issues/13440>
Regards,
David
On 22.12.21 19:58, Kyle Hamilton wrote:
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_s...@redfish-solutions.com
<mailto:philipp_s...@redfish-solutions.com>> 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
