On 14/08/2019 18:18, Peter Bowen wrote:
On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
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
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
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
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 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