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]
smime.p7s
Description: S/MIME cryptographic signature
