Vote proposal: Private keys can exist independently of public keys

[Dmitry Belyavsky]

On Wed, Oct 7, 2020 at 8:29 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote:
> > Issue #12612 exposes a problem with how we handle keys that contain
> > private components but not public components.
> >
> > There is a widespread assumption in the code that keys with private
> > components must have public components. There is text in our public
> > documentation that states this (and that text dates back to 2006).
> >
> > OTOH, the code has not always enforced this. Issue #12612 describes a
> > scenario where this has not historically been enforced, and it now is in
> > the current 3.0 code causing a regression.
> >
> > There are differences of opinion on how this should be handled. Some
> > have the opinion that we should change the model so that we explicitly
> > allow private keys to exists without the public components. Others feel
> > that we should continue with the old model.
>
> It seems to me that we have various ways forward:
> 1) Enforce that a private key requires the public key
> 2) Don't enforce it, just give an error when you try to use the
>    public key and it's not available.
> 3) Make it work for the same cases that worked with 1.1.1
> 4) Generate the public key from the private key
> 5) Have some kind of transition where we do 2), 3)
>    or 4) in 3.0, but will move to 1) at some later point.
> 6) do 2), but enforce it in the fips provider
>
> I don't know if we do any any kind of consistency checks on the key
> now when it's loaded. But 2) would then imply that the check is
> skipped instead of returning an error.
>

4) maybe not applicable when a private key is on the hardware token.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20201007/f4c8fb59/attachment.html>