levitte at openssl.org
Tue Jun 4 13:26:30 UTC 2019
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
Either way, the OSSL_PARAM is defined publically and openly (i.e.
non-opaque), and we currently have the following functions in the
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
> 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.
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project