On 12/08/2011 01:23 PM, Patrick Patterson wrote: > Far better that the Relying Party exercise some form of discretion and > responsibility.
I completely agree with you that it should work this way, except that in a single-issuer certification model (e.g. X.509), you are bound by the choices of the administrators of the sites you want to visit. What if i don't consider Entrust particularly trustworthy or reliable? If i want a secured connection to https://www.carillion.ca/ i have to rely on them to authenticate the connection. So i could "exercise discretion" and i wouldn't be able to work with your organization. Lots of web sites use X.509 certificates granted from GoDaddy (a disreputable company if i've ever seen one) simply because they're cheap and folks are short on cash these days. Other (major) organizations rely on a CA chain where the ultimate root uses a 1024-bit RSA key issued 12 years ago and is preposterously claimed to be valid until 2030. Should i simply refuse to visit the web sites who've made the decision to use these CAs? The mechanisms don't exist for relying parties to cleanly censure misbehaving CAs without losing secured access to big sections of the web themselves. And for those few who are willing to take those drastic measures, how can they actually effect change in the existing system? My argument is that the incentives which underlie the entire system are deeply flawed if you care about relying parties at all. And if the Relying Parties get no protection, then even the Subscribers are getting screwed. They're not screwed by their chosen CA directly (who they have a contract with), but by the overall system, because all their customers are (have to be) willing to rely on every shady CA out there (50 or 350 or 650 of them) to not provide an adversary a bogus certificate to intercept their communications. In short: telling people "eat healthier food" when the only affordable meal for miles is a greasy, stale hamburger is not a realistic demand. Regards, --dkg
signature.asc
Description: OpenPGP digital signature
