Re: ruby-openssl + provider interface: generating keys with provider

On Thu, Aug 28, 2025 at 03:03:08PM -0400, Michael Richardson wrote:

> Thank you very much for the reply.
> (Please excuse me if I seem grumpy: there is other unrelated shit)

You're welcome, understood, I'll keep that in mind. :-)

> Viktor Dukhovni <[email protected]> wrote:
>     > The distinction is real, I am not in the habit of linguistic pedantry.
>     > There's a difference between using the EVP API with a properties(7)
>     > value that fetches algorithm handles from a selected provider, and
>     > using the **provider API** to directly call the backend provider
>     > interfaces.
> 
> I never had any interest in calling the provider *API* directly.
> I guess the word "interface" is the source of confusion.
> I mean: the openssl library calls with OSSL_PROVIDER* in them.

Actually, I really am saying that you should not need to use any of the
functions mentioning `OSSL_PROVIDER *`, except perhaps in so far as your
application is explicitly loading some providers at startup.  Once all
the relevant providers are loaded, you really SHOULD be able to use just
the EVP API, with any explicit provider preferences indicated through
properties (`propq` arguments), to set a preferred non-mandatory
provider, you'd use "?provider=tpm2" or similar so that the "tpm2"
provider is preferred, but algorithms not found there are still found in
the "default" provider.

If you're having to reach into the OSSL_PROVIDER API in order to
generate or load keys, sign messages or verify signatures, something
is wrong.  Perhaps the documentation is poor, or you're not find the
right documentation (hard to find may be a variant of "poor").  Perhaps
you've talked yourself into a non-productive approach.  Or perhaps the
EVP API is actually materially deficient.  It now remains to figure out
which problem needs solving.


> I've deleted the rest of your EVP_[P]KEY comments, because clearly
> they do not apply.

Well, you keep saying that, but the EVP API is what the expected API
you're expected to use.  So if that fails to meet your needs, we need to
fix that.  In some cases there are additional providers that facilitate
that use, if, for example, a PKCS#11 provider had good "tpm2" support,
you might find that it meshes more naturally with the EVP layer and is
easier to use, but I don't have anything specific in mind at this time.

> I'm saying that the EVP API does not seem capable, and I'm asking for
> clarifications, fixes, and only if necessary, amendments.

Well, you haven't really provided solid evidence to back up that claim.
I'm willing to accept that there is room for improvement, and open
issues to fill any gaps, but these gaps are yet to be identified.

Let's first identify a simple clear task that isn't working for you.
Is it signing with an existing key that is stored in the TPM?  You
have a "message" to sign and a TPM key URI?  Or otherwise explain,
and provide some demo code.

-- 
    Viktor.

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aLEQnVxYVs6fIDcn%40chardros.imrryr.org.