Re: OTC VOTE: Keeping API compatibility with missing public key

2021-01-12 Thread Tomas Mraz
This vote is now closed. accepted: yes (for: 8, against: 0, abstained: 0, not voted: 3) Tomas 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 > public > component for EVP_PKEY has

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-08 Thread Kurt Roeckx
On Fri, Dec 04, 2020 at 01:45:07PM +0100, Tomas Mraz wrote: > 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

RE: OTC VOTE: Keeping API compatibility with missing public key

2020-12-07 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of Matt > Caswell > Sent: Monday, December 7, 2020 10:46 AM > To: openssl-project@openssl.org > Subject: Re: OTC VOTE: Keeping API compatibility with missing public key > > +1 > > On 04/12/2020 12:

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-07 Thread Matt Caswell
+1 On 04/12/2020 12:45, Tomas Mraz 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

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-07 Thread Richard Levitte
+1 On Fri, 04 Dec 2020 13:45:07 +0100, Tomas Mraz 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

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-04 Thread SHANE LONTIS
+1 > On 4 Dec 2020, at 10:45 pm, Tomas Mraz 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

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-04 Thread 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

Re: OTC VOTE: Keeping API compatibility with missing public key

2020-12-04 Thread Dr Paul Dale
+1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 4 Dec 2020, at 10:45 pm, Tomas Mraz wrote: > > Vote background > --- > > The vote on relaxing the conceptual model in regards to required public >

OTC VOTE: Keeping API compatibility with missing public key

2020-12-04 Thread Tomas Mraz
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