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.
Looks like a dupe of bug 111078
I believe they are the same bug. It looks like Bob created a patch that never made it in?
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
Priority: -- → P3
Summary: PPolicy restricted smartcard does not generate errors during modification → Policy restricted smartcard does not generate errors during modification
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
In the absence of significant numbers of users having this problem, we won't be allocating resources to addressing it.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.