146028 - Policy restricted smartcard does not generate errors during modification

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, defect, P3)

Description

[Charles Rosendahl]

Build 20020521 Trunk
Windows 2000 Professional 
New Profile w/a restricted Activcard

Using an ActivCard with a restrictive security policy that prevents any
modification to the card (delete, import, etc.) results in misleading behavior
when the operations are attempted.

For instance:
- log in to reader
- within cert manager, delete the certs on the token
- all indications are that the operation succeed.
- after logging out and then logging back in, the certs reappear in Cert Manager
on token.  

Expected:  If the restriction is in force, an error should be returned to the
user indicating failure, and the certs should not be removed from the display in
cert manager.

Actual: They were never deleted, but the impression is that the delete operation
was successful.

Example two:
- go to certificates.netscape.com
- attempt to create a keypair/cert via keygen/online generation method.

Actual: the operation abruptly stops immediately after keygen without any
information

Expected:  If it doesn't succeed, then some type of response is in order.

Comment 1

[Stephane Saux]

cc relyea

Comment 2

[John Unruh]

Looks like a dupe of bug 111078

Comment 3

[Charles Rosendahl]

I believe they are the same bug.  It looks like Bob created a patch that never
made it in?

Comment 4

[Robert Relyea]

No, these are two different bugs. bug 111078 is the case where you have a normal
writeable token and you delete a certificate, under certain cases NSS was not
deleting the keys as well (because it still believed there were certificates
attached to the keys because the certificate also lived in the softoken).

This bug is a ReadOnly Active Card token does not provide the appropriate warnings.
I suspect there are really 2 bugs here. 1) Active Card should be telling us it's
a readonly token (I can be convinced that there may be semantic reasons for
*not* doing this, but if the card can indicate that it's a readonly token, then
certain functions wouldn't even by tried: for instance we would never offer to
generate a key in the token). 2) there seems to be some problem in the error
path where we go to delete a token, but don't know the delete was unsuccessful.
This error may be a PSM, NSS or both (I suspect the latter).

bob

Comment 5

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

In the absence of significant numbers of users having this problem, we won't be allocating resources to addressing it.