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 se
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
tool
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
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
> 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 wou
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
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 fingerp
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
@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
@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
>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 j
11 matches
Mail list logo
