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

Wed Nov 18 13:05:07 UTC 2015

On Tuesday 17 November 2015 13:21:03 Emilia Käsper wrote:
> On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton <noloader at gmail.com> 
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 still provides two Verisign certificates using
> > md2WithRSAEncryption. Confer,
> > https://support.apple.com/en-us/HT203065.
> 
> Setting aside the debate of whether verifying trust store signatures
> is useful, whether verifying MD2 signatures has any practical
> security value, or whether OpenSSL + iOS is a meaningful combination:
> 
> This is iOS7. The current release is iOS9 (trust store here:
> https://support.apple.com/en-us/HT205205, MD2 certs are gone).
> 
> Arguments like this illustrate a fundamental misunderstanding in this
> thread.

That's correct. But it exists on both sides of the argument.

> We are not pulling the carpet from any users TODAY. We are
> asking whether there are applications that will need this code
> 2..3..5 years down the line.

And I said that this code will certainly need to stay for 15 more, at 
the very least (more on that below).

> When I referred to the fact that users
> of 1.1 will have to recompile, I didn't mean that errors would be
> revealed by recompilation. I meant that you would have to be an
> actively maintained application or library, and be doing a new
> release, and be stuck using an old algorithm, to even be impacted by
> this change.

Now, please, tell me: how often do you go though your e-mail archive and 
verify that you can decrypt and verify signatures on all the old email 
you have there?

On Monday 16 November 2015 20:28:01 Richard Moore wrote:
> On 16 November 2015 at 19:05, Hubert Kario <hkario at redhat.com> 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 considered secure and
> > that are still relevant today, just 15 years later.
> 
> This doesn't explain why the code needs to exist in future versions
> of openssl. The previous ones aren't going to vanish and can be
> compiled and used to rescue data in theoretical edge cases like this.

It's not theoretical, I know that archival systems which use CAdES, 
PAdES or XAdES exist for over a decade now.

> You're making it sound like this is making the data totally
> inaccessible which is not the case.

It *is* the case.

There seems to be a lot of misunderstanding what I'm talking about so 
let me start from the beginning.

As we all know, by having a RSA, DSA or ECDSA key pair (among others), 
it is possible to create digital signatures of electronic documents. 
Files really. It proves that a given document was created (or at least 
viewed) by a user which signed the document.

But the key sizes appropriate for proving that the signature was not 
constructed (counterfeited) changes in time. Same with key sizes 
supported by typical PKCS#11 tokens - 10 years ago a typical USB token 
wouldn't be able to create a 2048 bit RSA signature.

As we're discussing here, the hash algorithms considered as secure also 
change, with some being broken as time goes one and new being created.

Finally, the key used for signing may be compromised or lost. And even 
if not, it will loose validity at the "notAfter" date. The CA will loose 
validity too, worse, it may stop existing completely...

This creates a problem - how do I prove that a given document was signed 
while the key size was still appropriate, the hash algorithm was still 
considered secure and the certificates were still valid and not-revoked?

The answer is: use a trusted third party that will sign a hash provided 
by you together with a date provided by itself. It's a notary service, 
proving existence of some data at some point in time. It creates a Time 
Stamp.

Now on the scene enter Qualified Digital Signatures. In other words, 
signatures which are considered to be equivalent to paper signatures in 
_everything_ for all purposes under the law - marriage certificates, 
business agreements, medical records, tax reports, etc. They require 
registration (in person) with a state certified CA and use of 
essentially a FIPS 140-3 Level 3 HSM for generating and storing the key.

This extends the problem of Time Stamps. Since many legal documents MUST 
be kept for decades (30 years is not uncommon) we need to deal with not 
only compromises of private keys, key sizes or hashes getting obsoleted 
but _entire cryptosystems_ becoming obsolete.

The solution to this problem, is to regularly time stamp the document 
together with all data necessary to verify original signature and all 
subsequent timestamps (that means, CA certificates, intermediate CA 
certificates, end-user certificates, OCSP responses, CRLs and time 
stamps). This way, it is possible to digitally certify that any 
cryptosystems, signatures and timestamps were created before they could 
have been broken.

Now, to verify that all the data necessary for verification of previous 
signatures (be it on certificates, time stamps or the original document) 
is correct, the application MUST verify all those signatures (legal 
requirement) *before* it adds a new timestamp.

And since those time stamps need to be created using Qualified 
certificates too, usually access to those Time Stamping Authorities is 
limited by TLS with user certificates, so that users need to buy every 
timestamp.

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.
-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151118/e68f10a6/attachment-0001.sig>