On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: > > No, of course not. But after letting people depend on this ?single > > cryptographic library? for many years, telling them ?too bad? isn?t very > > nice. > > I guess I'm just having a hard time wrapping my head around why, upon > hearing that the volunteer-run project is giving years' advance notice > that certain features will be removed, the response is insistence that > everything must remain supported forever, instead of using the advance > notice to investigate alternatives. Volunteers should be allowed to > ease up when they need to, after all. Culture-clash. Security culture says everything remotely weak must go, but release-engineering culture emphasizes compatibilty. The crypto library is more of a systems component, not a security component. The SSL library is more of a security component than a systems component, and has algorithm negotiation. For example, Linux never breaks user-land, you can do all kinds of things inside the kernel, but user-land software (for a fixed libc) that worked before is going to continue working on new kernels. Doing that since 1991 or so. SunOS libc implemented multiple ABIs to ensure application compatibility. Many other operating systems do likewise. For better or worse, libcrypto is part of that world. It is a building block library for whatever applications the users want to use it for. It is not a security technology in its own right. > Surely the requirements for a general-purpose crypto library must change > over time! Yes, by accretion. And "general-purpose" does not mean "the expected use-cases", it really means "general". > have. As the state of the art advances, the library must adapt to > match, and removing components that are no longer widespread or > essential seems a natural part of that adaptation. The requirements are > not an append-only list. Except that they are, just as Linux and libc provide an append-only set of interfaces. > > 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* . > > > That text reads as if it was originally drafted 10+ years ago, when > "full-featured" meant "we support both encryption and decryption" as > well as "we provide both export-grade and strong crypto". I'm sure we > could put some updated text in if that would help clarify what exactly > the goals of the project are. And, as Richard notes, general-purpose > does not mean "usable for every possible specific use case under the > sun", it means "usable for most common things", which to me does not > include CAdES-A and the like. No, general purpose really means whatever purpose the user has in mind. The "most common things" is not "general purpose". -- Viktor.
