There were no comments so far, so unless there is any comment today, I'll call a vote on the proposed vote text tomorrow.
On Tue, 2020-12-01 at 12:20 +0100, Tomas Mraz wrote: > The vote on relaxing the conceptual model in regards to required > public > component for EVP_PKEY has passed with the following text: > > 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). > > However since then the issue 13506 [1] was reported. > > During OTC meeting we concluded that we might need to relax also > other > public key algorithm implementations to allow private keys without > public component. > > So here is my vote proposal in regards to this: > > ------ proposed vote text ------ > For 3.0 EVP_PKEY keys all algorithm implementations that were usable > with 1.1.1 EVP_PKEY API or low level APIs without public component > must > stay usable. > -------------------------------- > > This effectively overrules the '* all implementations apart from EC > require the public component to be present' part of the previous > vote. > > I did not explicitly mention in the vote proposal that we do not want > to generate the public component on fly (or even on 'fromdata' call) > as > I do not think we were doing that in 1.1.1 so implementation of this > vote should not require that either. > > > [1] https://github.com/openssl/openssl/issues/13506 > -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
