733716 - Improve Certificate Manager, show explicit trust, work better with distrusted certificates

Status: NEW

(Core :: Security: PSM, defect, P5)

Description

[Kai Engert [:KaiE:]]

Since we have started to introduce distrusted certificates, certificate manager behaves badly.

(a) A user is able to edit the trust of the distrusted certificate, but once the user did, it's impossible to revert to the original state. We should prevent users from editing or deleting distrust records.

(b) Users are easily confused, because they see our distrusted certificates. Our UI should indicate that it's distrusted.

(c) Our UI should quickly indicate which explicit trust attributes are associated to certificates.

(d) Our distrusted CA certificates should be shown in the CA tab, not in the server tab.

(e) When the user attempts to delete a builtin cert, we currently remove that cert from the display - even though we don't delete it. Yes, we indicate that we will only keep the trust, but users are confused anyway. The certificate should continue to be shown (but with the trust columns updated).

Comment 1

[Kai Engert [:KaiE:]]

Attachment: Patch v2

Bob, do you want to review this code?

I will attach a screenshot, and could provide a test build.

Comment 2

[Kai Engert [:KaiE:]]

Attachment: screenshot

Comment 3

[Robert Relyea]

I'm not a UI designer, so I would like one of them to look at this. I don't think you need Jonathan, but he should have some people working for him. I do have some input.

1) I didn't know what S/M/O meant when I first saw the UI. The seem to be in columns, in some sense the information is redundant.

2) I didn't see any examples of 'nuetral' trust. This would show up on intermediates which are not explicitly distrusted. I would like to see something like 
"T" - trusted 
" "- nuetral 
"X" - distrusted, 
But I would run this by a UI person.

When we edit trust can we explicitly distrust a cert now for a purpose.

Note: Distrust has the following characteristics (IIRC) -
1. For CA's a nuetral ("not trusted") CA can be overrided when we connect to the server. A distrusted CA cannot.
2. A nuetral ("trust unknown") intermediate could be implicitly trusted by linking to a trusted CA. A distrusted intermediate cannot (and cannot be overrided).

bob

Comment 5

[Robert Relyea]

Comment on attachment 603658 [details] [diff] [review]
Patch v2

I've already provided feedback, cancelling review.

Comment 6

[Kathleen Wilson]

Attachment: Certificate Viewer screen shoot

This screen shot of the certificate viewer shows another possible UI for showing which trust bits are set.

Comment 7

[Diane Loviglio [:diane]]

I'm a UX researcher, not designer, but I think the second UI looks clearer since the full labels are shown for S, M and O.

If it's just details - and view only it looks fine.  I'm assuming a user that gets to this screen understands the data presented here.  And from this 2nd screenshot, the highlighted action is close, so it seems that the info is there for those who care, but most will just click close.  Whenever I don't know what to do for UI or there are various opinions, I get the appropriate users, set up a real-life scenario when they would bump into this screen and then ask them to "think-out loud" and tell me what they are doing as they click through the flows.  If we wanted to do that - send me an email and we can talk further.

Comment 8

[Kai Engert [:KaiE:]]

Thanks for your feedback.

I agree with the proposals in general, it should be made more obvious what the letters means, or the letters should be replaced with a more obvious alternative UI.

I hope I will be able to find time on working on better solutions that you can agree with.

In the meantime, in order to allow for early testing of this proposed patch, I've made binaries available at http://flowerbeetle.org

We can discuss about how the UI shall look like, but it's also important to get the new functionality of certificate manager tested, and to get feedback whether the new interaction is an improvement.

Comment 9

[Kathleen Wilson]

(In reply to Kai Engert (:kaie) from comment #8)
> In the meantime, in order to allow for early testing of this proposed patch,
> I've made binaries available at http://flowerbeetle.org
> 
> We can discuss about how the UI shall look like, but it's also important to
> get the new functionality of certificate manager tested, and to get feedback
> whether the new interaction is an improvement.


I downloaded Flowerbeetle to try out the updated Certificate Manager, and the only difference I could see is the S, M, O columns. Is there something else I should be seeing or a change in functionality I should be trying?

Comment 10

[Kai Engert [:KaiE:]]

> I downloaded Flowerbeetle to try out the updated Certificate Manager, and
> the only difference I could see is the S, M, O columns. Is there something
> else I should be seeing or a change in functionality I should be trying?

Yes, see the initial comment in this bug for the full list of changes in functionality.

Comment 11

[Kathleen Wilson]

> (a) A user is able to edit the trust of the distrusted certificate, but once
> the user did, it's impossible to revert to the original state. We should
> prevent users from editing or deleting distrust records.

In Flowerbeetle when I tried to “Edit Trust” of a DigiNotar cert nothing would happen when I clicked on the button, so it seemed like the button was not working.  It would be even better if the “Edit Trust…” button turned grey when an actively distrusted cert has been clicked on so that there is an indicator that the button is disabled for that cert.


> (b) Users are easily confused, because they see our distrusted certificates.
> Our UI should indicate that it's distrusted.

In Flowerbeetle in the “Servers” list there is a column called “S”, and a “-“ in it for the distrusted certs. Since only the SSL trust bit is allowed for the “Servers” certs, it would be even better if the column were called something like “Trusted” or “Trust” or "SSL" (to be consistent with the Authorities tab), and the value in each row could be Yes/No or On/Off.


> (c) Our UI should quickly indicate which explicit trust attributes are
> associated to certificates.

Agreed, as per previous comments about the new UI.


> (d) Our distrusted CA certificates should be shown in the CA tab, not in the
> server tab.

Yes, because a distrusted CA certificate may not even be for SSL. For instance, we could need to distrust a root cert that was only used for S/MIME. If it’s a distrusted root or intermediate, then it should be in the “Authorities” tab as it normally would be.


> (e) When the user attempts to delete a builtin cert, we currently remove
> that cert from the display - even though we don't delete it. Yes, we
> indicate that we will only keep the trust, but users are confused anyway.
> The certificate should continue to be shown (but with the trust columns
> updated).

When I did this in Flowerbeetle the S/M/O columns went bank for that cert. It was not very obvious, so it appeared as though the action had not worked.

Maybe when you update the S/M/O UI to say “SSL”, “Mail” and “Code” in the column headers, then the values that are shown could be “On” and “Off” for each row/column. Then when a user “deletes” a BuiltIn CA, the UI would turn all of the trust bits to “Off” for that cert.

I think the “-“ could still be used for the display value of the distrusted certs. Or something like that to distinguish them between the other certs whose trust bit values can be changed.

Comment 12

[Ludovic Hirlimann [:Usul]]

Would be nice if this new UI came with some sort of documentation for people to quickly understand what these column are about. I think one of the Major issues with Certs is that the number of people who understand what they talk about is limited. I would love to see more documentation - and targeted to the end users being made available.

Comment 13

[Kai Engert [:KaiE:]]

I think the server tab should get the "security device" tab in addition, allowing us to see which explicit distrust entries are stored in the builtin root module.

Comment 14

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 15

[Daniel Kahn Gillmor]

Bug 685823 might be a duplicate of this (or at least has a similar UI proposal that might be worth taking into account).

Comment 17

[Dana Keeler (she/her) (use needinfo) [:keeler]]

This bug will either be broken up into multiple bugs or it will be obviated by a JS rewrite of the certificate manager, but we should keep track of these known issues.

Comment 18

[Ralf G. R. Bergs]

(In reply to Kai Engert (:kaie:) from comment #13)

I think the server tab should get the "security device" tab in addition,
allowing us to see which explicit distrust entries are stored in the builtin
root module.

In addition it would be nice if "disabled"/distrusted certs would appear in "red" color in the list of certs, so that with a single glance it's already clear there is something "wrong" with such certs.

Comment 19

[Martin Mokrejs]

Why is this taking so long? The functionality is great, it is really incovenient clicking on every certificate to study if it is trusted or not.