<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
While I am all for simplicity, I also think that removing functionality is a “bad idea”.
<div class=""><br class="">
</div>
<div class="">To reduce the support burden, deprecate the ciphers:</div>
<div class="">1. Under support, indicate that these ciphers will no longer receive fixes.</div>
<div class="">2. Remove any assembly implementations</div>
<div class="">3. Disable them by default.</div>
<div class="">
<div class=""><br class="webkit-block-placeholder">
</div>
<div class="">I suggest following the 80/20 rule (sometimes the 95/5 rule):</div>
<div class=""><br class="">
</div>
<div class="">Those “who care” (the minority) about the ciphers can re-enable them and rebuild the library.</div>
<div class="">Those “who don’t care” (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity.</div>
<div class=""><br class="">
</div>
<div class="">--</div>
<div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">-Todd Short</div>
<div class="">// <a href="mailto:tshort@akamai.com" class="">tshort@akamai.com</a></div>
<div class="">// "One if by land, two if by sea, three if by the Internet."</div>
</div>
</div>
</div>
<br class="">
<div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">--</div>
<div class="">-Todd Short</div>
<div class="">// <a href="mailto:tshort@akamai.com" class="">tshort@akamai.com</a></div>
<div class="">// "One if by land, two if by sea, three if by the Internet."</div>
</div>
</div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu" class="">uri@ll.mit.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"<br class="">
<<a href="mailto:openssl-dev-bounces@openssl.org" class="">openssl-dev-bounces@openssl.org</a> on behalf of
<a href="mailto:bkaduk@akamai.com" class="">bkaduk@akamai.com</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">On 11/18/2015 07:05 AM, Hubert Kario wrote:<br class="">
<blockquote type="cite" class="">So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to<br class="">
support <br class="">
both relatively modern TLS with user certificates, preferably the<br class="">
newest <br class="">
cryptosystems and hashes as well as the oldest ones that were<br class="">
standardised and used.<br class="">
<br class="">
That means that old algorithms MUST remain in OpenSSL as supported<br class="">
functionality. It may require linking to a specific library to make the<br class="">
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed<br class="">
from it completely, definitely not before at least 50 years _after_<br class="">
they <br class="">
became obsolete and broken.<br class="">
</blockquote>
<br class="">
There seems to be a logical leap between these two paragraphs.  Why is<br class="">
it necessary that OpenSSL be the only cryptographic library used by<br class="">
CAdES-A/etc. implementations?<br class="">
</blockquote>
<br class="">
Because it used to be the only real game in town, and *people learned to<br class="">
rely upon it*.<br class="">
<br class="">
<blockquote type="cite" class="">Is it in fact even necessary that only a<br class="">
single version of a single cryptographic library be used for such<br class="">
software? <br class="">
</blockquote>
<br class="">
No, of course not. But after letting people depend on this “single<br class="">
cryptographic library” for many years, telling them “too bad” isn’t very<br class="">
nice.<br class="">
<br class="">
<blockquote type="cite" class="">While OpenSSL may try to be a general-purpose crypto library,<br class="">
when a software has stringent or unusual crypto requirements, it seems<br class="">
reasonable that such a software may need to involve unusual<br class="">
implementations.<br class="">
</blockquote>
<br class="">
The requirements did not change. What changed was the maintainers<br class="">
expressing their desire to stop supporting some of them.<br class="">
<br class="">
<blockquote type="cite" class="">I do not believe that OpenSSL has promised anywhere that it will support<br class="">
this sort of use case.<br class="">
</blockquote>
<br class="">
Implicitly, by providing that kind of service for so long. And explicitly,<br class="">
as pointed out by Hubert:<br class="">
<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span>From the main web page of project:<br class="">
<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><span class="Apple-tab-span" style="white-space:pre"></span>The OpenSSL Project is a collaborative effort to develop a robust,<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><span class="Apple-tab-span" style="white-space:pre"></span>commercial-grade, *full-featured*, and Open Source toolkit<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><span class="Apple-tab-span" style="white-space:pre"></span>implementing the Transport Layer Security (TLS) and Secure Sockets<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><span class="Apple-tab-span" style="white-space:pre"></span>Layer (SSL) protocols as well as a full-strength *general purpose*<br class="">
<span class="Apple-tab-span" style="white-space:pre"></span><span class="Apple-tab-span" style="white-space:pre"></span>*cryptography library* .<br class="">
<br class="">
_______________________________________________<br class="">
openssl-dev mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" class="">
https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>