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. Kurt