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. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
