Agree to your very first point about "generate a CSR to be signed elsewhere" being very different from "generate a self-signed certificate" or even "sign this CSR" (i.e. become a Registration Authority). I'm thinking of the case where you have an IoT (a router, a WAP, a digital camera, a smart phone, etc.) that wants to enroll itself with a Certificate Authority, such as with FIDO and its responsible for its own key pair. https://fidoalliance.org/how-fido-works/ I see there being limited application (utility) of self-signed certs, since they're pretty much useless from a security perspective, because they're unanchored in any root-of-trust. So yes, in my mind, the library support to generate a CSR would be useful with then registering that certificate via ACME, SCEP, EST, CMP, etc. I was thinking exactly the same thing about us needing more granularity of libraries. Maybe even libasn1 being carved out as its own library, even if other things like libssl and libx509 having dependencies on it. -Philip > On Dec 22, 2021, at 11:58 AM, Kyle Hamilton <aerowolf@xxxxxxxxx> 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@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 >
