lookups by fingerprint and long keyid (was Re: duplicate keyid survey results)

[Jason Harris]

--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 10, 2002 at 02:28:00PM -0500, David Shaw wrote:
> On Sun, Mar 10, 2002 at 12:34:14PM -0500, V Alex Brennen wrote:

> > I checked code into CVS that will allow CKS to support HKP style=20
> > queries by the 64 bit key ID, the full 128 bit v3 fp, or the full
> > 160 bit V4 fp.  This feature will be available in the next release.

> I think this is a good thing except for one problem.  From the
> perspective of a program that is making a call to a keyserver via HKP,
> it has no way to know if the keyserver is pksd, CKS, or something
> else.  Since only CKS supports this syntax, there is a problem.  I
> guess it could try twice and fall back to the 32 bit key id if the
> keyserver returns an error with a fingerprint lookup.

Those are all valid concerns.  Encryption programs will have to be
modified accordingly, of course.  However, even without support for
the extensions in encryption programs, we can still benefit by having
the features available for browser-based lookups.

FWIW, it should be _very easy_ to add long keyid lookups to pks, iff we're
all willing to get back a list of keys matching the corresponding _short_
keyid.  Having pks return only matches by long keyid would require more
work, but should also be possible.  (Remember, there are 81 and 5 keys by
duplicate long and short keyids, respectively, and a maximum of 3 keys with
the same short keyid (0xDEADBEEF).)

Having pks support lookups by fingerprint would require the addition of
a new Berkeley DB Btree or Hash database file.  This should be a
straightforward (but non-trivial) programming task.

(Also, only on the pgp-keyserver-folk list, I previously announced a
proof of concept Perl program that allows lookups by fingerprints.  The
interface isn't HKP and some scripting would be required to keep the
fingerprint and keyid data current, but all sorts of improvements are
possible.  (At any rate, I'm glad to have finally gotten some positive
(though indirect) answers about the _perceived_ need for new types of
key lookups.))

> Something to be discussed in the RFC, I think. :)

As features which are optional to implement, I feel that they can go
in immediately.  I have already needed and performed lookups (mostly
non-keyserver greps on pgpring(1) output) by fingerprint and long keyid.

--=20
Jason Harris
jharris@widomaker.com

--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8i9OdSypIl9OdoOMRAiC1AJ9B/BHevtQR953ghkmoemiIjuqhfQCeJmq4
B+WpbY6x5/eslLlhURKVIHk=
=qEq/
-----END PGP SIGNATURE-----

--UugvWAfsgieZRqgk--