Questions about legacy apps/req.c code

[Kyle Hamilton]

>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> 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/497cb2ab/attachment-0001.htm>