I'm not talking 'security' here. I'm talking 'ease of management'. Please allow me to iterate something that you seem to be absolutely ignoring: I AM AWARE OF THE ISSUES THAT YOU HAVE STATED, AND THEY ARE RECOGNIZED AND MITIGATED BY AND IN MY SECURITY POLICY AND SECURITY-VERSUS-USABILITY-VERSUS-MANAGABILITY RATIONALE.
Have you ever tried to fix, for example, an IIS server hosting hundreds of domains that some junior admin mucked the configuration of on a certificate rekey-renewal? This has happened to me. The problem would have been much less time-consuming for me to solve had there been some way of identifying (without having to go through the entire list of all possible SubjectAltNames) which certificate should have gone with which site. The reason it took so long is because ALL certificates were mixed up in the same certificate store, and I not only had to fight with multiple keys and certificates that were currently-valid for the same sites, I had to fight to cross-check that the names were on the right virtual server instance. I don't admin IIS anymore. But I'm very annoyed with the pretentiousness of the coders who think that "they know best" and thus think that they have the right to inflict their concepts of security boundaries, and thus their own concepts of What Security Policy Should Be[tm], on me. Even worse is the fact that I actually get to talk to you and you still think that I don't know what I'm doing, or why, or what the tradeoffs are. IIS has the ability to use every private key in its certificate store. IIS has the ability to use every private key in every certificate store it uses. Separating them out wouldn't have changed this fact -- but it would have been much easier on me to be able to be able to use separate stores that I could independently reference. How about this (currently-hypothetical) case: I have a server (the protocol is unimportant) that speaks TLS, using OpenSSL. This server has the ability to plug in modules that perform various and sundry tasks, and the server calls into these modules. The API that my server provides for interaction with these modules allows for information about the session to be obtained, including the client certificate chain (if provided), the server certificate chain, and information about the current session including the name of the symmetric algorithm, the nominal strength of the algorithm (the number of random bits in the keying material), and the name of the MAC algorithm... but does NOT mandate the use of OpenSSL for cryptography (to allow for maximal flexibility to module authors). Each of these modules can be dynamically loaded and unloaded, has its own startup code which is run when it's loaded, and has its own shutdown code which is run when it's unloaded. For purposes of PKCS#11, each of these modules can rightly be considered an "application", regardless of whether they spawn operating system processes to interact with PKCS#11 things. Two separate module authors decide to use NSS for their cryptography. I happen to want the functionality of both of them, so I try to load them. The first is related to recognition of a specific type of peer-to-peer certificate for filesharing, and the second is related to encrypting a file to multiple recipients identified by their certificates. These modules do not know about each other, do not talk with each other, and there is no 'global NSS handle' which can be passed around. However, there is a single libnspr4.so and libnss3.so that both inform the server that they want, and so the server provides the symbols (since they are supposed to be "shared objects"). After playing with them, I decide that I do not wish to use the first one that I loaded, and attempt to unload it. The unloading code, because it's trying to Do The Right Thing and avoid resource leaks, closes the NSS library. I then turn my attention back to the second one. Suddenly, things break. I decide (based on the fact that it broke after I unloaded something) that the server's unloading mechanism is broken, and I file a bug against it. Currently, the only way to work around an issue like this is for every request into a module to check whether the NSS library is currently initted, and if it's not to reinitialize it. Every key reference needs to be rebuilt, every certificate reference needs to be rebuilt, everything that that independent client uses to call into the library needs to be rebuilt. The situation is worse with 3 NSS-using modules with one unload. Load order: C,B,A. Unload C. Request to A, A notices that NSS is no longer initialized and reinitializes. Request to B, B sees that the library is initialized and tries to use its now-invalid credentials. The only way to work around THIS issue is for every module to forget its information at the end of every request, because there's no way to know if the cache is poisoned. And the only way to ensure this is for every module to unintialize NSS at the end of every request. This is NOT the way a library should work. A library should provide a service in such a way that dependent software doesn't die horribly because its state is changed out from under it. A library should also not require a huge amount of overhead repeated many times in the process just to make it possible for an administrator (the actual "user") to ensure that nothing breaks. I notice from another thread that the SONAME of NSS3 includes the numeral '3', referencing the API version. Why do you rail against the idea of changing the API in an incompatible fashion for a major release (i.e., NSS4 or NSS5)? (Also, just as a note: PKCS#11 version 2.20 section 6.2 states: "A secondary goal was resource-sharing. As desktop multi-tasking operating systems become more popular, a single device should be shared between more than one application. In addition, an application should be able to interface to more than one device at a given time." There is precedent in the standard that you point to as a means to "implement a PEM module" to suggest that my desire to have multiple PKCS11 modules open, even in a single application, is not unjustified -- and I daresay that if I can expect that, I should also be able to have multiple parts of my code talk to the PKCS11 manager completely independently.) -Kyle H On Mon, Aug 18, 2008 at 4:18 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: > Kyle Hamilton wrote, On 2008-08-18 15:20: >> A library is a 'client'. You could replace Howard's use of 'user' >> with 'client' and get more understanding. > > Oh, I quite understand that his model has keys and certs that belong to > libraries, not to users. > > Of course, when a library brings access to those things into a process, > so that the process has access to them, they have effectively come under > the control of the user. The idea that the library somehow retains > exclusive control over the keys/certs, after it has brought them into > the user's process, is silly. The moment that the process can sign or > decrypt using a key through your library, it can do so without your > library. > >> How about the case where each client is supposed to have its own >> private key and certificate? > > That is uses on behalf of all users, but does not let those users share? > Is that the goal? To achieve that goal, access to those keys & certs > must never come into the process space of a user's process. Each user > into whose process space comes control of those keys becomes a user who > has access/control of those keys. > >> I'm not talking about "client trusts a different set of roots" (though >> that's also possible -- imagine a webserver that has different >> requirements for who signs what certificate the browser provides as >> credential based on the port used, and would like to offload the task of >> figuring out what CAs to accept to NSS by enumerating the trusted roots >> in the module assigned to that port), I'm talking "client must provide >> different credentials and for whatever reason needs to keep them >> separate". > > It is an illusion that they are kept separate in that model. If you > really want to keep those credentials separate, then they must not be > accessible in a process belonging to that user. Run a daemon process > to have exclusive access to those credentials. > >> I'm providing hypothetical situations that remain hypothetical because >> of the inability of NSS to adapt to them. > > If NSS doesn't help promote illusory security, so much the better. > >> If there's no real problem with breaking binary compatibility between >> major revisions of NSS, why shouldn't these ideas be identified, >> vetted, accepted, and put into the planning process for NSS 5? > > Of course there's a problem with breaking binary compatibility. > Who said there wasn't? Not me! > > The API can be extended without breaking compatibility, and that is done > in almost every release. The API can be extended without breaking compatibility, but changing the behavior thus allowing multiple clients in a process that manage their own interactions with NSS would break compatibility. This wouldn't be an extension, it would be an outright change to the API contract. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
