<div dir="ltr">+1<br><div><br></div><div>Note I support also changing all key types to be able to operate without the public component (where that is possible) which goes beyond what this vote covers (as previously noted).</div><div>Having a documented conceptual model that is at odds with the code isn't a good thing and in particular this choice of conceptual model isn't one that is appropriate in my view.<br></div><div><br></div><div>Tim.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020 at 10:45 PM Tomas Mraz <<a href="mailto:tmraz@redhat.com">tmraz@redhat.com</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">Vote background<br>
---------------<br>
<br>
The vote on relaxing the conceptual model in regards to required public<br>
component for EVP_PKEY has passed with the following text:<br>
<br>
For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:<br>
* relax the conceptual model to allow private keys to exist without<br>
public components;<br>
* all implementations apart from EC require the public component to be<br>
present;<br>
* relax implementation for EC key management to allow private keys that<br>
do not contain public keys and<br>
* our decoders unconditionally generate the public key (where<br>
possible).<br>
<br>
However since then the issue 13506 [1] was reported.<br>
<br>
During OTC meeting we concluded that we might need to relax also other<br>
public key algorithm implementations to allow private keys without<br>
public component.<br>
<br>
Vote<br>
----<br>
<br>
topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable<br>
       with 1.1.1 EVP_PKEY API or low level APIs without public component must<br>
       stay usable.<br>
<br>
       This overrules the<br>
         * all implementations apart from EC require the public component to be present;<br>
       part of the vote closed on 2020-11-17.<br>
<br>
Proposed by Tomas Mraz<br>
Public: yes<br>
opened: 2020-12-04<br>
<br>
Tomas Mraz<br>
<br>
<br>
</blockquote></div>