OTC VOTE: Keeping API compatibility with missing public key
tm at t8m.info
Tue Jan 12 13:35:36 UTC 2021
This vote is now closed.
accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3)
On Fri, 2020-12-04 at 13:45 +0100, Tomas Mraz wrote:
> Vote background
> The vote on relaxing the conceptual model in regards to required
> 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
> * relax implementation for EC key management to allow private keys
> do not contain public keys and
> * our decoders unconditionally generate the public key (where
> However since then the issue 13506  was reported.
> During OTC meeting we concluded that we might need to relax also
> public key algorithm implementations to allow private keys without
> public component.
> topic: For 3.0 EVP_PKEY keys all algorithm implementations that were
> with 1.1.1 EVP_PKEY API or low level APIs without public
> component must
> stay usable.
> This overrules the
> * all implementations apart from EC require the public
> component to be present;
> part of the vote closed on 2020-11-17.
> Proposed by Tomas Mraz
> Public: yes
> opened: 2020-12-04
> Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
[You'll know whether the road is wrong if you carefully listen to your
More information about the openssl-project