When you "delete" a CA cert that's pre-loaded in NSSCKBI.DLL the immediate UI indication is that the CA cert has in fact been deleted "for real", i.e., the CA cert is removed from the listing of CA certs. However if you restart Firefox then the CA cert once again shows up in the display (although if you do "edit" you can see that it is marked as untrusted. This behavior is IMO unnecessarily confusing to users, who expect a "deleted" cert to in fact continue to appear deleted (or at least inactive). I think it would be better if pre-loaded certs marked as untrusted for any use were either not displayed at all, were displayed grayed out, or were displayed in some other manner that indicated to the user that the certs in question were not currently being used.

For most people, deleting cert is never what they really want to do. They really want to mark the cert untrusted. When they find out they have a bad cert, their first inclination is to want to get rid of it, as if it were a virus. But a better solution is to keep it around, as a reminder that "this is a bad one. don't trust it!" Perhaps this analogy will help. When some crook commits a bad crime, the FBI doesn't go out and obliterate all images of him. They distribute his picture with words "10 most wanted: dead or alive" or something like that. That's how it should be with bad CA certs, too. When you find a rogue CA cert, you don't want to remove it. You want to mark it "bad cert: if you see this guy, do not trust him!" If anything, I think we should eliminate the cert deletion feature, and leave trust flags as the ultimate way to say "no!".

(In reply to comment #1) > When you find a rogue CA > cert, you don't want to remove it. You want to mark it "bad cert: > if you see this guy, do not trust him!" That's why I suggested using some alternative way of marking the CA cert as "deactivated" or "totally untrusted", as opposed to suppressing it from the display. Another point is that if a user accidentally "deleted" a pre-loaded CA cert and it was then no longer displayed, it would be difficult to impossible for the typical user to figure out how to reverse the "deletion". (Reinstalling Firefox wouldn't help I don't think, as the "trust" indicators would not be affected; only creating a new profile would do the trick.) > If anything, I think we should eliminate the cert deletion feature, > and leave trust flags as the ultimate way to say "no!". I think some form of "delete" operation is useful, for two reasons: First, in the absence of a "delete" button (or equivalent) it's not totally obvious how to "disable" a CA, i.e., mark it as untrusted for anything. Note that "mele" (from the mozilla.dev.security discussion) got confused about this point, and missed the fact that the "Edit" button could be used for this. Second, for CA certs that are not pre-loaded but explicitly added, it would be useful (at least for power users) to have some way to totally purge any record of the cert from the cert database. One possibility is that the "Delete" button could play a dual role. If the user selected a non-preloaded CA cert then the button would do a true deletion. However if the user selected a pre-loaded CA cert then the button would change text to "Disable" (or something similar) and just flip off the trust bits, leaving the CA cert in the list but with different appearance. However the problem with this suggestion is that it is possible to select multiple CA certs (including both preloaded and non-preloaded certs) and "delete" them in a single operation.

I think the delete feature is also needed for some cases where bad PKI has been implemented (eg. 2 certs with identical issuer and serial numbers). The only way to resolve problems in those cases is to delete one or more certs.

(In reply to comment #3) > I think the delete feature is also needed for some cases where bad PKI has been > implemented (eg. 2 certs with identical issuer and serial numbers). The only > way to resolve problems in those cases is to delete one or more certs. No, the solution is to reissue a new cert with a unique serial number.

I agree that it is confusing for delete to not actually delete. But we cannot actually delete certs in read-only tokens. PSM should gray out the delete button for certs in a read-only PKCS#11 token such as NSSCKBI.DLL.

(In reply to comment #5) > I agree that it is confusing for delete to not actually delete. > But we cannot actually delete certs in read-only tokens. > > PSM should gray out the delete button for certs in a read-only PKCS#11 token > such as NSSCKBI.DLL. > Graying out the button will just make it more confusing unless something is done so that users understand that they can accomplish what they want with the edit button. The underlying problem here is the paucity of information in the help file regarding how certificates are handled.

In order to address all previous concerns, my proposal is to keep the "delete" button enabled for ca certs in read only tokens, however, at the time the user presses the button, I propose this new behaviour: - remove all trust from the certificate, as we currently do - in addition, bring up a message that says "This certificate has now been marked untrusted, which is equivalent to deleting it. (It is not possible to completely delete this certificate, because it has been shipped with the product.)"

This issue was previously reported in bug 222139.

*** Bug 222139 has been marked as a duplicate of this bug. ***

NSSCKBI is not the only read-only token. The problem is not that it is "part of the product", but that it is a read only token, and it makes no sense to offer to delete things from a read-only token. Why perpetuate the myth that certs in read-only tokens can be deleted? Why produce a window that apologizes for not doing what the user asks? That's a "band-aid" solution. Why not integrate the trust viewing and editing with the main cert detail viewing? This UI needs much more than a band-aid. It needs to be designed so that the right thing for the user to do is as obvious, or more obvious, than the wrong thing. Eliminate the "Edit" button completely. Put the things that can be edited in the main cert detail view window, so they will be obvious to the user, not hidden. Let them be alterntive choices to delete, right on the same window where the delete button lives. When the delete button id grayed out, the user will immediately see what his alterantives are, and will use them.

*** Bug 352023 has been marked as a duplicate of this bug. ***

http://mxr-test.konigsberg.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSCertificateDB.cpp?mark=979-981,984-994#964 so. i'm perfectly happy to change the button label from "delete" to "remove trust" or something. however, i can't figure out how one would even recognize if a storage module was "Readonly". AFAICT, psm doesn't expose such a detail. Does NSS *technically* expose it? note that if i'm given a personal user certificate which i really don't want, i need to be able to delete it. forcing me to carry a certificate that i don't want just because of purity concerns for other cases isn't ok. but i see that case as fairly distinct (as long as we can distinguish them, and i'd hope we could).

adding jonath and honzab, FYI

nelson: ping. does NSS *technically* provide a way for a consumer to determine that a token is in fact readonly? (if so, could you please provide sample code.)

> does NSS *technically* provide a way for a consumer to determine > that a token is in fact readonly? Timeless, that's a great question for Bob Relyea, our chief PKCS#11 guru. If the answer is "not presently", then maybe he can suggest a good new API for this purpose.

Also see bug 173729.

reassign bug owner. mass-update-kaie-20120918

In the certificate manager, the wording was changed to "delete or distrust" with some text explaining what will happen. I think that's probably good enough.