Re: OTC VOTE: Keeping API compatibility with missing public key
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 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 > > -- 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.]
Re: OTC VOTE: Keeping API compatibility with missing public key
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 implementations apart from EC require the public component to > be present; >part of the vote closed on 2020-11-17. > +1 Kurt
RE: OTC VOTE: Keeping API compatibility with missing public key
+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: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 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 > > > > smime.p7s Description: S/MIME cryptographic signature
Re: OTC VOTE: Keeping API compatibility with missing public key
+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 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 > >
Re: OTC VOTE: Keeping API compatibility with missing public key
+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 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 > > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/
Re: OTC VOTE: Keeping API compatibility with missing public key
+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 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 > >
Re: OTC VOTE: Keeping API compatibility with missing public key
+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 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 > > >
Re: OTC VOTE: Keeping API compatibility with missing public key
+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 > 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 > >
OTC VOTE: Keeping API compatibility with missing public key
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
