Token names appear in the request for password dialog, the Certificate Manager, the Change Password dialog, and the Device Manager. This bug summarizes the token names that should appear all these places. It also includes a change in name for the root cert module. In the Device Manager, the token names for the PKCS #11 module should look like this: Internal PKCS #11 Module - Generic Crypto Services - Software Security Device Note that the term "Security Device" is now part of the name of the internal keys & certs token. Therefore, when the password request dialog is displayed for the internal token, it should read like this: Please enter the master password for the Software Security Device. The general case: Please enter the master password for the [name of token]. Note that the term "security device" should no longer be appended to the name of the token in the password request dialog. Otherwise, it will read ". . . for the Software Security Device security device." In the Certificate Manager, the column currently labeled "Token Name" should be labeled "Security Device".
Changed target to 2.0.
Target Milestone: --- → 2.0
I have another question. After changing the strings as above, everything that uses token->tokenName will be messed up. Token name is now "Internal PKCS#11 Module", so if you try to log in you are asked to log in to that, not "Software Security Device". Are you supposed to log in to tokens, or slots? If the answer is slots, then the UI needs to be changed to use token->slotName, in which case "Software Security Device" would show up.
My understanding is that you log onto a token (e.g. an individual smart card), not a slot. A module contains one or more slots, which each contain one token. I always thought the PKCS #11 module was a single module with two slots, but I'm on shaky ground here technically. (See http://www.mozilla.org/projects/security/pki/nss/ref/ssl/gtstd.html#1013181.) So, if the correct thing to do is show two internal PKCS#11 modules, then the screen dump for the device manager looks right to me--except that if "Builtin Object Token" is really a token, shouldn't it and "Root Certificates" trade places? The password request should read, "Please enter the master password for the Software Security Device." That is, it should be asking for the password associated with the token, not the module. And the words "security device" should not be added to the name of the token. Adding Relyea to the cc list.
I suggest renaming "Software Security Device" to "Software Certificate Storage" or "On-disk Certificate Storage".
I think I've gotten confused. How is the device list supposed to look? I have (based on the mock-up): Token #1: Slot #1 Slot #2 Token #2: Slot #1 ... The diagram makes me think that it should be: Module #1: Slot #1 Slot #2 Module #2: Slot #1 ... which would involve some different code than what we have now...
Then the mock-up is wrong. In PKCS#11 world, a module has slots, and a slot can either be empty of have a token installed. Given that, have multiple slots listed under one token doesn't make sense, since there will only be one token in a given slot and potentially multiple slots per module.
I guess this points to a greater confusion I have. Why do we have an nsPK11TokenDB? If you call nsPK11TokenDB::ListAllTokens, do you only expect to receive tokens that are plugged into slots (since otherwise, you don't really have the token)? For device manager, I really need an interface for secmod.db. I could then have something like: nsSecModule ** nsSecModuleDB::ListAllModules(); and nsPK11Slot ** nsSecModule::GetSlotsFromModule(nsSecModule *module); I don't see how to do this with nsPK11TokenDB. Do we either have to 1) implement three new interfaces (nsSecModuleDB, nsSecModule, and nsPK11Slot), or 2) modify nsPK11TokenDB to do everything, even if it's completely incorrect semantically?
This is a response to John Myers' most recent suggestion for the internal token name: Software Certificate Storage or On-Disk Certificate Storage. If I remember right, "Software Security Device" originally came from John too, in an IRC discussion. There was a time when this token was called the "Communicator Certificate DB". There were several objections to this. For one thing, it's not strictly accurate--I believe the certs are currently not stored in either token, they're stored in the cert db. This internal token actually stores the private keys, not the certs, and also the master key used by the Password Manager. A more significant problem is that the request "Please enter the master password for Software Certificate Storage" or some variation on that doesn't make any sense for Password Manager users who don't know or care about certs. It can certainly be argued that "Software Security Device" won't make much sense to such users either. However, PSM 1.x started using "security device" as the generic name for a token, and it is defined as such in the help system. So far, the term seems to be working. Unfortunately, anything more specific is likely to be wrong or misleading for some subset of users. So I still think "Software Security Device" is the term that best fits the various situations in which people will see it.
OK quick update on the meaning of various phrases and I discussion of what Communicator implemented and how it should be improved. (hopefully I'll get this posted before it gets swamped again.. module - represents a separate PKCS #11 dll. Really it's a separate function list of C_ function calls, so in theory out could have multiples a single DLL, except there is only one entry point per DLL to get this function list. The only exception is the internal module. There's a module for the standard driver and another module for the fips module. These two modules are mutually exclusive (you don't have both installed at the same time. slot - represents a physical reader that can accept tokens, or a virtual 'slot' in the case of software tokens. There are 1 or more slots per module. tokens - represent an actual device (either software or hardware). There can be either 0 or 1 tokens/slot. These differences show up in the name. Slots are always present, therefore their name is always available. It usually has name like 'Reader #1' or 'iButton slot #2'. These names typically only show up in the Administration UI. Tokens may or may not be present. You cannot do any crypto operations unless the token is present. Tokens are where private keys and certs are stored. They usually have some user selected name like 'Bob's DataKey' or 'Bob's AOL Badge'. These are the names the user will expect when they get password prompts, or prompts asking what token to use to store a generated key (for example). In Communicator, The UI listed the devices as follows: -> Module 1 ---> Slot/Token 1 ---> Slot/Token 2 ---> Slot/Token 3 The name would change from the slot name to the token name if the token was present, and back to the slot name when the token was removed. This could be a bit confusing for the user. What we should do now is either: -> Module 1 --> Slot 1 --> Slot 2 (Token Name) or -> Module 1 --> Slot 1 --> Slot 2 ------> Token Name I like the first way as it's more compact, and slots/tokens work hand in hand (internally there is one structure that stores all the slot and token information together. The second way has some advantages where we can separate token Info and slot Info as well as separate where various configuration parameters have effect. For instance changing the password changes the token password, but changing the password policy changes the policy on the slot (not the token). That is if you change both the password and the policy, remove the card, insert a second, the second will have it's old password and the new policy. If you take the first card and insert it into a different slot, it will have the changed password, but will not maintain the password policy.
Apologies for not including a rationale for my suggestion. My original objection to "Communicator Certificate DB" was as a developer of a server product that used NSS. It does not make sense to use the qualifier "Communicator" in a product other than Communicator. In that time, the same token name was used to refer to both the storage of keys and certs in cert7.db/key3.db and the software crypto implementation. These have now apparently been split into two tokens, one for the storage and another for the software crypto implementation. The term "Software" is appropriate for the latter, not the former--it makes sense to talk about a software implementation of crypto, but is a bit confusing to talk about software storage of information. The keys and certs are stored in the filesystem or, as users think of it, "on disk". My suggestions are an attempt to make the wording of dialog boxes containing token names more task oriented. A "Software Device" is an unusual concept, generally only understood by developers and lawyers. I was under the impression that the internal token does actually store the certificates. Bob, could you clarify? For the password prompt, the internal key storage token is both a special case (not a hardware device) and the common case. We should strongly consider special-casing this, using a completely different set of wording when prompting for the password for this particular PKCS#11 token. I would like to revise Bob's first suggestion to explicitly indicate when a slot is empty: -> Module 1 --> Slot 1 (empty) --> Slot 2 (Token Name) I also hope we can elide the slot names of modules which support only one slot.
One possible problem with my "On-disk Certificate Storage" suggestion is hardware crypto accelerator devices whose modules also store keys/certs on disk.
Recap of discussion of internal token name: This name appears most frequently when the user has decided to encrypt passwords etc. stored by the Password Manager and is asked to enter the master password protecting that info. Less frequently (today, anyway), the user needs to enter the master password because some operation involves one of the user's certificates and corresponding private key. The password request takes this form: Please enter the master password for the [name of token] ["security device" is appended in PSM 1.x, could possibly be dropped in 2.0]. I believe Bob Relyea is opposed to special-casing the internal token name (due to smart card vendor concerns?). As John pointed out, the notion of a "Software Security Device" is odd. But referring to certificates won't work either, because certificates aren't always involved. Here are some other possibilities that I can think of: - Disk Storage Security Device - Default Security Device - Internal Security Device - Internal Storage Security Device. Though it may strike us as odd, I'm not so sure "Software Security Device" is so difficult from a user's point of view. Software is magic stuff inside hardware. Distinctions between RAM, hard disk, running or not running, etc. are not necessarily relevant for most users. But Disk Storage Security Device is the most explicit option. I'm not so sure that we need to worry about conflicting with other modules that store on disk, since they will have their own separate token names. Based on the discussion so far, my preference is now Disk Storage Security Device. Another benefit of this is that the actual token name could be simply "Disk Storage" (e.g. as listed in the Cert Manager in the Security Device column), and we could append "security device" to every token name as PSM 1.4x currently does. ("Software" by itself as a token name is weird, but Disk Storage might not be.) We need to make this decision one way or the other soon. If referring to "disk" is really a problem, then I still think Software Security Device is better than the others.
Just a warning to everyone cc'ed on this bug: what I have checked in uses "Software Security Device". Unless someone can make a case as to why this is a high-priority, it probably won't be changed before the code freeze.
Ignoring FIPs mode for a second: There have always been two internal tokens: The internal crypto services token, and the internal database token. The latter has always stored both certs and keys. There are two tokens because we want to be able to do crypto operations without logging in (authenticating), but we don't want to access private keys without logging in. NOTE: the database token can also do crypto operations (though in practice it only really does RSA decrypt/sign). In FIPS mode both functions are combined, since FIPS requires authentication before doing any crypto operation. bob
Marking fixed since mcgreer says he's checked in the wording.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.