https://fedoraproject.org/wiki/FedoraCryptoConsolidation While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this: curl --cacert truststore.pem --cert example.com.pem:test https://example.com This is where I have a private truststore that I don't want shared with any other applications and client certificate that I don't want to install for usage by any other application. With curl and stunnel for example, how is this use case supported with NSS? The paradigm of having certs in db form is fine for shared resources but not appropriate for resources that are never intended to be shared. curl with OpenSSL uses a file paradigm, defaulting to /usr/local/share/certs/ca-root-nss.crt in the nominal case and whatever you specify in the explicit case. If there is something similar that allows you to create a non-shared "file" in berkeley db format and a non-shared instance of a client certificate in some format that could work. However given that use case is already supported with OpenSSL curl and stunnel, I'm skeptical of all the work to port NSS which was never designed for these use cases. Another problem I see is the case where the global certificates are no longer valid for whatever reason. These decisions can be made by the OS (CRL's), the user/admin OR the application(s). With the NSS, the application seems left out of the decision making process. In many cases the user/admin cannot be relied upon for proper management and the OS's notions of what is valid and the application's notion are different. This situation coalesces to my first use case but I could see it being a more general case of certificate management. r -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
