crypto consolidation status?
Robert Relyea
rrelyea at redhat.com
Fri May 8 18:09:04 UTC 2009
Adam Goode wrote:
> 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 certificate
> store?
The main rational is to put the trust control back in the hands of the
user and the administrators.
> 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.
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).
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.
>
> * 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 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.
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?
We're trying to converge on a single rule for all applications. You can
find that here https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
I'll update that with library information as well.
bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090508/537a26fb/attachment.bin>
More information about the fedora-devel-list
mailing list