OTC VOTE: Keeping API compatibility with missing public key

[Tim Hudson]

+1

Note I support also changing all key types to be able to operate without
the public component (where that is possible) which goes beyond what this
vote covers (as previously noted).
Having a documented conceptual model that is at odds with the code isn't a
good thing and in particular this choice of conceptual model isn't one that
is appropriate in my view.

Tim.


On Fri, Dec 4, 2020 at 10:45 PM Tomas Mraz <tmraz at redhat.com> wrote:

> Vote background
> ---------------
>
> 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.
>
> Vote
> ----
>
> topic: 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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20201205/a037c0a5/attachment-0001.html>