On Tuesday 17 November 2015 13:21:03 Emilia Käsper wrote: > On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton <noloa...@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 <hka...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
