-1 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.
Tim. On Tue, Nov 10, 2020 at 2:20 AM Dr. Matthias St. Pierre < matthias.st.pie...@ncp-e.com> wrote: > 0 > > > -----Original Message----- > > From: openssl-project <openssl-project-boun...@openssl.org> On Behalf > Of Matt Caswell > > Sent: Tuesday, November 3, 2020 1:11 PM > > To: openssl-project@openssl.org > > Subject: OTC VOTE: EVP_PKEY private/public key components > > > > 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] > >
