[SSL Observatory] Number of CAs

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111208/4a6c8644/attachment.sig>