Security of the gpg private keyring?

[Grant Olson]

On 02/28/2011 08:15 PM, Hauke Laging wrote:
> Am Dienstag 01 März 2011 01:32:05 schrieb Grant Olson:
> 
>> If I upload a key to
>> pool1.sks-keyservers.net, and it tries to sync with
>> pool2.sks-keyservers.net, how do you maintain the custody chain?
> 
> Can you explain what custody chain means in this context?
> 
> My simple thought about that is that one of the keys has a newer time stamp 
> and that this one in synchronized and overwrites the older ones.
> 
> 

So if I'm only going to accept keys authorized by the owner, I need to
validate the owner.  Instead just receiving the key:

KEY => KEYSERVER-1

I now need to receive a signed copy of they key

SIGNED(KEY) => KERSERVER-1

The keyserver would then to something like:

1. Temporarily import the KEY as a TEMPKEY.

2. Verify that TEMPKEY and SIGNATURE are the same user.

3. Verify TEMPKEY with SIGNATURE.

4. Upload verified TEMPKEY into the real database.

So far not too bad, even if the current keyservers don't do any of this.

But when it tries to sync with KEYSERVER-2, I no longer have
SIGNED(KEY).  So KEYSERVER-2 won't be able to perform the above
algorithm.  It cannot verify that KEYSERVER-1 obtained the key from the
owner in the first place.

You could store SIGNED(KEY) in your database, but then you end up
performing the above algorithm millions of times when syncing, which
will eat up a bunch of time.  10 seconds per key adds up quickly.

You could say that you know KEYSERVER-1 did an initial verification, so
you don't need to, but then a malicious or misconfigured peer could get
bad data into your database.  If you decide to stop peering with
KEYSERVER-1, then how do you know which entries in your db are possibly
compromised or invalid?

Arguably a key owner could say they only wanted their key on
gingerbear.net, not the whole sks-keyserver pool.  Or more reasonably,
that sks-keyservers shouldn't sync with PGP Corp, or gnupg.org, or
hushmail, or whoever, since they didn't explicitly authorize it.  The
correct behavior here hasn't been specified anywhere.

There are probably many more issues like that tucked away once you start
to think seriously about implementing the feature properly.

-- 
-Grant

"Look around! Can you construct some sort of rudimentary lathe?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 565 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110228/151be71e/attachment.pgp>