> 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. You're making it sound > like this is making the data totally inaccessible which is not the case.
Of course people can keep the current OpenSSL version indefinitely – and if the maintainers are too aggressive, it might just happen. But the vast majority of the uses would like to upgrade to new releases with hopefully more bugs fixed and fewer bugs introduced – and maintain their current functionality. Because if the new version stops decrypting their documents, who needs it? Several people pointed out: SSL/TLS is where the algorithm agility is, where the exploits are, and what needs to be pruned. So remove the dead wood from libssl. Leave libcrypto alone – it is useful as-is, and real-life big packages (like Perl) depend on it providing all the services it currently offers. Don’t punish users for choosing OpenSSL library to handle their non-SSL cryptographic needs and implicitly trusting the developers that they won’t be left in the cold.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
