Concern about FedoraCryptoConsolidation

Richard Levenberg richardl at
Tue May 7 04:10:59 UTC 2013

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

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.


More information about the devel mailing list