Key server Q

[Simon Josefsson]

David Shaw <dshaw at jabberwocky.com> writes:

> On Mon, Aug 05, 2002 at 12:41:49PM +0200, Simon Josefsson wrote:
>> Would it be possible for the keyserver code in GnuPG to not only send
>> the KeyID to the keyserver plugins, but also the user ID?
>> 
>> A solution could be to allow plugins to send back
>> 
>> OPTION uid
>> 
>> to GnuPG, which would make GnuPG then use key lines such as:
>> 
>> 12341234 foo at bar.com
>> 
>> The reason is that I'd want the DNS keyserver client to lookup
>> (foo.bar.com, IN, CERT) in a case like this.
>
> I thought we had discussed using CNAMEs for this sort of thing
> (foo.bar.com. CNAME 12341234.bar.com.) ?  Or is this as a backup to
> that method?

The problem is that if I get 12341234 from GnuPG I don't know the
"bar.com." part, so I don't know where to look.  I think it would be
nice to not have to specify a specific DNS key server zone and have
things work anyway.

> The difficulty here is that GnuPG very often knows the user ID or
> the key ID, but not both.
>
> For example, during a --recv-keys GnuPG knows the key ID but does not
> know the user ID since the key is not present yet, so there is no way
> to look it up.  During a --search-keys, GnuPG knows the user ID but
> not the key ID, also since the key is not present yet.

OK.

> It is possible to send the user ID during a --refresh-keys and a
> --send-keys.  In those cases, the key is present during the keyserver
> operation, so the user ID can be looked up and provided to the
> keyserver plugin.  Would that still be useful to you?

I don't think so, I was thinking of the cases where you have no DNS
zone configuration and don't have the certificate.

> Which user ID should be used for keys with multiple user IDs?  The
> primary one?  All of them?
>
>    12341234 foo at bar.com foo at bar1.com foo at bar2.com foo at bar3.com ...

A DNS plugin would use the primary one, I think, but I guess other
plugins might be able to make use of the others as well.

>> An ugly idea for doing this would be to have the OpenPGP message
>> reader look for From: lines before the actual OpenPGP header, and
>> snarf the address.  Of course, there is no guarantees that there is a
>> From: header or that it corresponds to the actual OpenPGP originator,
>> but it would be Good Enough for many common cases, I think.  Perhaps
>> there is a better way?
>
> Unless the message is signed or has some other way of giving the key
> ID, this might be the best way to do it (and then pass the from email
> address to --search-keys).  It would be nice if there was one official
> version of the many different "x-pgp-keys:" headers, so it could be
> easily parsed.  Perhaps we should write one.

The KeyID isn't enough for the situation I'm thinking about here,
where you want to retrieve the certificate from the originator's own
preferred server.