On Mon, Jul 15, 2019 at 02:19:22PM +0100, Matt Caswell wrote:
>
>
> On 15/07/2019 13:58, Tomas Mraz wrote:
>
> >
> > I understand that for the current digest algos implemented in the
> > legacy provider the problem might not be as pressing as these
> > algorithms are not widely used however
My view point (which has been stated elsewhere) is that OpenSSL-3.0 is
about internal restructuring to allow for the various things noted in the
design documents.
It is not about changing the feature set (in a feature reduction sense).
In future releases we will make the mixture of providers
> If DSA is almost never used, why enable it by default?
I am amused/bemused that, after years of saying we do not know what people are
doing with OpenSSL, it now is now becoming common practice to blithely assert
"this is not used" when it fits the personal viewpoint of some folks.
On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote:
> On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
>
> > >>DSA
> > >
> > > What is the cryptographic weakness of DSA that you are avoiding?
> >
> > It's a good question. I don't recall the
On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote:
> >>DSA
> >
> > What is the cryptographic weakness of DSA that you are avoiding?
>
> It's a good question. I don't recall the specific reason why that was
> added to
> the list. Perhaps others can comment.
On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote:
> Wouldn't it be better to make the legacy provider opt-out? I.E. require
> explicit configuration or explicit API call to not load the legacy
> provider.
I'm not even sure why they need to move to a different provider
(at this time).
On Mon, 2019-07-15 at 16:25 +0200, Richard Levitte wrote:
> On Mon, 15 Jul 2019 16:15:01 +0200,
> Tomas Mraz wrote:
> > So saying this is "just recompliation and configuration change" is
> > at least somewhat oversimplified.
> >
> > But I am OK with that. I'm just saying it should be better
> >
>>DSA
>
> What is the cryptographic weakness of DSA that you are avoiding?
It's a good question. I don't recall the specific reason why that was added
to
the list. Perhaps others can comment.
The only weakness I know about is that if you re-use the nonce, the
On Mon, 15 Jul 2019 16:15:01 +0200,
Tomas Mraz wrote:
>
> So saying this is "just recompliation and configuration change" is
> at least somewhat oversimplified.
>
> But I am OK with that. I'm just saying it should be better advertised
> and that internally openssl should not use the "load legacy
On 15/07/2019 15:15, Tomas Mraz wrote:
> On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
>>
>> On 15/07/2019 14:43, Tomas Mraz wrote:
>>> On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
On 15/07/2019 13:58, Tomas Mraz wrote:
>
IMO this is a major release and
On Mon, 2019-07-15 at 14:48 +0100, Matt Caswell wrote:
>
> On 15/07/2019 14:43, Tomas Mraz wrote:
> > On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
> > > On 15/07/2019 13:58, Tomas Mraz wrote:
> > > >
> > > IMO this is a major release and therefore we should be taking the
> > >
>DSA
What is the cryptographic weakness of DSA that you are avoiding?
On 15/07/2019 14:46, Salz, Rich wrote:
>
>>DSA
>
> What is the cryptographic weakness of DSA that you are avoiding?
It's a good question. I don't recall the specific reason why that was added to
the list. Perhaps others can comment.
Matt
On 15/07/2019 14:43, Tomas Mraz wrote:
> On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
>>
>> On 15/07/2019 13:58, Tomas Mraz wrote:
>>> Hi everyone,
>>>
>>> if the Subject was already fully discussed and thought through then
>>> please disregard this but otherwise I'd like this e-mail
On Mon, 2019-07-15 at 14:19 +0100, Matt Caswell wrote:
>
> On 15/07/2019 13:58, Tomas Mraz wrote:
> > Hi everyone,
> >
> > if the Subject was already fully discussed and thought through then
> > please disregard this but otherwise I'd like this e-mail to be a
> > starting point for discussion.
>
On 15/07/2019 13:58, Tomas Mraz wrote:
> Hi everyone,
>
> if the Subject was already fully discussed and thought through then
> please disregard this but otherwise I'd like this e-mail to be a
> starting point for discussion.
>
> I suppose the current intention is to make the legacy provider
16 matches
Mail list logo
