sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] APG


From: C.J. Adams-Collier
Subject: Re: [Sks-devel] APG
Date: Thu, 01 Jul 2010 21:43:50 -0700

For the time being, I think it would be wisest to stick with an hkp://
capable client library in C.  This may mean libwww and http 1.0.  I
don't want to get into an overhaul of sks just to make an android app
function correctly ;)

As the app matures, it may make sense to extend sks to meet the demands
of the client.  But we don't have any demands yet.

Thanks for all of your responses!

C.J.


On Fri, 2010-07-02 at 00:33 -0400, Jeff Johnson wrote:
> 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
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/sks-devel

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]