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

[Jameson Rollins]

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.

I think the situation Daniel points out is one of the better usages for
local signatures, and probably the main reason for having them in the
first place.

> 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?
According to your logic, everyone should just sign the keys of everyone
they wish to have trust paths too, whether they've actually met them or
not, just based on the fact that others they know have signed their
keys, rather than relying on the calculated validity through known trust
paths.

The point of the scenario that Daniel is pointing out is that Alice and
Charlie can use OpenPGP to *cryptographically* verify Bob's identity,
without Charlie having to make certifications he otherwise wouldn't
make.

jamie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: </pipermail/attachments/20100622/c04504c3/attachment.pgp>