OSSL_PARAM behaviour for unknown keys

[Dmitry Belyavsky]

Dear Kurt,

On Mon, Dec 14, 2020 at 10:10 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote:
> > Dear Kurt,
> >
> >
> > On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx <kurt at roeckx.be> wrote:
> >
> > > Hi,
> > >
> > > doc/man3/OSSL_PARAM.pod current says:
> > > Keys that a I<setter> or I<responder> doesn't recognise should
> > > simply be ignored. That in itself isn't an error.
> > >
> > > The intention of that seems to be that you just pass all the data
> > > you have, and that it takes data it needs. So you can pass it data
> > > that it doesn't need because it's only used in case some other
> parameter
> > > has some specific value. For example, depending on the DRBG mode
> > > (HMAC, CTR, HASH) you have different parameters, and you can just
> > > pass all the parameters for all the modes.
> > >
> > > I think for behaviour for a setter is not something that we want,
> > > it makes it complicated for applications to check that it will
> > > behave properly. I think that in general, if the applications
> > > wants to set something and you don't understand it, you should
> > > return an error. This is about future proofing the API. For
> > > instance, a new version supports a new mode to work in and that
> > > needs a new parameter. If it's build against a version that knows
> > > about it, but then runs against a version that doesn't know about
> > > it, everything will appear to work, but be broken. If we return
> > > an error, it will be clear that it's not supported.
> > >
> > > An alternative method of working is that the application first
> > > needs to query that it's supported. And only if it's supported
> > > it should call the function. But we don't have an API to query for
> > > that. You might be able to ask for which keys you can set, but it
> > > doesn't cover which values you can set. I hope we at least return
> > > an error for a known key with an unknown value. But it's my
> > > understanding that we currently don't always return all supported
> > > keys, and that the supported keys can depend on one of the set
> > > parameters.
> > >
> > > I suggest that we change the return value to indicate that all
> > > parameters have been used or not. For instance return 1 in case
> > > all used, return 2 in case not all used.
> > >
> > >
> > From my GOST implementor's experience, the provider can get a lot of
> > parameters.
> > Some of them are supported, some of them are not.
> >
> > The particular provider is the only subsystem that knows which parameters
> > are supported and which are necessary for the operations.
> >
> > So the caller can provide some unsupported parameters, some supported and
> > some totally wrong for the provider.
> > These are the cases that must be distinguishable on the caller side.
>
> If I understand you correctly, what you're saying is that it's
> sometimes ok to ignore some parameters. For instance, if you try
> to create an RSA object, and you pass it CRT parameters, and the
> implementation doesn't do anything with them, it can ignore them
> if it wants to.
>
> I would say that the provider should know what those parameters
> mean, so that it's not an "unknown key", it just ignores them,
> at which points it can say that it understands all the parameters.
>
> Some might argue that they don't want to use something that
> doesn't make use of the CRT parameters, but then they probably
> shouldn't be using that provider to begin with.
>
> > After that the provided EVP object should be either in a consistent state
> > or not, assuming the upcoming operation.
>
> The object should always be in a consistent state. I would prefer
> that in case of failure the object is not created (or modified).
> Which brings us to some other open points about the API we have. We
> should not introduce new APIs where you can modify the state of the
> object, so it can not be in a non-consistent state. It's much more
> simple to get things correct in that case. But as long as we have
> to support old APIs where it can be modified, the prefered
> consistent state is to not mofify the object on error. Some APIs make
> this very hard, so the other acceptable state is that you can free
> the object. With an API that doesn't allow modification, either
> you get a complete object, or you get no object.
>
>
I hope I've got a specific point of our disagreement.

There are 2 variants of using OpenSSL.
1. Algorithm-agnostic. We can deal with most of the algorithms in a more or
less similar way.
That was the way we dealt with various algorithms in libcrypto since 1.0
version.

2. Algorithm-specific. The API user should take into account which
algorithms are
supported by their application and provide some specific processing.

These are two different approaches.

The OpenSSL itself should be more or less algorithm-agnostic.
The providers (as engines before) are definitely algorithm-specific.
The openssl command line utilities in fact provide flexibility leaving the
burden of parameters setup to the end-user.

So if you pass some RSA-specific parameters to an EC key and vice versa,
you should get an (ignorable) error.
But when you have set the parameters and try to do a particular operation,
you either have a consistent set of parameters
(and get OK checking it) or not (and get an unrecoverable failure).

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20201215/b425eead/attachment.html>