On Jun 22, 2010, at 9:51 AM, Jameson Rollins wrote:
> On Tue, 22 Jun 2010 09:27:46 -0400, David Shaw <ds...@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.
David
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
