Re: [Sks-devel] APG

[Jeff Johnson]

On Jul 2, 2010, at 12:10 AM, David Shaw wrote:

>> 
>> Both of the above issues could be addressed by extending
>> the hkp:// query syntax a bit to include more sophisticated
>> queries.
> 
> I've often thought of SKS as really two distinct pieces: the SKS gossip 
> protocol and database for key storage, and the HKP interface for making 
> database queries to find and retrieve keys.
> 

I'd agree. But the hkp:// was designed (and much of OpenPGP) for securing 
e-mail ala S/MIME.

What is remarkable (to me) is how robust the hkp// interface is, similarly 
OpenPGP 2440/4880
packets. X.509 is the pits (I'm slogging through a OpenPGP Apple CDSA 
implementation
atm. Wotta bleary mess even if the are a few artful implementations)

> Given this, rather than extend HKP, I wonder if a better solution might be to 
> implement a LDAP interface to the existing backend.  LDAP already supports 
> all sorts of interesting queries (including "keys that have signed key 
> such-and-such", "find me the primary key that has subkey such-and-such", and 
> "the most recent non-expired key from user such-and-such"), and persistent 
> connections.  It's possible to add this to HKP, of course, but it sort of 
> feels like reinventing LDAP.
> 

Eeek! LDAP is wonderful for certain things, but the implementations are
really really hard.

But mainly I was looking for extending hkp:// to
   1) reduce the size of the returned blob. Say only POSITIVE CERTS and 
revocations.
   2) avoid re-connects by either HTTP 1.1 or a adjacency level if the trust
   graph was to be traversed.

LDAP likely (haven't looked) returns the full pubkey with all signatures even
if some of the search can be done on the server.

OTOH, perhaps leaving well enough alone in hkp:// is wisest. I'd hate
to see hkp:// KISS morph to LDAP complexity.

73 de jeff