Great job Frank. Frank Hecker wrote:
> Briefly, the motivations behind this proposal are as follows: I like the foundation. > Without further ado, here's the proposal: > > * Retain the current Firefox UI when SSL/TLS is not used: > > - no padlock or other SSL/TLS-related indicator in status bar > - location bar background is white > - site domain name is *not* displayed in the status bar Agree. To repeat a comment I made in another thread, I think the default address bar should not list pre-protocol-specifier items (username/password@) nor post host-name data (/foo/bar/some.jsp), an option should be to change back to the currently popular model of showing the full gory bits. > * Retain the current "normal case" SSL/TLS Firefox UI: > > - display locked padlock in status bar > - location bar background is yellow > - site domain name from certificate is displayed in status bar Again I say show the certificate subjectDN (organization, country..) and the basic domain name not the full address bar, these are valuable. I like the dispaly of authenticated domain-names in the status bar (ie if they come from a cert at the site). For the rest of the UI variations I need to give it a lot more thought than I have time for at the moment. Mock-ups would probably make a big difference in conveying the ideas (I'm not asking for them, but I'm not likely to make them either). > Some follow-on comments: > * The UI for SSL/TLS with low-assurance certs should be similar but not > identical to that for high-assurance certs. I don't have a strong sense of what the right feedback mechanism should be. But some things to consider feedback for, some of which you address (and most not in the terms presented in the list): =MoFo policy "high assurance" =MoFo policy "low assurance" =MoFo policy "no assurance" =Unknown issuer =Entity name authenticated =Domain name authenticated =Certificate is revoked (perhaps revoked should never be accepted without going through a deep options menu) =Certificate is expired (note that CAs may not offer revocation checking for expired certificates, either by purning CRLs or by refusing OCSP service) =Certificate domain-name matches DNS domain-name =Number of visits to site (the problem here is this wil sometimes unduly scare the user - consider how many dns names WFB uses for their service) > * This proposal in a sense "breaks" existing sites using low-assurance > certs, since users of those sites will no longer see the padlock. To > ease in the transition, it may be appropriate to put up a warning dialog > or informational message the very first time the browser encounters a > low-assurance cert, so that the user will be informed about what is > going on and will (we hope) be less confused when they see the checkmark > instead of the padlock. I like this model many users are completly new users and giving them these kinds of tidbits goes a long way to educating them - few will read a dummy's guide. There should be at least such a pop-up for every note-worthy new event (first high assurance, first low assurance, first domainname mismatch, first unknown CA, first revoked, first expired, change of CA for known site (possible DNS attack). > * In the case of a self-signed cert or cert from an unknown CA, Firefox > should *not* offer users the opportunity to accept the certificate or > the certificate's issuing CA as "trusted", at least not from the > immediately visible UI. This seems a necessarily compromise to avoid the 'click through everything' behavior the user seems to have today. > * In the case of a cert from a known CA but with an non-matching domain > name, the warning dialog should be displayed at least once per browser > session, without the possibility of turning it off permanently for that > site. If an informational message is displayed in this case, then > perhaps its dropdown menu can contain an option to not display the > informational message in the future for not matching domain names > (similar to the option for self-signed certs or unknown CAs); in this > case the UI indicators would remain the same, except for an "X" mark > replacing the "exclamation mark in circle" accompanying the original > informational message. This may be a bit complicated but I don't have a better suggestion off hand. > (I don't think it makes sense to not display a status bar indicator at > all after dismissing the information message, and to treat this case the > same as a non-SSL site. There really is something wrong with the site -- > it's either misconfigured or is using a stolen key and cert -- and the > UI should reflect that.) Agree. > * A "high assurance" certificate can be defined at a high level as "a > certificate issued only after some level of human review of the cert > subscriber", whereas a "low assurance" certificate might be issued > through an automated process, I suggest the inclusion of technical robustness criteria as well. Consider that regardless of the techniques use to vet an enrollment every CA with a standard higher than "anything anyone wants" is bound to need revocation and so without revocation support it is very difficult to maintain a better than floor-level policy. Perhaps high assurance should include support for revocation checking in the certificate. I think it makes sense to differentiate between domain-certificates and identity-certificates in the UI if not in the assurance bucketization as well. If there is a Country and Organization name listed in the cert subjectDN it should be displayed (US; Nike) this is easier on the user than (coolfastnikeshoes.com) in terms of understanding who they are dealing with. > * How would we decide in practice (i.e., at runtime) whether a given > cert was "high-assurance" or not? > For certs added by the user the > assurance level could be set by the user, with low assurance being the > default. (Or if we want to be draconian we could arbitrarily decide to > mark user-added certs as low-assurance only.) I think it's best to leave it to the user to decide, further I think the root list UI should indicate that they added it to help their memory. ram _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
