Re: [Sks-devel] APG

[David Shaw]

On Jul 1, 2010, at 11:36 PM, Jeff Johnson wrote:

> 
> On Jul 1, 2010, at 10:55 PM, John Clizbe wrote:
>> 
>> as well as http://ietfreport.isoc.org/idref/draft-shaw-openpgp-hkp/
>> 
> 
> 
> Which reminds me ...
> 
> There are _LOTS_ of advantages to hkp:// lookup through
> SKS keyserers: easy to implement, reliable and portable,
> latency measured in minutes, all astonishingly wonderful.
> 
> But there's a few negatives with hkp:// used for certificate
> retrieval too.
> 
> 1) no means to filter pubkeys. Some pubkeys are getting quite 
> large, approaching 100's of Kb. E.g. here's two fingerprints
> I routinely use for retrieval testing (because the pubkeys
> are huge:)
>       0xD5CA9B04F2C423BC
>       0xc2b079fcf5c75256
> 
> 2) hkp:/// pre-dates HTTP 1.1 and persistent connections.
> The persistence would be useful for validating the certificate.
> Alternatively, some means in the hkp:// query to batch
> retrieve sont only a designated pubkey, but also
> pubkeys that have signed the designated pubkey.
> 
> 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.

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.

David