OSSL_PARAM behaviour for unknown keys

Kurt Roeckx kurt at roeckx.be
Mon Dec 14 14:59:37 UTC 2020


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.


Kurt



More information about the openssl-project mailing list