4 ms·

The problem is that we are forced to trust a particular CA because the company we are dealing with chose to buy their certificate from that particular CA. Whil

by ra 16y ago

The problem is that we are forced to trust a particular CA because the company we are dealing with chose to buy their certificate from that particular CA. Whilst PKI provides solutions for this [1], they are not really practical in SSL. In any case, that's not how it works in the real world. In the real world, Achmed's uncles do trust Achmed, and might well trust him to validate the identity of a business partner. In essence, that's the logic behind PGP. What if SSL could be enhanced to allow PGP verification of counterparties? That way anyone could become the equivalent of a root CA, but your value would only be as good as your reputation / integrity. Trusted entities, like the governments, could vouch for the keys of their agencies - or other governments. Friends and Family could vouch for each others keys, businesses for their partners... etc etc. Unlike PKI, PGP would enable counterparties to establish their identiy by having many validating partners (paid and unpaid), as opposed to the one single root CA that is available. As well as bringing the source of trust closer to the relying party (really, I live in Australia, who the hell is Comodo anyway?), the network of trust that would result could be articulated in the browser in many different ways. eg: 25 of your friends and 600 businesses agree that this is the identity of Visa. Twenty years ago this wouldn't have worked. But today, we could use the root CA SSL system to bootstrap a network of trust that becomes independent of the old hierarchy. I hope all that makes sense. [1] eg: certificate revocation, or even the user removing the root CA from her own key store.

ciupicri 16y ago
Your proposition is indeed interesting, but let's not forget about the herd mentality. If a more technical savvy user will vouch for a certificate, tens of less technical users might follow and then you'll have the wrong impression about that certificate.
- T_S_ 16y ago
  You mean like Madoff?
  - ra 16y ago
    More like LinkedIn
    - T_S_ 16y ago
      Interesting. What's your objection to LinkedIn? Or are you just making a reference to the herd?
- ra 16y ago
  Sure, but if that vouch turns out to be false, then less people will trust that person as a trust factor next time. It becomes a self organising system. Highly trusted individuals / companies might even start selling subscriptions to their trust recommendations. The big difference is that you gain the right to freedom of choice, as opposed to being beholden to a root CA appointed by other people.
axusgrad 16y ago
botnets could vouch for their customers?
- ra 16y ago
  PGP has always included provisions for revocation. The RFC [1] isn't exactly light reading, but this overview [2] is helpful. [1] http://tools.ietf.org/html/rfc4880 http://tools.ietf.org/html/rfc4880 [2] http://www.openpgp.org/technical/whybetter.shtml http://www.openpgp.org/technical/whybetter.shtml
- gcb 16y ago
  If someone you trust ever vouched for the nods there, yes.
mleonhard 16y ago
The problem is that regular people don't understand the PGP network of trust. And even people who do understand it rarely expend the effort to make it work properly.
- Kadin 16y ago
  That's a challenge for whoever is designing the interface. It doesn't have to be that complex in terms of appearance to a casual user. The first time they encounter a site, the software could say "You haven't visited this site before. The following people believe that it is valid: John Doe, Jane Fox, Sam Smith. Do you want to continue to it?" (Where John, Jane, and Sam are members of your social network or at least your addressbook.) On subsequent visits it could say something (via a non-modal interaction) like "This is the same site you have visited 52 times before, most recently on Tuesday." You could have some additional validation when it looks like the user is in the process of submitting something sensitive, like an SSN or a credit-card or bank account number. There are a lot of possibilities in that vein and I've seen a lot of proposals to handle trust like this; you don't try to turn trust into some sort of absolute metric, because that's not how trust works in the real world. The problem with PGP's network of trust is that it tries to boil down very complex relationships into an integer value. It's not just that the interfaces suck, the concept doesn't mesh with how most users think.
  - JoachimSchipper 16y ago
    Ok, so how many of your family members do you trust to properly validate visa.com?
ay 16y ago
"The problem is that we are forced to trust a particular CA because the company we are dealing with chose to buy their certificate from that particular CA." That's why maybe interesting to make the current approach symmetric: Create a "CA assurance" layer, which would consist of a business entities who would sell the CA reputation validation services. The product of their business would be the list of CAs to trust (to be realtime-updated into the browser), they would collect a monthly fee, and would be insuring their users up to amount of $$$ in case one of the CAs on their list screws up (or not, depending on their SLA). This would create a system with two components - on one side "CA reputation services", on the other hand - "CAs" - watching each other and being vigilant, in an effort to not lose their respective customers. As soon as there is no monopolies, I think this approach could work - and relieve the browser vendors off making the tough decisions. They can still keep the list of root CAs, but just have them all "off" by default - so that the tech-savvy could make their own decisions, and publish their own lists, if they want to. The "CA assurance" layer would actively fight the attempts to create the monopoly in the CA side (because then they'd be out of business) - and the CAs should not be able to affect the "CA assurance" segment since the entry barrier there would be quite low. This approach still does not solve the "CA sunrise" problem - making it more difficult for a new CA to enter the market. (But maybe that is a good thing ?) EDIT: however, what this approach would address is the "local trust" issue: the said mom and pop shop can very well be trusted by the locally-significant CA assurance service, and not bother with the worldwide paperwork at all.
camiller 16y ago
"Trusted entities, like the governments" comedy gold right there...

by ra 16y ago

ciupicri 16y ago

Your proposition is indeed interesting, but let's not forget about the herd mentality. If a more technical savvy user will vouch for a certificate, tens of less technical users might follow and then you'll have the wrong impression about that certificate.

T_S_ 16y ago
You mean like Madoff?
- ra 16y ago
  More like LinkedIn
  - T_S_ 16y ago
    Interesting. What's your objection to LinkedIn? Or are you just making a reference to the herd?
ra 16y ago
Sure, but if that vouch turns out to be false, then less people will trust that person as a trust factor next time. It becomes a self organising system. Highly trusted individuals / companies might even start selling subscriptions to their trust recommendations. The big difference is that you gain the right to freedom of choice, as opposed to being beholden to a root CA appointed by other people.

axusgrad 16y ago

botnets could vouch for their customers?

ra 16y ago
PGP has always included provisions for revocation. The RFC [1] isn't exactly light reading, but this overview [2] is helpful. [1] http://tools.ietf.org/html/rfc4880 http://tools.ietf.org/html/rfc4880 [2] http://www.openpgp.org/technical/whybetter.shtml http://www.openpgp.org/technical/whybetter.shtml
gcb 16y ago
If someone you trust ever vouched for the nods there, yes.

mleonhard 16y ago

The problem is that regular people don't understand the PGP network of trust. And even people who do understand it rarely expend the effort to make it work properly.

Kadin 16y ago
That's a challenge for whoever is designing the interface. It doesn't have to be that complex in terms of appearance to a casual user. The first time they encounter a site, the software could say "You haven't visited this site before. The following people believe that it is valid: John Doe, Jane Fox, Sam Smith. Do you want to continue to it?" (Where John, Jane, and Sam are members of your social network or at least your addressbook.) On subsequent visits it could say something (via a non-modal interaction) like "This is the same site you have visited 52 times before, most recently on Tuesday." You could have some additional validation when it looks like the user is in the process of submitting something sensitive, like an SSN or a credit-card or bank account number. There are a lot of possibilities in that vein and I've seen a lot of proposals to handle trust like this; you don't try to turn trust into some sort of absolute metric, because that's not how trust works in the real world. The problem with PGP's network of trust is that it tries to boil down very complex relationships into an integer value. It's not just that the interfaces suck, the concept doesn't mesh with how most users think.
- JoachimSchipper 16y ago
  Ok, so how many of your family members do you trust to properly validate visa.com?

ay 16y ago

"The problem is that we are forced to trust a particular CA because the company we are dealing with chose to buy their certificate from that particular CA." That's why maybe interesting to make the current approach symmetric: Create a "CA assurance" layer, which would consist of a business entities who would sell the CA reputation validation services. The product of their business would be the list of CAs to trust (to be realtime-updated into the browser), they would collect a monthly fee, and would be insuring their users up to amount of $$$ in case one of the CAs on their list screws up (or not, depending on their SLA). This would create a system with two components - on one side "CA reputation services", on the other hand - "CAs" - watching each other and being vigilant, in an effort to not lose their respective customers. As soon as there is no monopolies, I think this approach could work - and relieve the browser vendors off making the tough decisions. They can still keep the list of root CAs, but just have them all "off" by default - so that the tech-savvy could make their own decisions, and publish their own lists, if they want to. The "CA assurance" layer would actively fight the attempts to create the monopoly in the CA side (because then they'd be out of business) - and the CAs should not be able to affect the "CA assurance" segment since the entry barrier there would be quite low. This approach still does not solve the "CA sunrise" problem - making it more difficult for a new CA to enter the market. (But maybe that is a good thing ?) EDIT: however, what this approach would address is the "local trust" issue: the said mom and pop shop can very well be trusted by the locally-significant CA assurance service, and not bother with the worldwide paperwork at all.

camiller 16y ago

"Trusted entities, like the governments" comedy gold right there...