[SSL Observatory] Number of CAs

[Daniel Kahn Gillmor]

On 12/08/2011 12:44 PM, Ben Wilson wrote:
> I think this group needs to define the problem more accurately.

I outlined the problem as i saw it several years ago, which is that the
design of X.509 as a single-issuer certification is fundamentally flawed:

 http://lair.fifthhorseman.net/~dkg/tls-centralization/

I'm sure i'm not the only one to have pointed out this kind of systemic
issue.

The incentives are all wrong, and projects like the EFF's observatory
are basically documenting all the brokenness that comes from a system
with bad mechanism and bad incentives.

The EFF's Sovereign Keys proposal is an attempt to address the
incentives, as is the Monkeysphere project (which i contribute to).  The
DANE working group seeks to avoid the bad incentives in the CAs by
supplanting CAs with a single global hierarchical naming/certifying
authority in the DNS. Other projects like Convergence eschew public key
certification entirely in favor of an "is it compromised for everyone or
just me?" approach.

Interestingly, i have yet to hear of a representative of a current CA
speak out against the atrocious incentives they're faced with, embrace
any of these alternate models, or propose another fix that improves the
incentives for a CA to protect their relying parties.

A disinterested observer might be forgiven for thinking that the current
group of CAs aren't actually interested in protecting their relying parties.

A well-intentioned CA that actually cares about their relying parties
could probably contribute healthily to the promotion and adoption of a
corroborative or relying-party-driven system; and their experience doing
so might even give them a leg up on their competitors (though their
profit margins might drop).

Or, the existing CA cartel could all just die entirely if one of the
CA-less proposals gains mindshare.

"fixes" like EV and mandatory audits and arguing about the actual number
of weakest-links may be palliative, but they don't really address the
underlying issues.

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/4c90d958/attachment.sig>