On Mon, Oct 21, 2013 at 3:20 PM, Phillip Hallam-Baker <[email protected]> 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." _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
