On 11/01/2009 08:28 AM, Marc Kaeser wrote: > Hello Bob, > > I've looked a bit further into the code today, and though you already > explained me those things, let me write them again in order to see if > I understood the idea:
I'm presuming you mean the PSM entry point. > > 1. Starting point: > The problem with nsSDR is that you can't choose another slot/token > than the internal one if one wants to use another storage location for > his/her encryption keys. nsSDR.cpp uses PK11_GetInternalKeySlot() at > line 149 without the possiblity to choose. I presume that's needed to authenticate. I seems to me that it should get the default SDR token as a pref (probably stored as token name). nsSDR would need the PK11SlotInfo for this token, not only to authenticate, but also to pass to the new NSS SDR interface. > > 2. A good solution: > I could modify nsSDR in order to be able to "browse" between all > available "PK11SlotInfo" and "NSSToken" objects, and have e.g. a GUI > to ask the user which slot / token he or her wants to use, or use the > cryptography-module-manager-window to mark the one that should be used > by default. (I have no clue how window-classes are to be implemented > in XPCOM at this point) You probably want to set this in the preferences. You probably do not want to try to grab it on the fly just before you encrypt a password. > > 3. A more difficult point: > The difficulty is to implement the "browsing" of a slot-list, > specially to find the right key to use to PK11SDR_Decrypt() the login > names and pwds. The trick here is when do you need to authenticate to a given token. One strategy is to always use the token defined in the prefs first. If you can't find the appropriate key, then you can move to searching other tokens for the key (a generic PK11SDR_Decrypt that works with all keys). If you found you had to fall back to another key you can also reencrypt with your chosen default token. The code where you set the default token could also optionally walk through and reencrypt all the existing keys to your new default token. This will make the fall back if you can't find the appropriate key less of a necessity. > > Please tell me, if I understand the problem correctly, why isn't that > functionality not already implemented? I asked to myself, NSS is a > complexe and relatively old component I guess, why did nobody do that > already? Someone who is used to XPCOM/NSS could do that in a few... > well... minutes? And I'm going to need... weeks :-D It's always been "something we could conceivably do in the future". This stuff tends to grow organically as people need stuff. We try to architect things so that it hopefully will work in the future (like the idea of even having a key id). bob > > Marc
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
