On Wed, Oct 7, 2020 at 8:29 PM Kurt Roeckx <k...@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
