<div dir="ltr">-1<div><br></div><div>As I said in the OTC meeting, I agree we should change the conceptual model to not require a private key to be a super-set of a public key; however I do not think we should introduce key-type specific behaviour in this area - i.e. if it makes sense to change the model then it should apply equally to (for example) RSA keys as to EC keys. </div><div><br></div><div>Tim.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 2:20 AM Dr. Matthias St. Pierre <<a href="mailto:Matthias.St.Pierre@ncp-e.com">Matthias.St.Pierre@ncp-e.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">0<br>
<br>
> -----Original Message-----<br>
> From: openssl-project <<a href="mailto:openssl-project-bounces@openssl.org" target="_blank">openssl-project-bounces@openssl.org</a>> On Behalf Of Matt Caswell<br>
> Sent: Tuesday, November 3, 2020 1:11 PM<br>
> To: <a href="mailto:openssl-project@openssl.org" target="_blank">openssl-project@openssl.org</a><br>
> Subject: OTC VOTE: EVP_PKEY private/public key components<br>
> <br>
> Background to the vote:<br>
> <br>
> The OTC meeting today discussed the problems raised by issue #12612. In<br>
> summary the problem is that there has been a long standing, widespread<br>
> and documented assumption that an EVP_PKEY with a private key will<br>
> always also have the public key component.<br>
> <br>
> In spite of this it turns out that in the EC implementation in 1.1.1 it<br>
> was perfectly possible to create an EVP_PKEY with only a private key and<br>
> no public key - and it was also possible to use such an EVP_PKEY in a<br>
> signing operation.<br>
> <br>
> The current 3.0 code in master introduced an explicit check (in line<br>
> with the long held assumption) that the public key was present and<br>
> rejected keys where this was not the case. This caused a backwards<br>
> compatibility break for some users (as discussed at length in #12612).<br>
> <br>
> The OTC discussed a proposal that we should relax our conceptual model<br>
> in this regards and conceptually allow EVP_PKEYs to exist that only have<br>
> the private component without the public component - although individual<br>
> algorithm implementations may still require both.<br>
> <br>
> It is possible to automatically generate the public component from the<br>
> private for many algorithms, although this may come at a performance and<br>
> (potentially) a security cost.<br>
> <br>
> The proposal discussed was that while relaxing the conceptual model,<br>
> most of the existing implementations would still require both. The EC<br>
> implementation would be relaxed however. This essentially gives largely<br>
> compatible behaviour between 1.1.1 and 3.0.<br>
> <br>
> The vote text is as follows:<br>
> <br>
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:<br>
> * relax the conceptual model to allow private keys to exist without public<br>
>   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<br>
>   contain public keys and<br>
> * our decoders unconditionally generate the public key (where possible).<br>
> <br>
> Proposed by Matt Caswell<br>
> Public: yes<br>
> opened: 2020-11-03<br>
> closed: 2020-mm-dd<br>
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)<br>
> <br>
>   Matt       [+1]<br>
>   Mark       [  ]<br>
>   Pauli      [+1]<br>
>   Viktor     [  ]<br>
>   Tim        [  ]<br>
>   Richard    [+1]<br>
>   Shane      [+1]<br>
>   Tomas      [+1]<br>
>   Kurt       [  ]<br>
>   Matthias   [  ]<br>
>   Nicola     [-1]<br>
<br>
</blockquote></div>