@weddige : sure!

If you go to the centre of a city and see a building that obviously is a bank, then you don't need a "certificate" to be reasonably sure that it's a bank. You don't even have to know the exact address (that one could write as "nr.street.city.country").

The building's geographical location and neighbourhood confirm the identity of what's written on the outside wall, because, in practice, the chance of it being fake is negligible.

OTOH, if you were on holiday in some poor country, and for some reason you end up in a not-so-nice area, and near a scrapyard there's a building that *looks* like a bank; would you trust it?

On the internet you often have no idea where a server is located and how trustworthy anyone with access to it is. The only thing you may know is its address (domain name) - without anyone reliably telling you who is currently "living at that address" (who is responsible for a webserver).

https server certificates USED to do that - more or less.

IMO the following things are needed:

1) Browser users must be able to determine whether information, uniquely identifying the *owner* of a website, is available to them (apart from the address, i.e. the domain name). I.e. what type (DV or better) of certificate is being used;

2) If better than DV, an indication of the *reliability* of the way in which the owner's identity was verified, must be shown. The overall reliability of a CSP (certificate service provider), as determined by the CAB-forum, may affect the reliability score of each certificate signed by that CSP (not as binary as it is/was, i.e. fully distrusting misbehaving CSP's);

3) Users must be educated, at least via functionality built into browsers, that trust depends on answers to the following questions:
a) How sure are you that a website owner is who they say they are (this info should be provided by the browser);
b) What is the reputation of the owner (this knowledge is also required in real life, but IMO makes cert issuance too complicated; external alternative certifications such as ISO 9001 and 27001 *may* help);
c) How trustworthy is the device and software that you use to browse;
d) What is *your* risk (financial or otherwise) if anything goes wong because of some transaction.

So I'm not saying that DV certificates should disappear, but that users should be able to distinguish between knowing just an address versus a website owner identity that was verified with high reliability, as well as a spectrum between those extremes.

W.r.t. the killing of EV-certificates (by Google) based on one incident ("Stripe, Inc") and the assumption that "nobody checks certificates": that incident was caused by the fact that the visible identifying EV information was not worldwide unique (not even between US states) - which is a design error.

Also, certificates contain way too much non-interesting information for end users (serial numbers, SAN's, public key etcetera). This must be fixed.

Furthermore, wildcard certs and certs with lots if seemingly unrelated SAN's (*) in them should have lower reliability scores. If anyway possible, shared hosting should also decrease the reliability score.

(*) Today I ran into one with 582 SAN's: https://crt.sh/?id=7293782180 - part of them are IDN's containing "characters" such as , , etcetera. This cert seems to have been used by a domain name parker, but the one with , appears to be live now (with a certificate only for itself) : https://www.virustotal.com/gui/domain/vdiarybook-com.xn--3t8h.to/summary (see "Siblings").

If end users are not provided with the minimum information required to reasonably assess their risks, or if most or all of them just don't (know how to) do that, then the internet is useless for medium to high-risk transactions. There will be too many victims of fraud (safety-nets are disappearing in NL) and too many company networks will get breached.

#X.509 #x509certificates #Certificates #Certificate #DV #OV #EV #QWAC #CSP #CABforum #Browser #Browsers #Trust #Reliability #Authentication #Impersonation #CA