Re: [Gnu-arch-users] Re: Common merge request format

[mdpoole]

Robin Green writes:

> On Mon, Apr 12, 2004 at 02:24:13PM -0400, Michael Poole wrote:
>> > What a rigmarole! Let's just insert headers pointing to a direct download 
>> > for
>> > our keys. Much simpler!
>> 
>> Slightly simpler and much less useful. With a keyserver, you can
>> store a web of trust in one place.  With URLS to exported keys, you
>> cannot.
>
> Point taken. I should have realised that.
>
> So how about this instead:
>
> # A keyserver that supports hkp where the sender's key can be found
> HkpKeyserver:     subkeys.pgp.net
> OpenPgpKeyID:     B524B126

I think that works.

> The thing I notice with keyservers though, is they tend to get overloaded
> quite often, so perhaps keeping the existing Gnupg-key: line as a web
> backup would be a good thing?

I've never had a problem with keyservers being overloaded, but perhaps
my mail reader (Gnus) hides transient failures from gpg well.  For the
purposes of a standard, I would rather have Gnupg-key be optional (in
RFC 2119 terms, SHOULD or MAY rather than MUST).

> Lastly, I'm a bit confused by the whole trust thing. If it is important to
> get as much trust information as possible, why doesn't the gpg documentation
> recommend asking multiple keyservers for trust info to make sure you receive
> the maximum number of signatures? Why doesn't it recommend regularly going
> back to the keyserver to see what new trust information has been added, if
> any?

Quite often, keyservers exchange information with each other.  I
believe it is also common practice for a user to keep all signatures
for his own key, in which case it would be natural for him to upload
them to all keyservers he wishes to use.

As for why not make frequent checks on the information: Why poll when
you can receive event notification from your correspondents?  Key
signatures are relatively static for a particular key, and changes in
a particular key are not very interesting to most other users.  I
think most people would have specific reasons to update their trust
snapshot for someone else's key: being informed of an update, or
needing a higher assurance of identity for new communications.

> It's an odd thing because if you are already assuming that the person is
> who they say they are, then certainly for gnu arch purposes at least it
> seems that keyserver keys give you no new information, because they merely
> confirm your beliefs if they are signed, and fail to disconfirm your beliefs
> at all if they happen to be unsigned. Ironically, this seems to imply
> that trust information is in effect useless in this context. In a coding
> context I think trust is gained through submitting lots of good code -
> not through having a key with a strong signature path between the submitter
> and the recipient.

The web of trust does not build trust in the user, but trust that the
key belongs to the user it claims to belong to.  Trust in a user is
hard to define and hard to communicate.  Trust in a key<->user link is
just as likely to differ from person to person, but most people can
use standard terms to communicate about it: for example, how much
checking one did of the identity.  Keyservers address the problem of
trust in a key.  You are absolutely correct that they do not address
the problem of trust in a user.

Michael