Closed Bug 79233 Opened 23 years ago Closed 23 years ago

token name fixes

Categories

(Core Graveyard :: Security: UI, defect)

1.0 Branch
x86
Windows NT
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
psm2.0

People

(Reporter: cotter, Assigned: bugz)

Details

Attachments

(1 file)

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
There's just one problem...

There are two separate *tokens* for software security and the cert/key db's. 
The layout,

Internal PKCS #11 Module
- Generic Crypto Services
- Software Security Device

doesn't actually represent the real world, which is really:

Internal PKCS #11 Module #1
- Generic Crypto Services
Internal PKCS #11 Module #2
- Software Security Device

My code depends on grouping slots by token name.  I see three options:
1.  List the two internal slots as being on two tokens, as the really are
2.  special-case them in javascript to make it look like they're on the same token.
3.  set both of their token names to the same string, with unknown consequences.

I'm going to do (1) for now, because it doesn't involve changing my code.  What
are suggestions?
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".
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Closed: 23 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: