On 14/08/2019 18:18, Peter Bowen wrote:
On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

A policy of switching from positive to negative indicators of security
differences is no justification to switch to NO indication.  And it
certainly doesn't help user understanding of any indicator to
arbitrarily change it with 3 days of no meaningful discussion.

The only thing that was insecure with Firefox EV has been that the
original EV indicator only displayed the O= and C= field without enough
context (ST, L).  The change fixes nothing, but instead removes the direct
indication of
the validation strength (low-effort DV vs. EV) AND removes the one piece
of essential context that was previously there (country).

If something should be done, it would be to merge the requirements for
EV and OV with an appropriate transition period to cause the distinction
to disappear (so at least 2 years from new issuance policy).  UI
indication should continue to distinguish between properly validated OV
and the mere "enable encryption with no real checks" DV certificates.

I have to admit that I'm a little confused by this whole discussion.  While
I've been involved with PKI for a while, I've never been clear on the
problem(s) that need to be solved that drove the browser UIs and creation
of EV certificates.

EV was originally an initiative to make the CAs properly vet OV
certificates, and to mark those CAs that had done a proper job.
EV issuing CAs were permitted to still sell the sloppily validated
OV certs to compete against the CAs that hadn't yet cleaned up their

This was before the BRs took effect, meaning that the bar for issuing OV
certs was very low.

To heavihandidly pressure the bad CAs to get in line, Firefox simultaneously started to display exaggerated and untruthful warnings for OV certificates, essentially telling users they were merely DV certificates.

So the intended long term benefit would be that less reliable CAs would
exit the market, making the certificate information displayed more
reliable for users.

The intended short term benefit would be to prevent users from believing
unvalidated certificate information from CAs that didn't check things properly.

As BRs and audits for OV certs have been ramped up, the difference between OV and EV has become less significant, while the difference between DV and OV has massively increased.

Thus blurring the line between OV and EV could now be justified, but blurring the line between DV and EV can not.

On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before and
after.  For example, "It used to take 10 minutes for the fire sprinklers to
activate after sensing excessive heat in our building.  With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long before
it spreads."

It used to be easy for fraudsters to get an OV certificate with untrue company information from smaller CAs. By only displaying company information for more strictly checked EV certificates, it now becomes much more difficult for fraudsters to pretend to be someone else, making fewer users fall for such scams.

Displaying an overly truncated form of the company information, combined with genuine high-trust companies (banks, credit card companies) often using obscure subsidiary names instead of their user trusted company names for their EV certs has greatly reduced this benefit.

If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view chains,
etc), what user experience problem would you be solving by adding
information about certificates to the UI?

This hasn't been the case since before Mozilla was founded.

But lets assume we started from there, the benefit would be to tell
users when they were dealing with the company they know from the
physical world versus someone almost quite unlike them.

Making this visible with as few (maybe 0) extra user actions increases
the likelihood that users will spot the problem when there is one.


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list

Reply via email to