439
edits
NSS Library Init: Difference between revisions
→FAQ
(→FAQ) |
|||
| Line 59: | Line 59: | ||
== FAQ == | == FAQ == | ||
1. Shouldn't the NSSInitContext be passed to functions like PK11_GetBestSlot() or CERT_VerfiyCertificate()? | |||
No. First, changing these signatures would not be allowed under the NSS binary compatibility guarantee. Second, the NSSInitContext is only a way to match up NSS_InitContext and NSS_ShutdownContext calls to prevent multiple libraries from prematurely closing NSS on each other. | |||
2. But what if you need to have differently configured trust and certs for different subsystems? | |||
That problem is explicitly not being solved by this proposal. So far I've seen one convincing use of trust domains (that is a single process virtual hosting environment). Most proposed scenarios for using multiple trust domains are really better handled using certificate policy. Using a different root cert for each kind of access tends not to scale well. | |||
That being said, adding trust domain support remains an option in the future. In all these cases, however, it's clear that trust domain support should be separate for NSS_Initialization. If you have multiple trust domains, you will most certainly want to support them in the context of a single NSS_Initialization. | |||
Finally, in most cases, a library using NSS in the context of an application that is already using NSS, should use the configuation of the application anyway. User's don't view the combination as a separate entity, but a single application. When the user configures his certs in thunderbird, he will be surprised if those certs aren't available to his ldap library, for instance. | |||
In short NSSInitContexts are not meant to be replacement for trust domains. | |||
3. What happens if NSS_Init is called more than once? | |||
If NSS_Init is called more than once (without an intervening NSS_Shutdown), the second NSS_Init returns SECSuccess without doing anything, just as it does today. This is to keep current applications which depend on this behavior from breaking. | |||
4. What happens if I only call NSS_InitContext()? | |||
NSS is fully initialized, and will stay initialized at least until you call NSS_ShutdownContext(), or someone calls NSS_Shutdown(). | |||
5. Why does NSS_Shutdown() always shutdown, rather than just shutdown the NSS_Init side? | |||
Some applications (at least in the past), call NSS_Shutdown() to 'switch profiles'. In order for this to work, NSS_Shutdown() must try to shutdown NSS completely. | |||
NOTE: If some library attached to this application is actively using NSS at the time (open SSL connection, holding cert, key, or slot references, etc.), NSS_Shutdown() does not completely shutdown today. In light of this fact, it may be better to treat NSS_Shutdown() with the semantics described for NSS_ShutdownContext(NULL). I believe I can be talked into this semantic, but I wrote the proposal for the most conservative position on binary compatibility. | |||
6. What happens if you call a PKCS #11 module which has already been initialized? | |||
When a someone attempts to initialize a PKCS #11 module a second time, the PKCS #11 module will return CKR_LIBRARY_ALREADY_INITIALIZED. At this point one of two things happen: | |||
1) If the PKCS #11 module supports the NSS 'add new slot' protocol, then NSS will add a new slow with the new configuration. | |||
2) For most modules we will move on. The requested module is already initialized and loaded in the trust domain, there is no further work needed to use it. | |||
7. FIPS question [still working on it..] | |||