+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 <tm...@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 > > >
