OTC VOTE: EVP_PKEY private/public key components

[Richard Levitte]

On Sun, 15 Nov 2020 22:36:54 +0100,
Kurt Roeckx wrote:
> 
> On Tue, Nov 03, 2020 at 12:11:27PM +0000, Matt Caswell wrote:
> > 
> > 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)
> 
> So I think being compatible with what 1.1.1 does is important.
> And what the text does is try to make rules for what 1.1.1 does,
> but as far as I understand it, it's not really describing what
> 1.1.1 does.
> 
> I think we should just fix the regressions. For fixing the
> regressions we don't need a vote.

The vote includes exactly the items needed to fix the regression.  In
reality, this is already mostly fixed, because all our new decoders
will reconstruct the public key exactly the same way the old backends
did, because they all call the exact same d2i_{TYPE}PrivateKey()
internally, which do the actual work.

The only actual work remaining to fix the regression is to relax the
EC keymgmt import function to accept receiving a private key without
the public key.  It doesn't actually need to regenerate a public key
either.  That will allow a construct similar to the one that was
reported in #12612.

In practical terms, that doesn't sound like very hard work.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/