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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/