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
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
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
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
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
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.
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
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; "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
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
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
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
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.
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
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
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
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
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
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
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
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
21 matches
Mail list logo