WoT Proposal: double-counting suppression

Daniel Kahn Gillmor dkg at fifthhorseman.net
Tue May 4 00:59:18 CEST 2010


This is another proposal for tuning WoT pathfinding algorithms in the
face of the possibility that people hold multiple keys.  In particular,
it is concerned with assignments of marginal ownertrust and multiple
keyholders.

My concern is with the case where User U holds two keys: X and Y.

I know U, and have verified that she holds both of these keys.

I also believe that U's certifications are useful, but i am not willing
to rely on them for certificate validation unless they are corroborated
by two other similar keyholders.  This corresponds to "marginal" ownertrust.

Let's assume there is another key, Z, with an associated user ID V.  If
U has certified <Z,V> with both X and Y, those should not count as
independent corroborations.

My proposal is:

-------------
 If

  (a) <Z,V> is certified by two keys X and Y, and
  (b) the user has assigned marginal ownertrust to both X and Y, and
  (c) there exists any User ID U such that i believe <X,U> and <Y,U>
both have full calculated validity,

 Then

  The certifications by X and Y over <Z,V> are treated as a single
certification for the purposes of corroboration.  That is, if three
marginally-trusted certifications are required to reach full calculated
validity for <Z,V>, then two more certifications by other keys with
"marginal ownertrust" are needed, not one.
-------------


The name i'm currently using for this proposal is "double-counting
suppression", though i'm happy to entertain suggestions for a catchier name.

What do folks think?  Is this something that GnuPG might want to adopt?
 Are there dangers or problems with the proposal?  Are there other ways
to accomplish the same goal?

	--dkg

PS I'm not sure how this interacts with variant certifications -- for
example, if one certification contains a subpacket that other ones do
not; perhaps this is not relevant.

PPS thinking about this more radically, it seems possible that users
might really prefer to assign the equivalent of "ownertrust" to User
IDs, and not to keys, since we actually rely on named real-world
entities to make good certifications.  Interestingly, the only reference
to anything like "ownertrust" in the OpenPGP spec is trust signatures,
which are actually assigned to a key+UserID combo, so the choice of how
to represent this information is implementation-specific.  There are
still issues around the root(s) of trust in such an arrangement (e.g.
"ultimate" might still need to be assigned key-wise), though.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100503/ed8cd1f0/attachment.pgp>


More information about the Gnupg-devel mailing list