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