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

[Michael Richardson]

A problem that I have with apps/req.c is that it is hardly a good reference
for how to use the API calls.

I think, ideally, that all of openssl.cnf should be entirely an artifact of
the apps, but there are (still, I think) things that can only by constructing
some openssl.cnf configuration and sending that down.  Many of those calls
are not documented, but many wrappers (ruby's openssl for instance) continue
to use.

I posted a notion a few years ago that the apps/* should be split off into a
new repo, should use only documented API calls, and should evolve separately
from the core libssl.  This is a documentation and d06f00d'ing exercise.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 





signature.asc
Description: PGP signature

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

[Jordan Brown]

On 12/22/2021 1:33 PM, Philip Prindeville wrote:
> Should supporting openssl.cnf be part of the library API, or
> externally handled in the command-line utility where it then passes in
> the values extracted from that file? 

I don't know how openssl.cnf factors into CSR creation with existing
tools.  The implementation that I did was entirely controlled by the
application and did not involve openssl.cnf.

I don't have an opinion on whether there should be a convenient way to
draw values from openssl.cnf into a CSR.  I would certainly start with
generating the CSR entirely from API calls, since that's the more
general case.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

Fwd: Utility of self-signed certs - Re: Questions about legacy apps/req.c code

[David von Oheimb]

Yeah, self-signed certs are absolutely useful - you just need to be very 
careful which ones you trust for what.


Such certs are widely used to provide trust anchor information, 
typically of root CAs,

but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even for end entities, such as locally known 
and trusted servers or email users.


I spent quite some effort to get their (optional) acceptance re-enabled 
in Thunderbird:
https://bugzilla.mozilla.org/show_bug.cgi?id=1523130 

but even one of their security(?) experts did not get my point and 
refused support.


    David

On 22.12.21 22:13, Jordan Brown wrote:

On 12/22/2021 1:08 PM, Philip Prindeville wrote:

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.


They're OK once you take a leap of faith, check the fingerprint, or 
copy the certificate out of band.


In some senses they are *better* than a CA-based cert, because once 
established they are not vulnerable to CA compromise.

--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

Fwd: Utility of self-signed certs - Re: Questions about legacy apps/req.c code

[David von Oheimb]

Yeah, self-signed certs are absolutely useful - you just need to be very 
careful which ones you trust for what.


Such certs are widely used to provide trust anchor information, 
typically of root CAs,

but conceptually and pragmatically, as Jordan also stated below,
they can make much sense even for end entities, such as locally known 
and trusted servers or email users.


I spent quite some effort to get their (optional) acceptance re-enabled 
in Thunderbird:
https://bugzilla.mozilla.org/show_bug.cgi?id=1523130 

but even one of their security(?) experts did not get my point and 
refused support.


    David

On 22.12.21 22:13, Jordan Brown wrote:

On 12/22/2021 1:08 PM, Philip Prindeville wrote:

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.


They're OK once you take a leap of faith, check the fingerprint, or 
copy the certificate out of band.


In some senses they are *better* than a CA-based cert, because once 
established they are not vulnerable to CA compromise.

--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

[Philip Prindeville]

> On Dec 22, 2021, at 2:18 PM, Jordan Brown  
> wrote:
> 
> On 12/22/2021 11:45 AM, David von Oheimb wrote:
>> 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 suspect that it would end up looking a lot like the existing API.  There 
> might be a few shortcuts possible, but fundamentally you need to set a 
> significant (and variable) number of parameters.  The straightforward way to 
> do that is with a "create object" function and "set parameter into object" 
> functions - and some of those parameters themselves need a similar set of 
> functions.
> 
> The existing API isn't bad, once you figure out how to use it.  It's been 
> several years since I wrote a CSR generator and so I don't remember how I 
> figured it out, but I think I might have had to look at req.c rather than 
> finding documentation.
> 

Should supporting openssl.cnf be part of the library API, or externally handled 
in the command-line utility where it then passes in the values extracted from 
that file?

I'm inclined to KISS and going with the latter.

-Philip

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

[Jordan Brown]

On 12/22/2021 11:45 AM, David von Oheimb wrote:
>
> 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 suspect that it would end up looking a lot like the existing API. 
There might be a few shortcuts possible, but fundamentally you need to
set a significant (and variable) number of parameters.  The
straightforward way to do that is with a "create object" function and
"set parameter into object" functions - and some of those parameters
themselves need a similar set of functions.

The existing API isn't bad, once you figure out how to use it.  It's
been several years since I wrote a CSR generator and so I don't remember
how I figured it out, but I think I might have had to look at req.c
rather than finding documentation.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

Re: Questions about legacy apps/req.c code

[Jordan Brown]

On 12/22/2021 1:08 PM, Philip Prindeville wrote:
> 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.

They're OK once you take a leap of faith, check the fingerprint, or copy
the certificate out of band.

In some senses they are *better* than a CA-based cert, because once
established they are not vulnerable to CA compromise.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

Re: Questions about legacy apps/req.c code

[Philip Prindeville]

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  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 
>  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
> 

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 
 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 



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 
> 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

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 
 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 



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 
> 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

Re: 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_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
>
>

Questions about legacy apps/req.c code

[Philip Prindeville]

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