Adam Goode wrote:
The main rational is to put the trust control back in the hands of the user and the administrators.Hi,Some of my colleagues work on an RPC library that will be gaining TLS support. http://minirpc.cs.cmu.edu/Being familiar with http://fedoraproject.org/wiki/FedoraCryptoConsolidation I of course told them that NSS was the best library to use for this. But there are a few issues with this: * What is the rationale for requiring a shared certificatestore?
In NSS trust is handled in terms of types. That is a certificate is trusted for SSL or S/MIME or Code Signing. It's possible for an application to trust additional certs which aren't in the normal NSS database temporarily (Firefox uses this when you accept an override, for instance).More importantly, we would like to allow an application to temporarily use a private cert (that it may trust for some reason) without spreading that trust to all applications on the system. It seems like the issue of certificate management is separable from the actual crypto part.
Applications are also allowed to open multiple private databases as well, though this feature is seldom used at the current time.
Note that many of these types of actions on the part of the application makes it more difficult to centrally manage crypto on your machine. So while they are available to you as an application, I suggest making it configurable to turn these options off so that admins can still control the security options on a box.
There is an internal state for NSS called a trust domain. This trust domain is not yet surfaced, mainly because the use case for running multiple separate trust domains in a single application has never truly surfaced. With a single view of the trusted certs per user, it still does not come into full view.* We are trying to use TLS from a library. The NSS documentation seems to suggest that calling NSS_Init more than once is bad. It doesn't look like it would be safe to call NSS_Init from a library. Really NSS should be returning a context object that encapsulates all NSS state, yes?
There are is the issue of the first NSS_Init wins that Rob pointed out. I'm hoping to fix that issue in the next month or two and send out recommendations on how libraries should initialize NSS.
* It's not obvious what to pass to NSS_Init. Looking at nss_compat_ossl
shows some tricks with getenv("SSL_DIR") and such. Is that practice
documented anywhere?
I'll update that with library information as well. bob
<<attachment: smime.p7s>>
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
