I'm not sure you have majority and minority the right way around. My guess would be that the majority of OpenSSL users are libcrypto. consumers rather than SSL/TLS consumers.
A point several of us have been trying to get through for some time.
Peter
-----"openssl-dev" <openssl-dev-boun...@openssl.org> wrote: -----
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-us...@openssl.org" <openssl-us...@openssl.org>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
While I am all for simplicity, I also think that removing functionality is a “bad idea”.
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-us...@openssl.org" <openssl-us...@openssl.org>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
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 following the 80/20 rule (sometimes the 95/5 rule):
Those “who care” (the minority) about the ciphers can re-enable them and rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity.
--
On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<openssl-dev-boun...@openssl.org on behalf of bka...@akamai.com> 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, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.
That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.
There seems to be a logical leap between these two paragraphs. Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?
Because it used to be the only real game in town, and *people learned to
rely upon it*.Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?
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.While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.
The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.
Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:
From the main web page of project:
The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
