local signatures: should they be importable by default in some cases?

David Shaw dshaw at jabberwocky.com
Tue Jun 22 19:29:32 CEST 2010

On Jun 22, 2010, at 9:51 AM, Jameson Rollins wrote:

> On Tue, 22 Jun 2010 09:27:46 -0400, David Shaw <dshaw at jabberwocky.com> wrote:
>> On Jun 22, 2010, at 2:36 AM, Daniel Kahn Gillmor wrote:
>>>> Can you elaborate on the usage you're describing?
>>> I'm thinking of a situation involving three people: Alice, Bob, and Charlie.
>>> Alice has met Bob in person and has verified his key.  Alice does not
>>> want this information to be publicly available (e.g., she has concerns
>>> about exposing a transparent social graph via the keyservers).  However,
>>> Alice knows and trusts Charlie and wants to put Bob in touch with
>>> Charlie, even though Charlie and Bob have never spoken before, and
>>> certainly have not verified each others' keys.
>>> Alice makes a non-exportable certification over Bob's key+userID, and
>>> mails it to Charlie (in an encrypted message, of course).  Charlie
>>> imports the certification.  Now even if Charlie does something like "gpg
>>> --send $BobsKeyID", the fact that Alice has met Bob will not be publicly
>>> exposed.
>> I'm not sure this is good behavior for Alice.  If she is concerned
>> about whether her linkage to Bob is publicly known, why would she risk
>> that by giving Charlie a signature (local or otherwise)?  Now she has
>> not only to worry about keeping her linkage secret herself, but she
>> also has to worry about Charlie keeping her linkage secret.
> I think that is a red herring.  Charlie could also make a myspace page
> that talks about what great friends Alice and Bob are.  No one can
> forcibly guarantee that all their linkages are kept secret.  Alice has
> to ultimately trust Charlie on some level that he won't maliciously make
> those linkages public.

The issue is not whether Charlie will maliciously expose Alice, but that information about Alice is under the control of someone other than Alice.  For example, say Charlie is hacked - the information given by Alice can be leaked without Charlie's consent.  Worse, since the information we're talking about here is in the form of a signature that could only have been issued by Alice (or at least someone with access to Alice's key), you get into non-repudiation issues.  Alice can deny a myspace page ("I have no idea what this guy Charlie is going on about - I've never met that Bob person").  Denying a signature is harder.

>> In the above scenario, it seems more reasonable for Charlie to locally
>> sign Bob's key himself on Alice's say-so.
> But that creates a different trust path than the one Daniel describes.
> Just as with exportable signatures, Alice's certification of Bob is
> different in Charlie's eyes that Charlie's own certification.  Charlie
> wouldn't (or shouldn't) make an exportable signature of someone whose
> identity he hasn't verified, so why should he make even a local one?

That's one of the main uses for local signatures - the "I believe this key is valid for me, but I'm not willing to say so in public for everyone" case.  That might be because of privacy, or it might be because Charlie is satisfied that the key is valid, but doesn't have enough proof to be willing to have other people rely on that.  This case is actually quite common.

For example - I've been working with Werner on GnuPG stuff for almost 10 years now.  I'm pretty sure his key is his by now ;)  Would I sign his key?  No, I wouldn't - because I can't perform the appropriate checks.  Would I sign it locally?  Sure.  Signing locally only makes a commitment to myself.  Everyone is free to make local signatures to whoever they like, on whatever criteria they like.  That's what's so wonderful about local signatures - they don't hurt anyone but the signer, so if you believe that the key is valid, lsign away.

In the case of Charlie using Alice's local signature, that's a strange use - a signature that was made with the express setting that it shouldn't be public, made into something public.  You can often stretch and bend a standard into doing these sorts of things, but it usually hurts.  Note, for example, that not all OpenPGP programs will even let you do this, so it immediately fails as soon as someone isn't using GnuPG.


More information about the Gnupg-users mailing list