A library is a 'client'. You could replace Howard's use of 'user' with 'client' and get more understanding.
How about the case where each client is supposed to have its own private key and certificate? 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". I'm providing hypothetical situations that remain hypothetical because of the inability of NSS to adapt to them. 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? -Kyle H On Mon, Aug 18, 2008 at 2:17 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote: > Howard Chu wrote, On 2008-08-17 22:21: >> Nelson B Bolyard wrote: >>> Previously, someone criticized NSS, saying that it was designed for use >>> only on single-user systems, a criticism that I dispute. NSS is very much >>> oriented toward each user have his own set of trusted flags. In contrast to >>> NSS, the idea that there is only one system-wide set of trusted certs, >>> and that each user does not have his own set, is a very single-user-system >>> approach. >> >> It seems you misunderstood my previous criticism, so I'll try again. I said >> NSS is obviously designed for a single-user *environment*, and doesn't cope >> well at all when multiple NSS users exist in a single process. By "users" I >> meant "users of the API", i.e. callers. > > Whoa, you think of libraries as users? > > I think you're saying that you expect every library to have its own set of > trusted certs, as if libraries -- and not true human users -- get to decide > what certs are trusted and what are not. A human user doesn't need a > separate store of certs for every one of his libraries or applications. > > The notion that code, and not the user, makes the security decisions about > what is trusted and what is not trusted, is the basis of many vulnerabilities. > >> This thread is yet another perfect illustration proving my point. If >> multiple libraries are loaded into a process that all use NSS, only the >> first piece of code that calls NSS_Init gets its settings loaded. If any >> of them calls NSS_Shutdown then NSS is torn down for the entire process, >> no matter how many other pieces of code were relying on it. > > NSS_Shutdown is a known issue. > >> The fact that each caller within a process cannot isolate its settings into >> its own context makes it unsafe for use in these environments. The fact that >> one caller's use of certain API calls can pull the rug out from under other >> callers makes it unsafe for these environments. > > Sounds like you really believe that the libraries, and not the user, should > be in control of what is trusted and what is not. If libraries are changing > the user's set of trusted certs without the user's consent, then all manner > of problems (vulnerabilities) will arise. > >> The API design is flawed and cannot be easily fixed; a full and complete >> fix would require an incompatible API change. > > We've already seen that the NSS_Shutdown issue can be solved without any > API *change*, but through the mere addition of a new function to the API. > >> I suggested an approach in my previous post in this thread, but >> while it maintains a measure of compatibility it's still not fool-proof. > > The thing that is being held up as the model to which we should aspire > uses a single common system-wide directory of trusted certs, e.g. > /etc/ssl/certs, or a per-LIBRARY (but nonetheless system wide) directory > of trusted certs, e.g /etc/openldap/ssl/. That's not the model we want > going forward. > _______________________________________________ > 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
