OTC VOTE: EVP_PKEY private/public key components

[Matt Caswell]

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]