Web verification https ssl certificate

There have been some fuss about certificates lately. The system can be tricked, fooled, abused, simply put: it can not be trusted.
I agree that it is bad that a system of trust can not be trusted, but to me that ain't the main problem here.
The problem is how it is used, when it is applied, and how we interpret the meaning of certificates.
Today a certificate are supposed to identify the endpoint of a session, this is good if you for example; are doing your bank errands. It also gives you an encrypted communication with that endpoint.
Today a certificate are dangerous when you need a encrypted connection with whatever the endpoint is since you also have to claim that you trust the endpoints identity.

Lets have a look at how the internet is used today.

Most of the time, the user just type an address and take part of the content on the page they end up on. Take youtube as an example, most users don't care of typing "http://" and many will not even type the "www". If it looks like youtube and shows you that funny clip you where looking for, there is no reason to doubt or care if is the real youtube or not. As a result youtube has no certificate to prove its identity.... sort of. If you try https://www.youtube.com you will end up at http://www.google.com. That is, if you grant the exeptions, and ignore the warnings.

The need to identify the endpoint is only related to a fraction of the sites a normal surfer visit every month.
The need to limit third parties access to to the traffic between the user and the endpoint, is almost always present, for the same reasons most people put a letter in an envelope, even if it only contains one page.
Most folks don't really care if this or that website really belongs to this or that person/company, they just don't like that their traffic can be viewed or tampered with by a third party, regardless if it is the odd hacker at the cafeé, or goverment sanctioned espionage.
What clips you view on youtube are between you and youtube/google unless you choose otherwise.

So why should you need to add exceptions claiming to know who is on the other side, or start to trust some sketchy SA:s that will lead to a degeneration of the security regarding my banks identity?
They are supposed to be unrelated and should not be effected by one and other.

How to solve this then.

Split the meaning of certificates.
Have one level of certificates govern encryption, managed by a similar system as we have today, it cant be completely trusted, but who cares.

Have another level govern endpoint identification, managed by your bank as a Root CA, where the bank also can trust the store/business they granted doing business for. leaving the Root CA list no longer then the number of banks/creditcards you use.

This will also give you the option of gaining secure communication/access, without having to claim to trust the endpoint identity.

Let the browser treat these 2 different types of certificate differently, to make it clear to the user what's going on. Encrypted communication and/or trusted endpoint.
This way, the level of trust in the endpoint identity are never wider then necessary. If your bank are not trusting a store/business, you can't really do business with them anyway, at least not in a dangerous way, without understanding that there is a risk.

What about the times you like to know the endpoint even if there's no banking involved.
Self signed certificates will work splendidly here, just add a function to see the certificate history.
If the site is referred to you, the refering part could send you the certificate, just like people share pgp keys. If you find the site by yourself a trust are often not immediate, but rather built up as time passes, hence the history feature. When you feel like it's ok to trust the site, just have a peek in the history to verify it still is the site you think it is, and click trust.

What if a previously trusted site should no longer be trusted.
No certificate system will protect you against that. Not today and not tomorrow.
If a site goes bad, regardless if it is a change in EULA, corporate takeover or hacker, it will not be reflected in the certificate, unless the one in control of the site change it.
The only thing you have is revocation lists. If a site owner makes changes outside the tolerance in the certificate, the certificate can be listed in a revocation list to announce it 'no longer valid'. Signing up for a revocation list is done when a certificate are made, and are only trusted by the client in regard of the certificate at hand, and could therefore also be self hosted. The revocation lists are therefore not a trust issue for the site visitor.


Web Certification Fail: Bad Assumptions Lead to Bad Technology

Web Security Trust Models


Mozilla Debates Whether to Trust Chinese CA