<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>@Philip,<br>
<br>
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).<br>
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.<br>
<br>
I do not like to separate the code sections that handle the
alternative case of generating a self-signed cert <br>
because there are strong similarities with generating a PKCS#10
CSR, so a split would introduce quite some redundancy.<br>
(The code would deserve some further cleanup, but this is a
general issue that holds for many, if not all, those apps.)<br>
</p>
<p> @Kyle,<br>
</p>
<p>your comments regarding the (self-)signature key to be used for
CSR signing vs. cert signing are not really to the point being
asked.<br>
<br>
Also your comments on OpenSSL library code size are a side topic
here, though I fully agree that it would be great if <br>
the crypto lib was relieved from much bulk (to which various
people including myself have added quite a bit recently)<br>
that would much better fit in higher-level library. I <a
moz-do-not-send="true"
href="https://github.com/openssl/openssl/pull/4992">suggested</a>
this 4 years back, but so far the project members have not<br>
found time for this. Later I re-phrased the issue later as a major
FR: <a moz-do-not-send="true"
href="https://github.com/openssl/openssl/issues/13440">https://github.com/openssl/openssl/issues/13440</a><br>
</p>
<p>Regards,</p>
<p> David</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 22.12.21 19:58, Kyle Hamilton wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPMEXDYKEGkCXEYRaQC-7jVHAuw9xo1YXJGyN27ZhkfbrFT3vA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">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.
<div dir="auto"><br>
</div>
<div dir="auto">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).
<div dir="auto"><br>
</div>
<div dir="auto">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.)</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">-Kyle H</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Dec 21, 2021, 22:25
Philip Prindeville <<a
href="mailto:philipp_subx@redfish-solutions.com"
moz-do-not-send="true">philipp_subx@redfish-solutions.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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.<br>
<br>
I'm thinking the shortest path might be to extract code from
apps/req.c as we know it's correct.<br>
<br>
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.<br>
<br>
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?<br>
<br>
The latter would allow me to move the CSR code into a library
and have the app exercise that API.<br>
<br>
The only downside I can see is that the self-signed
certificate path might need to duplicate some of the library
code.<br>
<br>
Is that acceptable?<br>
<br>
Thanks,<br>
<br>
-Philip<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>