PKCS#10 CSR generation and bulky crypto library - Re: Questions about legacy apps/req.c code

[David von Oheimb]

@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_subx at redfish-solutions.com 
> <mailto:philipp_subx at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20211222/0a167c59/attachment.htm>