<div dir="ltr"><div dir="ltr">Dear Kurt,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 14, 2020 at 10:10 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">On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote:<br>
> Dear Kurt,<br>
> <br>
> <br>
> On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx <<a href="mailto:kurt@roeckx.be" target="_blank">kurt@roeckx.be</a>> wrote:<br>
> <br>
> > 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>
> ><br>
> From my GOST implementor's experience, the provider can get a lot of<br>
> parameters.<br>
> Some of them are supported, some of them are not.<br>
> <br>
> The particular provider is the only subsystem that knows which parameters<br>
> are supported and which are necessary for the operations.<br>
> <br>
> So the caller can provide some unsupported parameters, some supported and<br>
> some totally wrong for the provider.<br>
> These are the cases that must be distinguishable on the caller side.<br>
<br>
If I understand you correctly, what you're saying is that it's<br>
sometimes ok to ignore some parameters. For instance, if you try<br>
to create an RSA object, and you pass it CRT parameters, and the<br>
implementation doesn't do anything with them, it can ignore them<br>
if it wants to.<br>
<br>
I would say that the provider should know what those parameters<br>
mean, so that it's not an "unknown key", it just ignores them,<br>
at which points it can say that it understands all the parameters.<br>
<br>
Some might argue that they don't want to use something that<br>
doesn't make use of the CRT parameters, but then they probably<br>
shouldn't be using that provider to begin with.<br>
<br>
> After that the provided EVP object should be either in a consistent state<br>
> or not, assuming the upcoming operation.<br>
<br>
The object should always be in a consistent state. I would prefer<br>
that in case of failure the object is not created (or modified).<br>
Which brings us to some other open points about the API we have. We<br>
should not introduce new APIs where you can modify the state of the<br>
object, so it can not be in a non-consistent state. It's much more<br>
simple to get things correct in that case. But as long as we have<br>
to support old APIs where it can be modified, the prefered<br>
consistent state is to not mofify the object on error. Some APIs make<br>
this very hard, so the other acceptable state is that you can free<br>
the object. With an API that doesn't allow modification, either<br>
you get a complete object, or you get no object.<br>
<br></blockquote><div><br></div><div>I hope I've got a specific point of our disagreement. </div><div><br></div><div>There are 2 variants of using OpenSSL.</div><div>1. Algorithm-agnostic. We can deal with most of the algorithms in a more or less similar way.</div><div>That was the way we dealt with various algorithms in libcrypto since 1.0 version.</div><div><br></div><div>2. Algorithm-specific. The API user should take into account which algorithms are</div><div>supported by their application and provide some specific processing.</div><div><br></div><div>These are two different approaches.</div><div><br></div><div>The OpenSSL itself should be more or less algorithm-agnostic.</div><div>The providers (as engines before) are definitely algorithm-specific.</div><div>The openssl command line utilities in fact provide flexibility leaving the burden of parameters setup to the end-user.</div><div><br></div><div>So if you pass some RSA-specific parameters to an EC key and vice versa, you should get an (ignorable) error.</div></div><div>But when you have set the parameters and try to do a particular operation, you either have a consistent set of parameters </div><div>(and get OK checking it) or not (and get an unrecoverable failure).</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>