Re: VOTE: Technical Items still to be done

2020-10-08 Thread SHANE LONTIS
+1 > On 9 Oct 2020, at 12:47 am, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with >the functionality available using lower-level APIs. > - Anything that

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread SHANE LONTIS
-1 > On 9 Oct 2020, at 7:40 am, Dr Paul Dale wrote: > > +1 > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 9 Oct 2020, at 12:27 am, Matt Caswell > > wrote: >> >> topic:

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Dr Paul Dale
[to the project list this time] +1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:47 am, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release:

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Dr Paul Dale
+1 Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 9 Oct 2020, at 12:27 am, Matt Caswell wrote: > > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release >

RE: VOTE: Technical Items still to be done

2020-10-08 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of > Tomas Mraz > Sent: Thursday, October 8, 2020 6:21 PM > To: Matt Caswell ; openssl-project@openssl.org > Subject: Re: VOTE: Technical Items still to be done > > +1 > > On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote:

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Kurt Roeckx
On Thu, Oct 08, 2020 at 03:27:18PM +0100, Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release +1 Kurt

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Tomas Mraz
+1 On Thu, 2020-10-08 at 15:47 +0100, Matt Caswell wrote: > topic: The following items are required prerequisites for the first > beta > release: > 1) EVP is the recommended API, it must be feature-complete compared > with > the functionality available using lower-level APIs. >- Anything

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Tomas Mraz
+1 On Thu, 2020-10-08 at 15:27 +0100, Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality > as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X,

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Tim Hudson
+1 Tim. On Fri, Oct 9, 2020 at 12:47 AM Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >-

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Tim Hudson
+1 Tim On Fri, Oct 9, 2020 at 12:27 AM Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X,

RE: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Dr. Matthias St. Pierre
+1 > -Original Message- > From: openssl-project On Behalf Of Matt > Caswell > Sent: Thursday, October 8, 2020 4:27 PM > To: openssl-project@openssl.org > Subject: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality > > topic: We should accept the Fully Pluggable TLSv1.3 KEM

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Matt Caswell
Note that Nicola pointed out a formatting error in the vote text. The last sub-bullet under point 2 is actually 2 different sub-bullets that got merged together, i.e. - Compile and link 1.1.1 command line app against the master headers and library. Run 1.1.1 app test cases against the

Re: VOTE: Technical Items still to be done

2020-10-08 Thread Nicola Tuveri
+1 On Thu, 8 Oct 2020 at 17:47, Matt Caswell wrote: > > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >- Anything that

VOTE: Technical Items still to be done

2020-10-08 Thread Matt Caswell
topic: The following items are required prerequisites for the first beta release: 1) EVP is the recommended API, it must be feature-complete compared with the functionality available using lower-level APIs. - Anything that isn’t available must be put to an OTC vote to exclude. - The

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Matt Caswell
Thanks for the feedback on this thread. There was some feedback specifically on the vote text. I've made the amendment suggested by Tomas, and numbered the items as suggested by Nicola. I did not convert to markdown. The other discussions on this thread I think are useful things to think about

Re: VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Nicola Tuveri
+1 On Thu, Oct 8, 2020, 17:27 Matt Caswell wrote: > topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as > shown in PR #13018 into the 3.0 release > Proposed by Matt Caswell > Public: yes > opened: 2020-10-08 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y,

VOTE: Accept the Fully Pluggable TLSv1.3 KEM functionality

2020-10-08 Thread Matt Caswell
topic: We should accept the Fully Pluggable TLSv1.3 KEM functionality as shown in PR #13018 into the 3.0 release Proposed by Matt Caswell Public: yes opened: 2020-10-08 closed: 2020-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [+1] Mark [ ]

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

2020-10-08 Thread Nicola Tuveri
An update to keep this thread in sync: we moved the discussion between me and Richard partially offline and partially on (the issue that triggered this vote proposal). Part of the discussion was on our positions and rationales regarding the actual

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Salz, Rich
>Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it stable for many years to come. Any bugs in the API design for providers will have to live with us at least until the 4.0 release and so it

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Tomas Mraz
On Thu, 2020-10-08 at 09:47 +0100, Matt Caswell wrote: > > On 07/10/2020 19:07, Kurt Roeckx wrote: > > 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

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Matt Caswell
On 07/10/2020 19:07, Kurt Roeckx wrote: > 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 >

Re: Vote proposal: Technical items still to be done

2020-10-08 Thread Tomas Mraz
+1 to that. There is a reason why almost all the major projects switched over to doing time based releases instead of feature completeness based ones. Of course the 3.0 release is kind of special because we are defining a completely new API - the providers API - with the intention to have it