OSSL_PARAM behaviour for unknown keys

[Kurt Roeckx]

On Tue, Dec 15, 2020 at 08:45:45AM +0100, Richard Levitte wrote:
> Whatever we decide on this, I would rather not burden provider authors
> with having to check for all sorts of things they aren't interested in.

I think you write the provider just a little bit different than
what you might be doing now.

> I've often had the fictitious algorithm BLARGH (someone should invent
> it, just 'cause), and while everyone with access to specs could write
> a provider, some might extend it as well, with extra parameters (like
> the CRT params for RSA keys) or flags or whatnot.  If we burden the
> providers with the sort of checks that are discussed here, it would
> require every BLARGH implementation to be constantly in sync with
> every other BLARGH implementation.  That's not a very good idea (*)

So you're saying that the applications should change depending on
which provider it has loaded? One implementation can name the
parameter for the same functionality different than the other?

I guess it's then up to the application to query which provider is
loaded, and see which parameter it should set for that provider?

But it's unlikely that all applications will properly check that
the provider provides all the functionality it needs. And we
should do what we can to prevents problems.

> So, I'm thinking that control should remain with the application /
> libcrypto.  However, I'll also maintain that, as a matter of protocol,
> we can ask the providers to set the return_size field for any
> parameter they use, as a way to help out.  That would enable the use
> of functions like OSSL_PARAM_modified() on the application / libcrypto
> side when setting parameters, just at it currently does for getting
> them.  From a provider author point of view, I'd say that's a much
> lesser burden than having to have knowledge of all sorts of params any
> other provider might support.

To get back to the RSA / CRT example. If you write a provider to
do RSA but don't use the CRT parameters, and the application loads
the provided key with CRT parameters, it's not hard for a provider
to know some other provider might use the CRT parameters and so
can ignore it. But it's also fine that it returns an error at
first, the application will either switch to an other provider, or
the provider will get fixed to ignore it.

If it's for a parameter that enables a new mode, and the mode
is not supported by the provider, we need a way to check that that
mode is supported. For intance blake2 has an optional key, but we
never implemented it because the API didn't support setting it.
If at some point it is added, an application needs to have a way to
make sure it supported. The options I see are:
1) The fetch function should support requesting a version that
   has support for it.
2) You fetch something and:
   a) You set the parameter, and check for an error.
   b) You ask the settable parameters and check that it
      supports it. It's my understand that you can't get
      all the parameters in some cases, so this isn't always
      possible.

I don't actually see many applications do 2b), they'll do 2a) and
currently don't get an error. It's also likely they will not do 1)
correctly, because it was written against a provider that did
support it, so it was not clear they needed to request that
feature, and so again will currently not get an error, and will be
hard to debug.

We can detect that the application is trying to do something
that's not going to work and should return an error in that case.

We need 1), but the question is how fine grained we want to do
that, or what we expect a provider to implement asking for a
feature. For intance, if we want to load a multiprime RSA key, not
all providers will support that, and as far as I know, the FIPS
provider will not support that. Note all providers will even support
loading an RSA private key, so when fetch RSA, we really need to say
that we should be able to set the key. We need documentation that
says what you can expect to do depending on the features you
requested.

As far as I know, if you currently try to load a multiprime key
into the FIPS provider, it will not give you any error, it will
just not do what you want it to do.

We need to define how we're going to deal with all this. I prefer
that it's in some consistent way.


Kurt