Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Benjamin Kaduk
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote text. > There will be a subsequent vote on the "beta readiness checklist" which > is a separate

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread SHANE LONTIS
I assume you are just talking about the ec key? If the public key is not present then that could be seen as an error for operations that require the public key. Shane > On 7 Oct 2020, at 9:54 pm, Dr Paul Dale wrote: > > Would it be feasible to change code that does ->pub_key to call a

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Richard Levitte
On Wed, 07 Oct 2020 21:25:57 +0200, Nicola Tuveri wrote: > > On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > > with a private key should have a public key. I was incorrect. > > Sure, my example was not about

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
On Wed, 7 Oct 2020 at 20:45, Richard Levitte wrote: > > I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY > with a private key should have a public key. I was incorrect. Sure, my example was not about pointing fingers! It's just to give recent data points on how the

Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Kurt Roeckx
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > The following items are required prerequisites for the first beta release: [...] > * Address 3.0beta1 milestones. So we now have a list here, with the last item pointing to a different list. I suggest that we only have 1 list, and

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
On Wed, 7 Oct 2020 at 20:17, Richard Levitte wrote: > > There's no reason for the EVP layer to check for the presence or the > absence or the public key, for one very simple reason: it doesn't have > access to the backend key structure and therefore has no possibility > to make any such checks.

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Richard Levitte
I'm as culpable as anyone re pushing the "convention" that an EVP_PKEY with a private key should have a public key. I was incorrect. Regarding avoiding NULL checks, that's actually a separate story, evem though it overlaps conveniently. There was the idea, for a while, that we should avoid NULL

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Dmitry Belyavsky
On Wed, Oct 7, 2020 at 8:29 PM Kurt Roeckx wrote: > On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote: > > Issue #12612 exposes a problem with how we handle keys that contain > > private components but not public components. > > > > There is a widespread assumption in the code that

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Kurt Roeckx
On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote: > Issue #12612 exposes a problem with how we handle keys that contain > private components but not public components. > > There is a widespread assumption in the code that keys with private > components must have public components.

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
Re; "enforcement" My impression is that there is no such enforcement, because the project has (had?) a stance on "avoid NULL checks" and "consider things that break our documented assumptions as programmer errors". The natural result of these two principles may very well be the deliberate reason

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Richard Levitte
There's no reason for the EVP layer to check for the presence or the absence or the public key, for one very simple reason: it doesn't have access to the backend key structure and therefore has no possibility to make any such checks. Such checks should be made in the backend. That part of your

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Richard Levitte
As far as I can tell, the existing "enforcement" is in the algorithm implementations. I had a look through the following files in OpenSSL 1.1.1: crypto/rsa/rsa_ossl.c crypto/dsa/dsa_ossl.c crypto/dh/dh_key.c crypto/ec/ecdsa_ossl.c crypto/ec/ecdh_ossl.c I first had a look at the key computing

Re: Alpha releases

2020-10-07 Thread Matt Caswell
This vote has now started. I'll post here with the results once its complete. Matt On 06/10/2020 13:12, Matt Caswell wrote: > The OTC meeting today discussed making further alpha releases while we > continue to work towards getting to beta 1. It was proposed that we > release alpha 7 on Thursday

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Matt Caswell
I would also be ok with this vote text formulation. Lets see what others say. Matt On 07/10/2020 16:34, Nicola Tuveri wrote: > I believe the current formulation is slightly concealing part of the problem. > > The way I see it, the intention if the vote passes is to do more than stated: > 1.

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Nicola Tuveri
I believe the current formulation is slightly concealing part of the problem. The way I see it, the intention if the vote passes is to do more than stated: 1. change the long-documented assumption 2. fix "regressions" in 3.0 limited to things that worked in a certain way in 1.1.1 (and maybe

Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Nicola Tuveri
I support the edit proposed by Tomas. First comment that I have is that I'd prefer the first-level items to be actually numbered, as done in the drafts: we might put a disclaimer that the numbers are not indicative of priority and just meant to be used to address (equally important) tasks by

[VOTE PROPOSAL] Weekly OTC meeting until 3.0 beta1 is released

2020-10-07 Thread Nicola Tuveri
Background -- Since the two virtual face-to-face OTC meetings of last week, and again in the two OTC meetings this week, we repeatedly discussed replacing the weekly "developer meetings" with official OTC meetings. The "developer meetings" have so far seen frequent participation from a

Re: Vote proposal: Technical items still to be done

2020-10-07 Thread Tomas Mraz
On Wed, 2020-10-07 at 12:35 +0100, Matt Caswell wrote: > I had an action from the OTC meeting today to raise a vote on the OTC > list of technical items still to be done. Here is my proposed vote > text. > There will be a subsequent vote on the "beta readiness checklist" > which > is a separate

Re: Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Dr Paul Dale
Would it be feasible to change code that does ->pub_key to call a function that null checks the field and generates the public key if it is absent? Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 7 Oct 2020, at 9:29

Vote proposal: Technical items still to be done

2020-10-07 Thread Matt Caswell
I had an action from the OTC meeting today to raise a vote on the OTC list of technical items still to be done. Here is my proposed vote text. There will be a subsequent vote on the "beta readiness checklist" which is a separate list. Feedback please on the proposed vote text below. The

Vote proposal: Private keys can exist independently of public keys

2020-10-07 Thread Matt Caswell
Issue #12612 exposes a problem with how we handle keys that contain private components but not public components. There is a widespread assumption in the code that keys with private components must have public components. There is text in our public documentation that states this (and that text

Vote proposal: Accept the Fully Pluggable TLSv1.3 KEM into 3.0

2020-10-07 Thread Matt Caswell
I'm proposing the following vote text: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Feedback please on the vote proposal before I start the vote. Matt