Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

classic Classic list List threaded Threaded
70 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
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_algorithms()
is not the code that knows which algorithms will be used (think
scripting languages).  Having a single call that adds all the
algorithms or just the non-legacy algorithms can work, hance Matt's
suggestion of a #define that selects between two implementations,
and requires linking with the legacy library.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Viktor Dukhovni
In reply to this post by Richard Moore
On Thu, Nov 19, 2015 at 05:07:38PM +0000, Richard Moore wrote:

>​Yes, but a several people (including me) disagree with you. And one of the
> options that has been suggested is to keep the code but have it disabled by
> default.

Note, we're talking about "disabled" as opposed to "not compiled".
Stuff that's not compiled by default tends to not get tested, and
breaks silently when it is needed.  That's not terribly useful.
(Yes, I know about RC5, which is not compiled by default for IPR
reasons.  Distributions that have never shipped IDEA compiled-in
can disable it downstream).

This means that absent explicit compile-time directives, the EVP
interface will not expose the legacy algorithms.  Middleware that
provides general-purpose crypto interfaces on top of OpenSSL to
other software will need to enable the legacy algorithms.

I am not convinced that making people jump through the extra hoops
would be worth the effort on our part and theirs.  Whom would we
be helping?

The simplest thing to do is to make legacy libcrypto code maximally
maintainable, and if removing assembly support does that, than we
do that.  Beyond that, do nothing.  What algorithms people use on
their own data is their choice and risk decision not ours.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Richard Moore


On 19 November 2015 at 19:28, Viktor Dukhovni <[hidden email]> wrote:
On Thu, Nov 19, 2015 at 05:07:38PM +0000, Richard Moore wrote:

>​Yes, but a several people (including me) disagree with you. And one of the
> options that has been suggested is to keep the code but have it disabled by
> default.

Note, we're talking about "disabled" as opposed to "not compiled".
Stuff that's not compiled by default tends to not get tested, and
breaks silently when it is needed.  That's not terribly useful.

​I haven't seen anything that suggests that actually. ​In fact my assumption is the opposite of yours.

 
(Yes, I know about RC5, which is not compiled by default for IPR
reasons.  Distributions that have never shipped IDEA compiled-in
can disable it downstream).

This means that absent explicit compile-time directives, the EVP
interface will not expose the legacy algorithms.  Middleware that
provides general-purpose crypto interfaces on top of OpenSSL to
other software will need to enable the legacy algorithms.

I am not convinced that making people jump through the extra hoops
would be worth the effort on our part and theirs.  Whom would we
be helping?

​Again, since the old middleware would need to change​ either way, I don't see why the baggage should be brought along.
 
The simplest thing to do is to make legacy libcrypto code maximally
maintainable, and if removing assembly support does that, than we
do that.  Beyond that, do nothing.  What algorithms people use on
their own data is their choice and risk decision not ours.


​The simplest thing depends on your point of view. The simplest thing if you only care about openssl is to remove it, however the simplest thing if you only care about an end product that depends on some weird feature is to change nothing. You can't just make an absolute statement, as usual there are trade-offs and work for different people. ​

​Cheers

Rich.​


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

John Denker-2
In reply to this post by Viktor Dukhovni
On 11/19/2015 12:28 PM, Viktor Dukhovni wrote:

> What algorithms people use on
> their own data is their choice and risk decision not ours.

I heartily agree with the sentiment.  A low- or mid-level library
is not the right place to be making and enshrining policy decisions.

We can take yet another step in the same direction.  There are
several job descriptions:
 1) Writing the library code.
 2) Compiling the library code.  This might be done by some
  distributor.  This is where final decisions about #define
  options are made.
 3) Linking against the compiled library and running the application.
 4) Running the counterpart application on the other end of the
  communication line.

You would think that the guy in job #3 would be in the best position
to make policy decisions ... but sometimes even he doesn't get to
make that decision, because of #4.  It takes two to tango.  It seems
very likely that some people are using openssl to communicate with
legacy devices that use "outdated" crypto primitives.

-- There are /some/ cases where it is better to communicate in the
 clear than to encrypt badly.
-- There are /some/ cases where it is better to not communicate at
 all than to encrypt badly.
++ Sometimes not!  There is no such thing as absolute security, and
 sometimes an algorithm that would not withstand an "advanced persistent"
 attack might be good enough for some quick-and-dirty tactical purpose.

To say the same thing another way:  I am quite sure that many
/persons/ on this list, if assigned to job #3 and/or job #4, could
make wise decisions at those levels, based on information available
at those levels.  Indeed there are some persons on this list who
wear all four hats simultaneously.

So the question is, are there any representatives of category #3
who are willing to speak on behalf of /everybody/ in that category?
If not, it seems this thread is asking a question that cannot be
answered.

To say the same thing yet another way, fundamentally we have a
communication problem, or rather two separate communication
problems:
 A) The experts on this list know that certain crypto primitives
  are "broken or outdated".  This needs to be communicated to the
  people who are actually in a position to make and implement
  policy.
 B) There is some question as to whether users in the field have
  received message (A) and successfully ended all use of the
  deprecated primitives.  It would be nice if the people who
  know the status could communicate this back to the developers.

The problem is:  It's not obvious that discussions on this list
will solve either of these communication problems.  It's very
asymmetrical:  If somebody squawks, you know you have a problem
... but the converse does not hold.  Furthermore, it seems likely
that the people who subscribe to this list have long since gotten
message (A) ... but what about non-subscribers?  There's a
correlation there, the sort of correlation that makes it very
perilous to extrapolate.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Short, Todd
In reply to this post by Blumenthal, Uri - 0553 - MITLL
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.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<[hidden email] on behalf of [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Peter Waltenberg
Quite reasonable except.

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" <[hidden email]> wrote: -----
To: "[hidden email]" <[hidden email]>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "[hidden email]" <[hidden email]>
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.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<[hidden email] on behalf of [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Hubert Kario
In reply to this post by John Denker-2
On Friday 20 November 2015 12:58:59 John Denker wrote:

> On 11/19/2015 12:28 PM, Viktor Dukhovni wrote:
> > What algorithms people use on
> > their own data is their choice and risk decision not ours.
>
> To say the same thing yet another way, fundamentally we have a
> communication problem, or rather two separate communication
> problems:
>  A) The experts on this list know that certain crypto primitives
>   are "broken or outdated".  This needs to be communicated to the
>   people who are actually in a position to make and implement
>   policy.
>  B) There is some question as to whether users in the field have
>   received message (A) and successfully ended all use of the
>   deprecated primitives.  It would be nice if the people who
>   know the status could communicate this back to the developers.
There are certain situations in which using "broken or outdated"
algorithms is both secure and unavoidable.

See my email from Wed, 18 Nov 2015 14:05:07 +0100.

And to repeat myself: TLS is *not* the only way OpenSSL is used.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Short, Todd
In reply to this post by Peter Waltenberg
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 indirect users into account, they don’t care about the research or advanced uses of OpenSSL; they just want to connect securely to their corporate network.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Nov 20, 2015, at 9:09 PM, Peter Waltenberg <[hidden email]> wrote:

Quite reasonable except.

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" <[hidden email]> wrote: -----
To: "[hidden email]" <[hidden email]>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "[hidden email]" <[hidden email]>
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.

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<[hidden email] on behalf of [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Emilia Käsper-2
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 <[hidden email]> wrote:
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 OpenSSL team (like most open source projects) is made up of
individuals that have widely varying backgrounds and experiences - and
those experiences lead to different view points on a lot of fairly
fundamental topics. This is a good thing - as frankly a project that
doesn't have a mix of view points tends to not last.

Between the OpenSSL team members our experiences cover a very wide range
of uses and many of us have been working on the code base for 17+ years
and have worked in areas that are certainly well outside the average or
common uses. However despite that experience we certainly don't think
that we know what all the users of the code base are doing.

Increasingly we are making sure any debate on project direction where
there are mixed view points within the team brings in the openssl-users
and/or openssl-dev lists so we get to have input from a wider set of
people - who may or may not represent uses that we don't already know about.

All the view points being expressed are valid and there are good reasons
why we could as a team head in either direction (dropping out code or
keeping everything or anything along that spectrum) and what is
important is to listen to the input and see the varying points of view
and add that into the decision making process.

So if you have a use of OpenSSL that you think the team might not know
about then please express that clearly on the list. View points on what
has been proposed are also welcome - but I think you'll find increasing
the awareness of the team about what our users are doing is the more
important of the two objectives in seeking feedback.

Tim.

_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

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

Valerie Anne Bubb Fenwick
In reply to this post by Short, Todd
Sorry to revive this old thread, I did not see any recent updates.
If there are - please point me that way, and apologies in advance.

I saw a reference to SunOS libc compatibility issues, implying we
never remove functionality. I want to be clear - we do.  We do it
by giving our customers advanced notice, and typically only do
so in a "minor" release (using SunOS version numbering, 5.9, 5.10
and 5.11 were "minor" releases. 5.10.1 (or S10U1) was an update/patch
release).

We give the customers advance notice, and typically continue
to support the feature on the currently released OS and it's updates,
and remove it from the next minor.  For example, all S10 updates
may still support the feature, and it disappeared in S11.

As others have noted, it is impossible to maintain all code forever.
It will create bugs.

I removed the "crypt(1)" command from Solaris 11, and "vi -x / -C" options
as well, because they were based on the ENIGMA rotor. VERY insecure.

We gave notice, told customers they should switch to our
new encrypt(1) command (which had AES available) and made the move.

I like Todd's suggestion (someone else made a similar one, too), but
would take it a step further and prehaps only allow decryption/
verification with these old algorithms when enabled. (if possible)

You can see some crypto related EOF announcements for Solaris here:
http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html

Thanks

Valerie

On 11/20/15 02:26 PM, 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 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.
>
> --
> -Todd Short
> // [hidden email] <mailto:[hidden email]>
> // "One if by land, two if by sea, three if by the Internet."
>
> --
> -Todd Short
> // [hidden email] <mailto:[hidden email]>
> // "One if by land, two if by sea, three if by the Internet."
>
>> On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
>> <[hidden email] <mailto:[hidden email]> on behalf of
>> [hidden email] <mailto:[hidden email]>> 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
>


Valerie
--
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1234