While not a solution, I'm thinking the keybase.io work is a step in a useful direction. Just a directory of accounts where you can associate a keypair with verifiable assertions that its holder controls a particular Twitter/github account and Web server and DNS.
On Apr 9, 2014 1:08 PM, "Theodore Ts'o" <tytso@xxxxxxx> wrote:
On Wed, Apr 09, 2014 at 12:17:35PM -0500, Dave Crocker wrote:
>
> The interesting premise in the suggestion is that a web of trust key
> management model is useful at Internet scale.
>
> I don't understand why anyone believes that.
The problem is that nearly all solutions to the PKI problem I've seen
to date fall into three classes, all of which have problems (which is
why there is the oft-retold joke about how any protocol which requires
a PKI is doomed).
1) The current "race to the bottom" multiple competing CA model, which
while scalable, has had some rather spectacular failures, of which
Diginotar is only one example.
2) Trust the government to run the CA ("I'm from the government, and
I'm here to help!") --- which raises questions of "which government"
and "how do you trust that someone won't invoke 'national security' as
the root password to the Constitution / Fundamental Rights" to abuse
the trust that the government would have it served as the CA?
3) The PGP web of trust model, which doesn't scale to the Internet,
but which is good enough for small communities for which high trust is
extremely important (for example, such as Debian Developers and the
Linux kernel.org keyrings).
I suspect #1 could have gotten traction as far as usage is concerned,
if the pricing model for a given level of security had been attractive
enough and if it had been sufficiently easy for mere mortals to get
x509 user certificates. But as it is, #3 has been winning out as far
as usage because the people who care enough about security to go do
the extra work are also the folks who (a) don't trust the CA's, and/or
(b) are too cheap to be willing to pay what the CA's want to charge,
and so the PGP web of trust model is quite suited for their needs.
At the end, because the use cases and the requirements for different
communities are quite different, I think the only thing that has a
chance is some kind of hybrid solution. Because questions of format
aside, the main difference between all of these schemes is who do you
put in your trusted root, and how much cerifying delegation do you
allow?
If you're the US military and you let the NSA handle all of your key
management needs, that's one answer. If you're a web browser, you
mark several dozen or several hundred CA's (depending on how you
count), and that's another answer. If you're a Linux kernel developer
and you want to get an account on kernel.org and be able to sign git
tags, you need to either be directly signed by one of four or five
trusted root individuals, or have 3 signatures by keys that are signed
by the root individuals, and that's yet another answer.
What we really need is widely deployed software which can support all
of these different use cases, and deal with the fact that there is
significant base deployed that will add resistance to switching to a
whole new certificate format. (For example, x509 certs have a large
amount of infrastructure, but so do PGP --- there are smart card and
Yubikey NEO's that support storage of private keys for PGP and ssh on
hardware tokens.) And so I might want to use one of PKI policy when
validating e-mail sent by a fellow kernel developer, and use a
different PKI policy if I'm talking to a stranger someone for whom the
only authentication path is via some "race to the bottom" cerifying
authority, and where my trust requirements might be different.
I'll note that I can mostly do that today, because my mail user agent
(mutt) supports both S/MIME and PGP. So any proposed solution should
ideally be better than what we can do today with that kind of support
(namely, adding both S/MIME and PGP into the mail client).
Cheers,
- Ted