The "User Identification Request" dialog box for selecting the client cert to send to a server should have a "remember this decision" checkbox.

Changing QA contact to nitinp

Reassigning to ddrinan.

Target -> 2.1

target -> future remove nsenterprise.

Mass assigning QA to ckritzer.

Would this feature remember based on the host, or needs it to consider the path, too?

Remembering based on host would be sufficient, I believe. Since the SSL session (and thus the client cert) is shared across all paths on a host, this is reasonable.

Agreed. Kai, what we should do, if possible, is detect that a cert was presented because of a "remember this decision" hit on the client side. If the server rejects this certs, we should inform the user and not reuse the remembered cert when the user attempts again (at least in this session, but it's probably a better idea to just forget the prefs permanently).

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

I still don't see why bug 177689 should be a duplicate of this bug. If I select a button, I wish it simply to stay checked, and I don't need any extra dialogs to "remember this decision". It is a real bug not an enhancement.

Mozilla Thunderbird 0.2 (20030901) (win98) Bug still here.

Note that some work on this has been done in bug 431819.

This subject (browser UI for client cert selection) has recently gotten a bunch of discussion in the IETF TLS mailing list (of all places!), and in private emails among the participants in that thread. After participating in that, and being mindful of Firefox/Mozilla's desire to resist certs becoming yet-another way to silently track users, I offer these thoughts. 1. We don't want this cert selection dialog to be seen so often that it becomes yet another dialog that users "click through" mindlessly. I think this argues that the default should be to remember the user's choice. If the user does NOT want us to remember the choice, we should honor that, too, but I wouldn't make that the default. 2. We want the "path of least resistance" (the shortest easiest way to dismiss the dialog) to be one that chooses to send no cert, rather than being one that does send a cert. The "fail safe" choice should be to send no cert. 3. The choice of sending no cert should be one of the choices in the list of choices presented to the user. Today, we present the user with a set of certs from which to choose. If the user chooses any of them, we send a cert. If the user wants to choose "none of these", he must click "cancel", which is unintuitive. Cancel seems to suggest stopping the connection and the request, not merely sending no cert. So the choice of sending no cert should be in the list of choices. 4. We should remember the decision to send no cert, just like we remember the decision to send any other cert. Taking the above points together, the choice of "send no cert" should be the default choice, the choice that is pre-selected in the list of choices when the dialog appears. If the user wants to send a cert, he should pick one. But if he merely clicks OK, we should send no cert, and should remember that choice. Comments?

I'll bet Dan wants to participate in this discussion, too.

> 4. We should remember the decision to send no cert, just like we remember > the decision to send any other cert. This is really important!!! I now have to click away the dialog for every mail I send in thunderbird if I do not want to send the cert w/ my private email addresses to my employee. Seems like Bug 135403 also addresses this.

reassign bug owner. mass-update-kaie-20120918

I've patched my nightly in order to remove this dialog: it is really annoying.

I think the fixed in patch of bug 431819. https://hg.mozilla.org/releases/mozilla-1.9.1/rev/fc3a742c4bf2#l2.25