Policy restricted smartcard does not generate errors during modification



17 years ago
2 years ago


(Reporter: carosendahl, Unassigned)


1.0 Branch
Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [kerh-coz])



17 years ago
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

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

Comment 1

17 years ago
cc relyea

Comment 2

17 years ago
Looks like a dupe of bug 111078

Comment 3

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

Comment 4

17 years ago
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).



17 years ago
Priority: -- → P3
Summary: PPolicy restricted smartcard does not generate errors during modification → Policy restricted smartcard does not generate errors during modification


17 years ago
Blocks: 157818


17 years ago
Keywords: nsbeta1

Comment 5

15 years ago
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody


14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core


13 years ago
Whiteboard: [kerh-coz]
QA Contact: junruh → ui


11 years ago
Version: psm2.3 → 1.0 Branch
In the absence of significant numbers of users having this problem, we won't be allocating resources to addressing it.
Last Resolved: 2 years ago
Resolution: --- → WONTFIX


2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.