OTC VOTE: EVP_PKEY private/public key components

[Tim Hudson]

-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.Pierre at ncp-e.com> wrote:

> 0
>
> > -----Original Message-----
> > From: openssl-project <openssl-project-bounces at openssl.org> On Behalf
> Of Matt Caswell
> > Sent: Tuesday, November 3, 2020 1:11 PM
> > To: openssl-project at 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]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20201110/5de61e3b/attachment.html>