Someone picked up an old dead thread, but I'll make some brief
responses.
On 11/02/2016 20:49, Valerie Anne Fenwick wrote:
Hi Jakob -
On 11/22/15 08:17 PM, Jakob Bohm wrote:
On 20/11/2015 23:26, Short, Todd wrote:
While I am all for simplicity, I also think that removing
functionality is a “
Hi Jakob -
On 11/22/15 08:17 PM, Jakob Bohm wrote:
On 20/11/2015 23:26, Short, Todd wrote:
While I am all for simplicity, I also think that removing functionality is a
“bad idea”.
To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longe
To close off this thread: OpenSSL will not be making any changes.
The team voted on moving a set of algorithms to maintenance mode, and
removing the corresponding assembly implementations from libcrypto, but the
vote did not pass.
Emilia
On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson wrote:
> On
On 24/11/2015 4:09 AM, Jakob Bohm wrote:
> But they care very much if Cisco AnyConnect (or any other
> OpenSSL using program they may need) stops working or
> becomes insecure because the OpenSSL team is breaking
> stuff just because it is not needed in their own handful
> of example uses.
The Ope
On 23/11/2015 21:36, Karl Vogel wrote:
On Mon, 23 Nov 2015 05:17:33 +0100,
Jakob Bohm said:
J> You all seem to misunderstand the fundamental release engineering issues
J> involved.
Actually, we don't.
J> 1. Very shortly after you release OpenSSL 1.1.0, many distributions
J> and pointy ha
>> On Mon, 23 Nov 2015 05:17:33 +0100,
>> Jakob Bohm said:
J> You all seem to misunderstand the fundamental release engineering issues
J> involved.
Actually, we don't.
J> 1. Very shortly after you release OpenSSL 1.1.0, many distributions
J> and pointy haired managers will blindly switch to
But they care very much if Cisco AnyConnect (or any other
OpenSSL using program they may need) stops working or
becomes insecure because the OpenSSL team is breaking
stuff just because it is not needed in their own handful
of example uses.
And while ordinary people may not know or care, they will
I suspect that most “users” of OpenSSL are doing it indirectly through other
applications that use TLS (or crypto) functionality. Example: the Cisco
AnyConnect client is reportedly one of the most installed pieces of software
regardless of platform; it uses OpenSSL for TLS.
Taking those indirec
On 20/11/2015 23:26, Short, Todd wrote:
While I am all for simplicity, I also think that removing
functionality is a “bad idea”.
To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive
fixes.
2. Remove any assembly implementati
While I am all for simplicity, I also think that removing functionality is a
“bad idea”.
To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.
I suggest f
On Thu, Nov 19, 2015 at 11:01:26AM +0100, Tomas Mraz wrote:
> 3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the
> OpenSSL_add* functions so the users have to explicitly add these to use
> them automatically.
This does not work. Often the code that calls OpenSSL_add_all_alg
On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:
> > No, of course not. But after letting people depend on this “single
> > cryptographic library” for many years, telling them “too bad” isn’t very
> > nice.
>
> I guess I'm just having a hard time wrapping my head around why, upon
>
On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
> wrote:
>
>> On 11/18/2015 07:05 AM, Hubert Kario wrote:
>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>> support
>>> both relatively modern TLS
On 18 November 2015 at 17:57, Hubert Kario wrote:
> On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> > On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > > support both relatively modern TLS with user certificates,
On 11/18/2015 07:05 AM, Hubert Kario wrote:
> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support
> both relatively modern TLS with user certificates, preferably the newest
> cryptosystems and hashes as well as the oldest ones that were
> standardised and used.
>
> That mean
On Tue, Nov 17, 2015 at 11:24:17AM -0800, Jay Foster wrote:
> I can understand the desire to remove the assembly code options,
*ONLY* for deprecated legacy algorithms, as an alternative to the
proposal to remove the algorithm entirely.
> I recently updated a product I support (50MHz single core)
On 11/17/2015 9:56 AM, Jeffrey Walton wrote:
We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.
Zooko Wilcox O'Hearn recently gave a
On 11/17/2015 12:00 PM, Jeffrey Walton wrote:
>
>
> Also, if OpenSSL requires iOS 9 or above, then its setting policy for users.
In some sense, yes. But it has always done so -- OpenSSL only supports
certain platforms, and certain versions of certain platforms. There are
prerequisites to being a
On Tue, Nov 17, 2015 at 7:21 AM, Emilia Käsper wrote:
>
>
> On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote:
>>
>> > MD2 - (The argument that someone somewhere may want to keep verifying
>> > old
>> > MD2 signatures on self-signed certs doesn't seem like a compelling
>> > enough
>> > reaso
>> We can significantly reduce that liability by removing any assembler
>> optimisations. Also just because something is available doesn't mean it
>> has to be "default". We can have good defaults whilst keeping old crypto.
>
> Zooko Wilcox O'Hearn recently gave a talk at a software assurance
> con
With regard to the idea that one can simply make older algorithms
Somebody Else's Problem: is it *known* that another viable,
well-maintained product sees this as one of its roles? That would be
more reassuring, I think, than just hoping that some unknown group
will step into the gap.
--
Mark H
On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote:
> > MD2 - (The argument that someone somewhere may want to keep verifying old
> > MD2 signatures on self-signed certs doesn't seem like a compelling enough
> > reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> > ...
> Apple
>> I asked for mainstream use-cases for algorithms whose removal could
>> cause widespread pain. Some individual users, undoubtedly, will be hit
>> by this, and I acknowledge that they may not be reading this list. But I
>> wanted to know if I'd missed something endemic. I also asked elsewhere:
>>
> MD2 - (The argument that someone somewhere may want to keep verifying old
> MD2 signatures on self-signed certs doesn't seem like a compelling enough
> reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> ...
Apple still provides two Verisign certificates using
md2WithRSAEncryption
Ø If you are aware of a concrete use of MD2 or any of the other algorithms,
please let us know!
Also, note that we have an extended alpha and-beta test period, so we can add
things back if mistakes are made.
/r$
___
openssl-users m
On 16/11/15 15:51, Emilia Käsper wrote:
> Thanks all for your feedback!
>
> I asked for mainstream use-cases for algorithms whose removal could
> cause widespread pain. Some individual users, undoubtedly, will be hit
> by this, and I acknowledge that they may not be reading this list. But I
> wa
On 16 November 2015 at 19:05, Hubert Kario wrote:
> Example: CAdES V1.2.2 was published in late 2000, the first serious
> attacks on MD2 were not published until 2004. I think it is not
> unreasonable for CAdES-A documents to exist today which were originally
> signed with MD2 while it was still
One more time,
I know that someone, somewhere is probably using any given feature of
OpenSSL. I am looking to gather information about concrete, actively
maintained applications that may be using one of those algorithms, to build
a more complete picture.
If you are aware of a concrete use of MD2
On 16/11/2015 16:51, Emilia Käsper wrote:
Thanks all for your feedback!
I asked for mainstream use-cases for algorithms whose removal could
cause widespread pain. Some individual users, undoubtedly, will be hit
by this, and I acknowledge that they may not be reading this list. But
I wanted to
On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote:
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces
remain, so nothing changes at compile-time. Most co
Thanks all for your feedback!
I asked for mainstream use-cases for algorithms whose removal could cause
widespread pain. Some individual users, undoubtedly, will be hit by this,
and I acknowledge that they may not be reading this list. But I wanted to
know if I'd missed something endemic. I also a
On Fri, Nov 13, 2015, Benjamin Kaduk wrote:
>
> As another thread calls to mind, PKCS#12 could potentially just use
> triple-DES. (BTW, the CMS tests fail when openssl is configured with
> no-rc2, due to this; I have a WIP patch sitting around.)
>
The issue is that some cuurent software (inclu
32 matches
Mail list logo