OTC Vote proposal: Relax the implementation in regards to required public component

[Tomas Mraz]

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