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
