<div dir="ltr">I vote "for" :) Let me know what should I do if openssl will decide to move forward<div><br></div><div>Regards,</div><div>Alex.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 1:35 PM, Blumenthal, Uri - 0553 - MITLL <span dir="ltr"><<a href="mailto:uri@ll.mit.edu" target="_blank">uri@ll.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/20/16, 16:25 , "openssl-dev on behalf of Salz, Rich"<br>
<<a href="mailto:openssl-dev-bounces@openssl.org">openssl-dev-bounces@openssl.org</a> on behalf of <a href="mailto:rsalz@akamai.com">rsalz@akamai.com</a>> wrote:<br>
<br>
>> The fact that these mechanisms are half-done means to be that it’s a<br>
>>bug in need of fixing.<br>
><br>
>I doubt that anyone else on the team will find this argument compelling.<br>
<br>
I don’t know. “pkeyutl -engine pkcs11 -keyform engine -derive -inkey<br>
id_03" does not work the way it’s supposed to. To me it usually means a<br>
bug. Another supporting reason - no interface or parameters/arguments<br>
would change, only the internal behavior would be adjusted, resulting in<br>
actually succeeding with a crypto operation rather than returning an error.<br>
<br>
But regardless, I hope the team would consider the complexity (or<br>
simplicity :) of the proposed change and the benefits from it. After all,<br>
we’re not lawyers, and (hopefully :) we all want to make/keep this tool as<br>
useful as possible to as many users as feasible (as far as we can :). So<br>
since this change doesn’t require moving heaven and earth (AFAICT),<br>
perhaps the team would consider it.<br>
<br>_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
<br></blockquote></div><br></div>