OSSL_PARAMs

[Richard Levitte]

On Tue, 04 Jun 2019 14:57:00 +0200,
Salz, Rich wrote:
> 
> 
> >    Part of the idea was that this would be a means of communication
>     between application and provider, just like controls are with
>     libcrypto sub-systems.
>   
> 
> I can probably find the email thread (or maybe it was a GitHub
> comment on my proposal for params), where you said, quite
> definitively, that this was *not* a general-purpose mechanism but
> rather a way to expose the necessary internals for opaque objects
> like RSA keys.

Either I misunderstood what you said at the time, or you misunderstood
what I said...  there's definitely a disconnect here somewhere.

What I wonder is why it should be exclusively only one of those
options?

Either way, the OSSL_PARAM is defined publically and openly (i.e.
non-opaque), and we currently have the following functions in the
public API:

    EVP_MD_CTX_set_params
    EVP_MD_CTX_get_params
    OSSL_PROVIDER_get_params

I fully expect that more will come.  I have a branch where I've
EVP_MAC_CTX_set_params, for example, and I wouldn't be surprised if
EVP_CIPHER_CTX_set_params and EVP_CIPHER_CTX_get_params appear before
long (I'm actually rather surprised they haven't already), and I'm
absolutely sure we will see similar functions for asymmetric
algorithms.

> What changed your mind?
> 
> Perhaps not surprisingly, I agree with Shane's assessment and am
> strongly opposed to the project foisting this on everyone at this
> time.  @DavidBen, your thoughts?

Maybe we're reading differently, I didn't see Shane being opposed to
parameter passing in this way per se, just the exact form of the
OSSL_PARAM structure, which is different.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/