Hacker News new | past | comments | ask | show | jobs | submit login

If you reject the web of trust then you're saying you trust nobody (except yourself). Do you really not know anybody you trust to verify identities on your behalf? (That's a trick question because you trust the CAs).



I specifically said that I do trust a set of people. Do you imagine that my small set of trusted people will personally vouch for the authenticity of millions of certs so that I can use the web? Of course not. You imagine instead that I'll trust the next set of people and so on, and that all this transitive trust will let me trust my bank's website. But I don't trust all those random people, which leads to a clear rejection of web of trust.


But you trust the CAs right now. If we used a web of trust system, you could still trust those CAs and nobody else. That's your model that you say isn't broken. You can be happy with that. I'll be happy with trusting people that I trust.


You propose a world where CAs still exist and all the infrastructure to support them exists, and realistically everyone continues to rely on them. But in parallel, everyone will build this web of trust system so that you can prefer it when it's convenient. That seems real plausible.


There is levels of trust.

While I maybe trust someone to be a real person after I've met them in real life and ate their spaghetti to give me back the 10$ they borrowed, I wouldn't trust them to verify the identity of the IRS for me.

The current solution is that we have some third parties which follow strict rules defined by themselves and browser vendors. Everyone involved has a very good incentive to remain trustworthy, otherwise they'd be out of business.

Sadly this doesn't prevent bottomfeeders like Trustico, StartTLS and others to leech of the system while some are genuinely interested in securing everyone's communication (see LE)

The Web of Trust only works if your trust in someone is binary and understandable to a computer, otherwise the browser might tell you "This website is 35.218% Trustworthy".

HTTPS trust must be binary. Either the cert is trusted or it isn't.

It's even more fun; GPG is considering to abandon the WoT. They're switching to TOFU instead, the first time you see a key it's trustworthy, similar to SSH.


>They're switching to TOFU instead, the first time you see a key it's trustworthy, similar to SSH.

Which is horrible unless your first connection to a server is trustworthy or you have an out-of-band way to verify keys (which is why it works in SSH, and can't work on the web).


Exactly. SSH Connections are usually towards servers you have setup so verifying the keys is easy. Even then there is little concern since most of it happens in the local area network anyway.

For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.


> For PGP/GPG I feel like that TOFU is what most people are doing anyways, this change will only formalize the 0.90-quantile behaviour.

Yes, probably. Key signing parties used to be a thing. I was able to find one that happened in London in 2014 (no idea how many keys were signed, though). Unfortunately people are not aware of the concept of trust and especially of the fact they delegate trust to these third party CAs. It's just not a proper way to do security.

The TOFU model is the best thing if you actually verify the keys out-of-band. Web of trust is the best way I'm aware of to enable in-band verification. I don't claim that it will actually work in practice. But that's fine. All it means is you can't actually do in-band verification in practice. I think most people here are beginning with the assumption that in-band verification is possible and then criticising WOT for its practical shortcomings which is ridiculous.


Trust is not a binary all or nothing state. I might trust a good friend to keep a secret about my finances generally, but I wouldn't trust that friend with my ATM card and pin.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: