On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk 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? Is it in fact even necessary that only > a single version of a single cryptographic library be used for such > software? > > 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. > > I do not believe that OpenSSL has promised anywhere that it will > support this sort of use case.
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* . (emphasis mine) -- 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
