Re: [Sks-devel] Requesting your thoughts on a web of trust scheme

[Daniel Kahn Gillmor]

I'm not sure this is OT on sks-devel, unfortunately, so it'll be my last
post on-list on this thread.  Some comments below.  Suggestions for a
better place for further discussion are welcome.

On 12/08/2011 05:30 PM, Daniel F wrote:

> I would like to request your thoughts and comments about a trading web
> of trust scheme proposal I've written up. Please give it a look at
> your leisure and let me know what you think.
> 
> http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal

I see two main ways the proposal could use improvement as presented:

 0) increase clarity and precision of critical terminology, and

 1) reuse existing components and standards properly

There are a few minor technical corrections at the end.

Clarity and precision of terminology
------------------------------------

The document seems to presume that there is a single thing called
"trust" that defines a relationship between two people, and that it is a
linear scale.  This simply isn't the case in the real world, and
attempts to codify it as such will run into severe problems.

For example, i might trust Alfred to proofread anything i write in
english and improve it in the process.  But I trust Betty to write a
critical piece of software that I rely on for system administration.
Betty can't form an eloquent english paragraph to save her life, and
Alfred couldn't program his way out of a paper bag.  Charles, meanwhile,
is remarkably simple-minded but has a way of interacting with children
that makes them happy.  He's an excellent babysitter, as long as nothing
too unexpected happens.

Who do i rate higher in "trustworthiness"?

Your "Operationalizing the trust values" section suggests that you want
to tie trustworthiness to something like "amount of money i would lend
this person".  If this is the entire goal here, why not call it a
"distributed credit-rating system", and avoid all the confusion around
the deeply non-linear concept of "trust"?  Even if you're working with
the comparatively simple concept of financial credit, it's still
troublingly unclear because not everyone has access to the world's
per-capita GDP.  If John has $1,000 to his name, he won't be willing to
consider lending much of it to anyone.  But billionaire Mary might be
willing to risk much more than 100% of the per-capita GDP by lending it
to many different people.  Should the "trust" ratings John declares vary
from Mary's because of their different levels of wealth?

Adding "transitive trust" into the picture only further complicates
things, even if "trust" is relegated to simple "credit-worthiness".
Multi-stage "transitive trust" is even worse from a comprehensibility
standpoint.

Additionally, the proposal also seems to sometimes use the term "key"
when it means "keyholder".  This kind of metonymy is common in everyday
use, but a technical proposal is no place for sloppiness.  Keys are
particular information-theoretic constructs that have very different
properties from the entities who use them.  Understanding which parts of
your proposal are vulnerable to problems with the math and which parts
are vulnerable to problems with the humans requires more rigor.


Reuse existing standards properly
---------------------------------

Your proposal suggests using the OpenPGP User ID as a free-form field to
encode arbitrary data.  Please don't do this.  There currently exists a
reasonable expectation that a User ID does in fact Identify the User of
the key (whether it's a human, an organizational role, or a service).
If a search of keyservers by User ID field returns a bunch of garbage
about some trust metric, that will be quite annoying.

So what should you use?  OpenPGP already actually has a reasonably
well-defined "trust signature" subpacket:

 https://tools.ietf.org/html/rfc4880#section-5.2.3.13

But the use of trust here is in the sense of "trusted introducer"
meaning.  That is, the only type of "trust" they care about is "am i
willing to rely on the identity certifications made by this person?"
Even with this reasonable and scoped definition of "trust", this form is
not in wide use today.  This should give you some pause as you think
about the likelihood of adoption of the proposed scheme.

Since you probably don't want to use the existing trust packet you
probably want to make use of OpenPGP's standardized notation format:

  https://tools.ietf.org/html/rfc4880#section-5.2.3.16

Declare a notation, and define its meaning as parsimoniously as
possible.  The rater could make signatures including this notation over
the rated person's primary key directly since the proposal doesn't seem
to care about "real-world" identities.

In your FAQ, I note that you prefer a "forward walk" over a "reverse
walk" through the graph (though i see no justification for this
preference).  If you think it's really important to place these objects
on the rater's key instead of the ratee's key, you would be better off
defining a novel User Attribute (there is a range dedicated to private
and experimental use so you don't need to petition the registry before
you have something working) and self-signing it with the appropriate
information.

  https://tools.ietf.org/html/rfc4880#section-5.12

Another approach would be to make a key-only signature over one's own
primary key; but that would probably be a mistake, since RFC 4880
recommends that implementations should consider a certification over a
given object to supersede all the earlier ones.

As for your concerns about the GnuPG UI: Yes, you'll need to work on
changes to the UI.  If you're looking for something that normal humans
will even begin to consider adopting, you probably don't want the GPG UI
anyway.  The concept you seem to be proposing (credit-rating in
particular) is significantly different from the concept GPG's key
management handles best (identity), so you'll be better off crafting a
UI that relays these concepts to the user directly.

To be clear: I don't think it's a good idea to clutter the existing User
ID space with this proposal as it stands.


some specific technical notes
-----------------------------

0) "the stock gpg client requires an email address for a UID" -- this is
not true.

1) "To this end, it is also proposed to have a minimum key length and
type requirement for this first version (4096 bit RSA suggested), to
make it computationally costly to create bogus identities in the
system." -- this does not follow.  Creating new 4096-bit RSA keys is not
a high computational burden.

2) "...Since the service by design holds private keys of a great number
of users..."  Please do not encourage or condone the creation of secret
key material silos in a system that is claimed to be in control of its
users.  If this is going to be implemented properly, the secret key
material should remain with the users, not in a service hub.


I hope this critique is useful,

        --dkg

signature.asc
Description: OpenPGP digital signature