<div dir="ltr"><div dir="ltr">Dear Kurt,<div><br></div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
doc/man3/OSSL_PARAM.pod current says:<br>
Keys that a I<setter> or I<responder> doesn't recognise should<br>
simply be ignored. That in itself isn't an error.<br>
<br>
The intention of that seems to be that you just pass all the data<br>
you have, and that it takes data it needs. So you can pass it data<br>
that it doesn't need because it's only used in case some other parameter<br>
has some specific value. For example, depending on the DRBG mode<br>
(HMAC, CTR, HASH) you have different parameters, and you can just<br>
pass all the parameters for all the modes.<br>
<br>
I think for behaviour for a setter is not something that we want,<br>
it makes it complicated for applications to check that it will<br>
behave properly. I think that in general, if the applications<br>
wants to set something and you don't understand it, you should<br>
return an error. This is about future proofing the API. For<br>
instance, a new version supports a new mode to work in and that<br>
needs a new parameter. If it's build against a version that knows<br>
about it, but then runs against a version that doesn't know about<br>
it, everything will appear to work, but be broken. If we return<br>
an error, it will be clear that it's not supported.<br>
<br>
An alternative method of working is that the application first<br>
needs to query that it's supported. And only if it's supported<br>
it should call the function. But we don't have an API to query for<br>
that. You might be able to ask for which keys you can set, but it<br>
doesn't cover which values you can set. I hope we at least return<br>
an error for a known key with an unknown value. But it's my<br>
understanding that we currently don't always return all supported<br>
keys, and that the supported keys can depend on one of the set<br>
parameters.<br>
<br>
I suggest that we change the return value to indicate that all<br>
parameters have been used or not. For instance return 1 in case<br>
all used, return 2 in case not all used.<br>
<br></blockquote><div><br></div><div>From my GOST implementor's experience, the provider can get a lot of parameters.</div><div>Some of them are supported, some of them are not.</div><div><br></div><div>The particular provider is the only subsystem that knows which parameters are supported and which are necessary for the operations.</div><div><br></div><div>So the caller can provide some unsupported parameters, some supported and some totally wrong for the provider. </div><div>These are the cases that must be distinguishable on the caller side.</div><div><br></div><div>After that the provided EVP object should be either in a consistent state or not, assuming the upcoming operation.</div><div>And the possibility to find out whether the state is consistent and suitable for the upcoming operation or not is a must and should be provided by an API. </div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>