WoT Proposal: implicit transitive self-certification

[Daniel Kahn Gillmor]

People undergoing key transitions or who hold multiple keys present some
unusual challenges for calculating key+userid validity through the WoT.

For example, a common case during key transtion is:

 0) You believe that user U holds key old key X,

 1) You find another key Y with user U's identity associated.

 2) The <Y,U> key+userid binding is certified by X

this scenario seems to correspond to a key transition or some other
circumstance where a user holds multiple keys.  Unless the user has
explicitly stated "Do Not Trust" ownertrust for key X, reasonable
automated pathfinding tools could treat Y,U as having full calculated
validity as well, since people presumably know their own identity.

My proposal is:

 If

 (a) key+userID binding <X,U> has full calculated validity, and
 (b) X has any ownertrust setting (including unassigned) other than "Do
Not Trust", and
 (c) key Y has a binding over the same User ID U certified by X

 Then

   treat <Y,U> as having full calculated validity.

I'm currently calling this proposal "implicit transitive
self-certification", though i welcome suggestions for a catchier name.

Does this sound like something that GnuPG would consider adopting in its
WoT pathfinding algorithms?

Are there problems with this proposal that i am not seeing?  Any cases
where it could be dangerous or insecure?

	--dkg

PS: Note that this proposal does *not* modify ownertrust in any way; it
only modifies the calculated validity of matching User IDs.  Note also
the equivalence to introducing a new subkey -- a new subkey would be
effectively treated as bound to the user ID in question already; this
proposal simply allows people to transition to a new primary key (which
is useful, for example, for people with old/weak primary keys)

PPS i note also that there would need to be some recursive limit in
practice.  Conservatively, i'd propose no recursion be allowed.  That
is, if I find <Z,U>, certified by Y, I should not treat Z,U as having
full calculated validity.  This might complicate implementation.

-------------- 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/4aa9cb01/attachment-0001.pgp>