No me preguntéis cómo llegué a esa página porque ni me acuerdo, pero el caso es que Fedora tiene un proyecto para consolidar las bibliotecas criptográficas de Linux en una. Ahora mismo hay varias bibliotecas, distintas e incompatibles, proporcionando servicios criptográficos (OpenSSL, NSS, GnuTLS, la criptografía en el propio kernel, etc) y en Fedora/Red Hat lo que pretenden es que haya un solo API que usen todas las aplicaciones, y un único sitio donde se almacenen claves y certificados.
Lo que tal vez en RH estén pasando por alto es que la existencia de varias implementaciones no es caprichosa. NSS (Network Security Services) es la implementación de Mozilla, desarrollada principalmente para su navegador, y eso marca sus características, como la portabilidad a todo tipo de sistemas operativos o la necesidad de pasar las restricciones de exportación estadounidenses. También es la que más certificaciones oficiales ha recibido, y por lo tanto la elegida por el proyecto de Fedora. OpenSSL es la implementación "clásica" Unix para añadir soporte SSL a tus aplicaciones, pero debido a la incompatibilidad de su licencia con la GPL, las aplicaciones con esa licencia suelen evitarla. Por ello el proyecto GNU patrocinó la creación de GnuTLS bajo licencia LGPL, para que los programas GPL tuvieran una alternativa. Y aunque actualmente GnuTLS no es un proyecto oficial de GNU (debido a discrepancias de su autor con la FSF), la licencia LGPL empleada sigue siendo importante para quienes emplean esta biblioteca.
Por ello la idea de la consolidación, aunque en principio pueda resultar atractiva, no lo es tanto si se piensa en la disparidad de licencias y objetivos. Lo que sí me parece buena idea es la intención de unificar claves y certificados en un único lugar (y formato). Pero para ello no hace falta tanto una reescritura de aplicaciones como la creación de un estándar, por ejemplo alrededor de los de FreeDesktop. FreeDesktop ya tiene estandarizados directorios para datos de aplicaciones, configuración o ficheros temporales, y no costaría mucho ampliarlo para claves y certificados. Añadiendo uno (o varios) formatos para reconocer los diferentes objetos, quedaría al albur de cada biblioteca implementar el estándar en su código. Algo bastante menos intrusivo que mandar parches a decenas de aplicaciones.
Lo que sí hay que hacer es disuadir a los desarrolladores es de escribir sus propias bibliotecas criptográficas. Implementar correctamente algoritmos de cifrado y descrifrado, incluso cuando son ampliamente conocidos y están extensamente documentados, es difícil. Hacerlo sin introducir ningún tipo de debilidades, francamente complicado para quienes no tienen una gran experiencia en la materia. Las debilidades pueden ser más sutiles de lo que programador medio puede llegar a imaginarse. Por ello es mejor dejar la implementación (y la auditoría) a verdaderos expertos. El resto nos tenemos que conformar con usar dichas bibliotecas... y dar gracias a $DEITY por librarnos de tener que programarlas nosotros.
Red Hat tiene por supuesto una motivación empresarial al querer ofrecer un API unificada como la que ofrece su competencia de Redmond o Cupertino, pero eso no significa que haya que desdeñarla. El núcleo de la idea no es malo, aunque tal vez no tanto el camino elegido para implementarla.
:wq