OTC VOTE: EVP_PKEY private/public key components

[Matt Caswell]

This vote is now closed.

Viktor's vote was a little unclear but I interpreted it as a -1 in
recording the votes.

accepted:  yes  (for: 5, against: 4, abstained: 1, not voted: 1)


Matt


On 03/11/2020 12:11, Matt Caswell wrote:
> Background to the vote:
> 
> The OTC meeting today discussed the problems raised by issue #12612. In
> summary the problem is that there has been a long standing, widespread
> and documented assumption that an EVP_PKEY with a private key will
> always also have the public key component.
> 
> In spite of this it turns out that in the EC implementation in 1.1.1 it
> was perfectly possible to create an EVP_PKEY with only a private key and
> no public key - and it was also possible to use such an EVP_PKEY in a
> signing operation.
> 
> The current 3.0 code in master introduced an explicit check (in line
> with the long held assumption) that the public key was present and
> rejected keys where this was not the case. This caused a backwards
> compatibility break for some users (as discussed at length in #12612).
> 
> The OTC discussed a proposal that we should relax our conceptual model
> in this regards and conceptually allow EVP_PKEYs to exist that only have
> the private component without the public component - although individual
> algorithm implementations may still require both.
> 
> It is possible to automatically generate the public component from the
> private for many algorithms, although this may come at a performance and
> (potentially) a security cost.
> 
> The proposal discussed was that while relaxing the conceptual model,
> most of the existing implementations would still require both. The EC
> implementation would be relaxed however. This essentially gives largely
> compatible behaviour between 1.1.1 and 3.0.
> 
> The vote text is as follows:
> 
> topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution:
> * relax the conceptual model to allow private keys to exist without public
>   components;
> * all implementations apart from EC require the public component to be
> present;
> * relax implementation for EC key management to allow private keys that
> do not
>   contain public keys and
> * our decoders unconditionally generate the public key (where possible).
> 
> Proposed by Matt Caswell
> Public: yes
> opened: 2020-11-03
> closed: 2020-mm-dd
> accepted:  yes/no  (for: X, against: Y, abstained: Z, not voted: T)
> 
>   Matt       [+1]
>   Mark       [  ]
>   Pauli      [+1]
>   Viktor     [  ]
>   Tim        [  ]
>   Richard    [+1]
>   Shane      [+1]
>   Tomas      [+1]
>   Kurt       [  ]
>   Matthias   [  ]
>   Nicola     [-1]
>