I think that a good system would be that the key can be signed by multiple parties. For example if you are running a web shop, your certificate could be signed by Visa if you accept card payments, by your registrar to prove that you own the domain, by the tax office in your country to prove that you are a real company and so on. And then the browser would show these signatures as badges when clicking/hovering the padlock icon. So essentially the more signatures the more trustworthy.
Right now, CAs in the Web PKI certify authenticity, not trustworthiness: when the system works correctly, a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding.
What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.)
Unfortunately TLS is already conflating two problems as it is:
1. Is the opposite party who they claim to be?
2. Did a third party alter or eavesdrop on the transmission?
That is, am I simply being phished in private or is the government also listening to me being phished?
It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1.
There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
It is not trivially easy to solve the second problem without solving the first problem. If you don't have proof of identity, all someone has to do to eavesdrop on you is pretend to be the person you're communicating with while actually communicating with them on your behalf.
It's the difference between a passive attack and an active attack. Most people think only of passive eavesdroppers, and against them it could be true that "it's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever". But against an active attacker, unless you can solve the "is the opposite party who they claim to be" problem, it's trivially easy to eavesdrop by pretending to be the other party (MITM attack).
And then you find out there are ways to convert a passive eavesdropper into an active attacker (remotely injecting packets to manipulate the TCP connection state, based on observed sequence numbers), and the distinction becomes a bit fuzzy...
It's trivially easy when that 'proof of identity' is purely a unique identifier shown to the user, and not actually tied to real-world identity. This is what a domain name is, ICANN ensures people can't register a domain name if someone already owns it, so with that guarantee, everyone trusts that 'google.com' showing up in their URL bar means that the certificate presented by the server they're connecting to is actually authorized to show 'google.com'.
That proof of identity still needs to solve the first problem... you still need to somehow prove that someone who says they're google.com is actually google.com.
B) why having an untrustworthy root CA is the most calamitous outcome possible.
Because the algorithm that yields the answer to your question really only answers the question "Does the cert I was handed cryptographically validate back to a trusted root?"
If you can pwn the routing/DNS sufficiently around an AS, you could MITM all the authoritative sources, and with something like TrustCor, willing to issue duplicitous root certs and cert chains, while being trusted by major OS and software package maintainers, you can, in theory, pull the old switcheroo, and the software will still tell you "seems legit, hoss".
This is part of why the Internet is architected as a "collective network of networks composed of Trusted Agents".
At the end of the day, you're depending on every middle box routing your packet to do the job to get it where it needs to go.
The type of Trust you're looking for is incompatible with technologically facilitated networking in a sense. The network cannot prove the trustworthyness of the network. Trust has to start outside it.
The trust we've rooted from is from the integrity of the institutions we've established. Something that has been eroded more and more over time as the Internet infrastructure has slowly been civically infiltrated to shape it into a surveillance tool by governments.
If you're feeling heartburn over this, the problem isn't the Internet per se. It's your Government, and your institutions, and for places that like to think they are populace driven, the people around you.
1. registering google.com requires it being available, and their registry and registrars prohibit registering already-registered domains
2. these registries contain the authoritative DNS records for google.com
3. when anyone wants to pull a certificate for `www.google.com`, they first need to create a DNS TXT entry called "acme-challenge.google.com" (for example)
Because of this, you know that whoever 'says' they're Google.com actually is Google.com because of how domain names work and because you see the lock icon in your browser. It's all built on trust of registries and registrars operating diligently, and it's checked by pretty much every big company watching for changes to their domains in case of malicious actions.
That's a proof of identity. I think you're fixated on the notion that somehow "identity" can only refer to some kind of legal entity, but "identity" in the WebPKI sense is "control over a domain name"--and WebPKI exists to facilitate communication of proof of that identity.
No. A PKI-less system can ensure I am communicating with one and only one party. That's all most comms need. If I want some assurance that party is who they claim to be that can be negotiated over that channel.
> a successful TLS handshake with satan.com tells you that you have connected to the actual satan.com and perhaps that it is operated by Satan, Inc (although it’s still on you to check whether it’s the Delaware one or the Kentucky one[1]). It does not, and is not supposed to, tell you whether it’s smart to sell your soul there, CA marketing materials (“users trust sites that ...”) notwithstanding.
Well we are certifying authenticity but we do it with the trust of the CAs. But if we can't trust the CAs maybe there are other authorities we can trust more, or that we at least can share the trust between several parties.
But I agree with you on the sentiment that stopping snooping technically is the easy part and this is already possible today with Public Key Pinning, DNSSEC, client certificates and so on.
But that's why I think the role of the CA should change so that the signatures actually gives some form of tangible trust that people can relate to.
> But that's why I think the role of the CA should change so that the signatures actually gives some form of tangible trust that people can relate to.
But this is a tough thing to do. The best way to do this would be to introduce a new type of certificate, that can be stapled onto web requests maybe (eg. a signature at the end of the http body), that isn't controlled or authenticated by any existing system. This would allow clients to implement this system based on merit and based on whether or not it solves problems and concerns these clients have. For example, if it's literally just EV certificate boogaloo[0], then Chrome can choose to not implement it.
But when you try to force it onto people in the form of QWACs or what have you, and have it government-mandated, this goes against the theory of 'open source' standards being adopted because they're a good standard, and instead degrades user experience by forcing client vendors to implement them regardless of their flaws.
