APG

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

APG

C.J. Adams-Collier KF7BMP
Hey folks,

I'd like to start the work required to add keyserver support to APG:

http://code.google.com/p/android-privacy-guard/source/checkout

Can someone recommend a C library that can talk to sks?

Cheers,

C.J.


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: APG

Phil Pennock-17
On 2010-07-01 at 17:53 -0700, C.J. Adams-Collier wrote:
> I'd like to start the work required to add keyserver support to APG:
>
> http://code.google.com/p/android-privacy-guard/source/checkout
>
> Can someone recommend a C library that can talk to sks?

Is this for transliteration to Java?  Since Android apps are Java,
unless you're messing around with firmware images.

It's a simple HTTP call, but to a non-standard port.  It's the
/pks/lookup stuff which you'll see any of the web-forms using.  Your
search-term should be "PKS".

GnuPG is probably as good a source as any.

http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?view=markup

-Phil

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: APG

Phil Pennock-17
On 2010-07-01 at 19:33 -0700, Phil Pennock wrote:
> It's a simple HTTP call, but to a non-standard port.  It's the
> /pks/lookup stuff which you'll see any of the web-forms using.  Your
> search-term should be "PKS".

Brain-fart, I meant HKP, sorry.

> GnuPG is probably as good a source as any.
>
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?view=markup

Stands.

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: APG

John Clizbe-3
In reply to this post by Phil Pennock-17
Phil Pennock wrote:
> On 2010-07-01 at 17:53 -0700, C.J. Adams-Collier wrote:
>> I'd like to start the work required to add keyserver support to APG:
>>
>> http://code.google.com/p/android-privacy-guard/source/checkout
>>
>> Can someone recommend a C library that can talk to sks?
>
> Is this for transliteration to Java?  Since Android apps are Java,
> unless you're messing around with firmware images.

I'd check the Bouncy Castle sources to see if they already have keyserver
support if it's Java.

> It's a simple HTTP call, but to a non-standard port.  It's the
> /pks/lookup stuff which you'll see any of the web-forms using.  Your
> search-term should be "PKS".
>
> GnuPG is probably as good a source as any.
>
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?view=markup

as well as http://ietfreport.isoc.org/idref/draft-shaw-openpgp-hkp/


--
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:[hidden email]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: APG

C.J. Adams-Collier KF7BMP
In reply to this post by Phil Pennock-17
On Thu, 2010-07-01 at 19:33 -0700, Phil Pennock wrote:
> On 2010-07-01 at 17:53 -0700, C.J. Adams-Collier wrote:
> > I'd like to start the work required to add keyserver support to APG:
> >
> > http://code.google.com/p/android-privacy-guard/source/checkout
> >
> > Can someone recommend a C library that can talk to sks?
>
> Is this for transliteration to Java?  Since Android apps are Java,
> unless you're messing around with firmware images.

basically, yes.  The ndk can talk to C, so anything I can JNI-ify.

> It's a simple HTTP call, but to a non-standard port.  It's the
> /pks/lookup stuff which you'll see any of the web-forms using.  Your
> search-term should be "PKS".

cool.  http on non-standard port should be no problem.

> GnuPG is probably as good a source as any.
>
> http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/branches/STABLE-BRANCH-1-4/keyserver/gpgkeys_hkp.c?view=markup

righty-o.  thanks.

> -Phil

C.J.
--
0xBA27A83C
[hidden email]
+1 206 226 5809
Member, Collier Technologies LLC



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: APG

Jeff Johnson-12
In reply to this post by John Clizbe-3

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.

73 de Jeff

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: APG

Jeff Johnson-12

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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: APG

C.J. Adams-Collier KF7BMP
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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/sks-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: APG

Jeff Johnson-12

On Jul 2, 2010, at 12:43 AM, C.J. Adams-Collier wrote:

> 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 ;)
>

Well the issue is that hkp:// is largely just store-and-forward transport.

Once the key materiel is transported, one still has to searching for
revocations and expiries and validate the certificate all quite annoyingly
complex.

There's aso the issue of persistent keyring store on mobile device that
would be simplified by reduced packet size and retrieval of just
what was needed (self-signatures and revocations) in one transaction,
relying on the low distribution of SKS to avoid a local keyring store,
and CRL's and OCSP and all the other baggage in cert mgmt.

> 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.
>

Yep. hkp:// is working fine on my wee widdle jail bait iPhone here. I'f
hate to have to re-hack anything ;-)

73 de Jeff

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Keys size (was: APG)

Kim Minh Kaplan
In reply to this post by Jeff Johnson-12
Jeff Johnson writes:

> 1) no means to filter pubkeys. Some pubkeys are getting quite
> large, approaching 100's of Kb.

Last year I did some investigations on keys size in the SKS network and
was surprised to find some multimegabytes keys.  I only looked at the
largest and it was because of a huge embedded JPEG photo.  Keys above
100KB represented much less than 1/1000 of the keys.  The vast majority
of keys are in the 1100-1200 bytes range.
--
Kim Minh

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel