UI terminology for calculated validities

[Daniel Kahn Gillmor]

On 04/22/2014 05:40 PM, Peter Lebbing wrote:
> On 22/04/14 13:56, Hauke Laging wrote:
>> This can easily be seen from the facts that (a) the same owner can have
>> several keys and (b) there are scenarios in which you will not assign the
>> same trust to these keys.
> 
> Oh wow. I understand you can make any topic as difficult as you want if you put
> some effort into it, but are there seriously people who have different keys for
> different levels of identity verification? And do they admit they do this
> because they are sadistic, or is there some way they try to explain this away?

I can give an example where i know that the same person holds exclusive
access to multiple keys, but i grant different levels of ownertrust to
each key.  I do this because of the rules of how GnuPG interprets
signatures in the WoT, not because the keyholder has any different
policy about the two different keys:

 My friend X does a decent job at checking identities.  I wouldn't want
to rely on X's certifications directly, but i consider them useful as
corroboration from other friends.

 X has an 8-year-old 1024-bit DSA key (key "A") that has collected a lot
of certifications, and X is attached to it.

 X also has a 2-year old 4096-bit RSA key (key "B") that doesn't have as
many certifications.

 both A and B are in active use, because X is trying to transition from
A to B, but hasn't completed the transition.

 My intent is to grant "marginal" ownertrust to X, meaning that i'm
willing to consider a (key,uid) pairing as valid if it has
certifications from X and at least two other marginally-trusted friends.

If i grant "marginal" ownertrust to both A and B, then X only needs one
other friend to collaborate to get my gnupg implementation to accept
certificates that i'm not intending to accept.

X might even be in the habit of certifying keys with both A and B (this
would be reasonable for as long as X is actively using A and B, since
some of X's peers might know about and rely on certifications from A
only, and some might know and rely on B only).

I actually know several people who meet X's description (the pool of
debian developers is moving from older, weaker keys to stronger keys).

So, my current policy for dealing with this for people like X is that i
set "no ownertrust" on A, and "marginal ownertrust" on B;  i also
explain to them that if they want to make a certification that i can
rely on, they should make it with their newer, stronger key.

if GPG was closer to a contact manager, its implementation of ownertrust
could be made more sophisticated, to address this situation, by having
an abstract concept of "peers" where each peer could have an arbitrary
number of keys.  You could even approximate something like this by
matching User IDs and discounting cumulative marginal ownertrust if the
two certifications come from keys that are each bound to the same User ID.

I'm not suggesting that we make these changes right now to the gpg WoT
caluculation model, because i think there is more important work to be
tackled first, though.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140422/a9502ea5/attachment-0001.sig>