[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Benjamin Kaduk]

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"
> <openssl-dev-bounces at openssl.org on behalf of bkaduk at 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.

I guess I'm just having a hard time wrapping my head around why, upon
hearing that the volunteer-run project is giving years' advance notice
that certain features will be removed, the response is insistence that
everything must remain supported forever, instead of using the advance
notice to investigate alternatives.  Volunteers should be allowed to
ease up when they need to, after all.


>> 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.

Surely the requirements for a general-purpose crypto library must change
over time!  In 1995, such a library did not (could not!) include AES
support, whereas even by 2005 it would have been pretty essential to
have.  As the state of the art advances, the library must adapt to
match, and removing components that are no longer widespread or
essential seems a natural part of that adaptation.  The requirements are
not an append-only list.

>> 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:

Well, I see this thread as notice that the implicit support should no
longer be taken for granted, with plenty of advance notice.

> 	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* .
>
>


That text reads as if it was originally drafted 10+ years ago, when
"full-featured" meant "we support both encryption and decryption" as
well as "we provide both export-grade and strong crypto".  I'm sure we
could put some updated text in if that would help clarify what exactly
the goals of the project are.  And, as Richard notes, general-purpose
does not mean "usable for every possible specific use case under the
sun", it means "usable for most common things", which to me does not
include CAdES-A and the like.

-Ben