Re: [perpass] Web-of-trust CAs

[DataPacRat <[e-mail]>]

On Mon, Oct 21, 2013 at 3:20 PM, Phillip Hallam-Baker <[e-mail]> wrote:

> I think you need to work out how to evaluate how trust in the Web of Trust
> is evaluated:
>
> http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00
>
> You can accuse the CA system of being 'brittle' but so is Web of Trust once
> you get past the keys that you signed directly yourself.
>
> Putting the key in a vcard only addresses one part of the problem, you need
> to know whether you have the right vcard. An attacker that can knock over a
> CA will have no trouble knocking over a simple vcard scheme either.
>
> To replace that system you have to show that what you propose as a
> replacement is actually stronger and that it is not susceptible to sovereign
> control by a single government (at minimum, some of us are not going to be
> any more happy with a group of governments acting in concert unless you can
> assure us that they will not collude).
>
>
> Where vcard is supported, it makes a fine mechanism for converting a key
> identifier to a key. It is a less good mechanism for establishing trust in a
> key which is what most of us see as the hard part.

The reasons you list are the ones behind why I included the
'Confidence' parameter in the Signed vCard spec. In fact, that
parameter is the key to the whole approach.

There is good reason to treat Bayesian analysis as a useful tool for
analyzing iffy data, such as a pool of keys that may include false
ones. Using existing terminology, any given vCard Authority can be
treated as an ad-hoc Certificate Authority. Using one's own
self-signed vCard as a baseline, web-of-trust techniques could then
determine the relative amount of trust to apply to any other Signed
vCard's data. Eg, if I trust my own vCard at a level of 100 decibans,
I trust Alice's card at 30, and Alice trusts Bob's card at 40, it's
easy to determine that Bob's card should be trusted at somewhere under
30 decibans. (Real situations would be much more complicated, such as
with multiple assertion paths; but this is still early days.)

If this approach is, in fact, workable, then once the details can be
hammered out (perhaps with Webfist-style exchanges, perhaps some
entirely different method), I'm hoping that those details can be
hidden from the end-user as well as the certificate negotiations for
https browsing are, for users who just want to get things done. Throw
in a collection of open-source key/vCard signing apps, which use
cellphone cameras and QR codes, and then, as you mention in your
PRISM-Proof trust model, even a thousand attendees at a conference
could potentially perform mutual key endorsements with just about
every other attendee. But that's still pie-in-the-sky - getting the
Signed vCard draft nailed down is the current step. Getting it nailed
down so it can, at least potentially, eventually support the
pie-in-the-sky, is why I've brought it up on this list.

So: What can I do to improve the current Signed vCard draft?



Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."