Last Comment Bug 345934 - PSM should not offer to delete certs in read-only tokens
: PSM should not offer to delete certs in read-only tokens
Status: RESOLVED WORKSFORME
[kerh-coz]
:
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: Trunk
: All All
: -- normal with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 222139 343592 352023 375540 460914 472055 473261 557865 636950 683382 705259 (view as bug list)
Depends on: 173729
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-25 20:31 PDT by Frank Hecker
Modified: 2016-05-05 15:12 PDT (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Frank Hecker 2006-07-25 20:31:22 PDT
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.
Comment 1 Nelson Bolyard (seldom reads bugmail) 2006-07-25 23:39:14 PDT
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!".
Comment 2 Frank Hecker 2006-07-26 08:00:51 PDT
(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.
Comment 3 Julien Pierre 2006-07-26 14:24:50 PDT
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.
Comment 4 Nelson Bolyard (seldom reads bugmail) 2006-07-26 15:15:48 PDT
(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.

Comment 5 Nelson Bolyard (seldom reads bugmail) 2006-07-26 17:05:54 PDT
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.  
Comment 6 runner23 2006-07-27 02:04:41 PDT
(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. 

Comment 7 Kai Engert (:kaie) 2006-07-30 11:34:06 PDT
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.)"
Comment 8 Kai Engert (:kaie) 2006-07-30 11:38:10 PDT
This issue was previously reported in bug 222139.
Comment 9 Kai Engert (:kaie) 2006-07-30 11:38:40 PDT
*** Bug 222139 has been marked as a duplicate of this bug. ***
Comment 10 Nelson Bolyard (seldom reads bugmail) 2006-07-30 18:36:50 PDT
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.  
Comment 11 Tuukka Tolvanen (sp3000) 2006-09-10 05:17:36 PDT
*** Bug 352023 has been marked as a duplicate of this bug. ***
Comment 12 Kai Engert (:kaie) 2007-05-22 16:25:59 PDT
*** Bug 375540 has been marked as a duplicate of this bug. ***
Comment 13 Jo Hermans 2009-01-04 11:47:17 PST
*** Bug 343592 has been marked as a duplicate of this bug. ***
Comment 14 Jo Hermans 2009-01-04 11:48:02 PST
*** Bug 460914 has been marked as a duplicate of this bug. ***
Comment 15 Jo Hermans 2009-01-04 11:48:56 PST
*** Bug 472055 has been marked as a duplicate of this bug. ***
Comment 16 timeless 2009-01-04 18:06:04 PST
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).
Comment 17 Jo Hermans 2009-01-12 17:29:37 PST
*** Bug 473261 has been marked as a duplicate of this bug. ***
Comment 18 Kai Engert (:kaie) 2009-03-10 23:34:42 PDT
adding jonath and honzab, FYI
Comment 19 timeless 2009-04-05 07:36:25 PDT
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.)
Comment 20 Nelson Bolyard (seldom reads bugmail) 2009-04-05 14:00:49 PDT
> 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.
Comment 21 Kevin Brosnan 2010-04-07 11:41:15 PDT
*** Bug 557865 has been marked as a duplicate of this bug. ***
Comment 22 Kai Engert (:kaie) 2010-04-08 05:33:26 PDT
Also see bug 173729.
Comment 23 Kevin Brosnan [:kbrosnan] 2011-02-27 07:21:58 PST
*** Bug 636950 has been marked as a duplicate of this bug. ***
Comment 24 Matthias Versen [:Matti] 2011-08-30 19:00:32 PDT
*** Bug 683382 has been marked as a duplicate of this bug. ***
Comment 25 Kai Engert (:kaie) 2012-01-27 14:00:48 PST
*** Bug 705259 has been marked as a duplicate of this bug. ***
Comment 26 Kai Engert (:kaie) 2012-09-18 10:40:57 PDT
reassign bug owner.
mass-update-kaie-20120918
Comment 27 David Keeler [:keeler] (use needinfo?) 2016-05-05 15:12:11 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.