[Servercert-wg] Displaying secure sites to Internet users

[Tobias S. Josefowitz]

Hi Paul,

On Thu, 21 Nov 2019, Paul Walsh wrote:

> I have answered your question below.

Many thanks! Let me add a few thoughts.

> [PW] "EV is dead" and "website identity doesn't work" are statements 
> attributed to research that prove it's technically possible to trick the 
> verification system.

To be honest, I have not seen or heard it like that. Maybe I just frequent 
other venues than you. While I in no way want to downplay the fact that EV 
certificates can still get issued with some level of inaccurate, 
misleading or maybe(?) even outright false information, this is however by 
far not the only reason why I am not convinced that EV could be the 
starting point to all our problems.

As I have pointed out in my previous email, in fact, I might, as 
counterintuitive as it may seem, be more convinced of EV if more criminals 
used them - with or without wrong data. As it is, however, criminals 
seemingly staying away from EV and happily using DV for their "projects" 
indicates to me that having EV is apparently not necessary - users will 
happily interact with weird-ish domains with no EV and give them their 
credentials for services that _you_ might expect to sport an EV 
certificate. And as I have pointed out in my previous email and also in 
https://cabforum.org/pipermail/servercert-wg/2019-November/001477.html, 
if we, either by training of users or through technical enforcement, make 
EV certificates a hard requirement for at least some levels of user 
interaction, that would also have grave consequences.

> If we look at food packaging, no harm has come to any company or 
> consumer as a result of additional information being added to the label. 
> While some consumers are happy with just the brand name, some want info 
> on the sugar content, while others might want the calorie count. Some 
> brands (Weight Watchers) go as far as to build a billion dollar business 
> by focusing only on consumers that rely on the content label. The last 
> statement can be said of identity - there are enough people to benefit 
> to warrant our support.
>
> I see certs in the same way as content labels?. Google, Opera and 
> Mozilla might only want DV right now because they only care about 
> encryption, but they might want additional information in the future - 
> using the same cert makes most sense to me - why add time, complexity 
> and cost by creating another cert? Other browsers and applications might 
> want to make use of different information in certs for their own 
> purpose. Some might want the VAT number for UK companies while others 
> might want a certificate of good standing for Delaware companies. 
> There?s no reason not to allow CAs to include all of this information in 
> the same cert and allow third-parties to make use of whatever they 
> desire.
>
> Why should CAs be told what not to include in their certs?

There is a reason for that, and I am happy to share it with you:

When a certificate with additional information is used, we (the 
certificate consumer) have to assume that the additional information 
*might* just be relevant - maybe not to us, but to the owner of the 
certificate. Sure, in some cases additional information might be included 
for no apparent reason, but we will generally have to assume that some 
portion of certificate owners actually relies on the additional 
information being present in the certificate for _something_.

I do not know if you have ever experienced the pleasure of acquiring or 
renewing an EV certificate under time constraints, but the verification of 
data can make the process somewhat time-consuming. Should something happen 
with the certificate - be it having an error, be it that the private key 
has leaked - users of certificate consumers are at risk until the issue 
with the certificate has been remedied, even though we may only consume 
the "DV portions" of it.

We as certificate consumers notice that timely renewal even of DV certs is 
a challenge for many organizations still today, for a multitude of 
reasons; having to go through time consuming validation steps on top will 
not help. We have also seen that such situations cause organizations to 
withhold the information from their CAs (who would be forced to revoke) 
and their and our users, and keep using the compromised certificates for a 
while, because having a large scale "no new certificate yet"-related 
service outage is something they want to avoid at all cost.

By looking to not have additional information in certificates we thus 
directly increase the security of our users in face of actual, realised 
security threats to them.

Tobi