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]
