looking up pgp keys

[jbar]

On Mon, 9 Sep 2013 20:40:42 -0400
Tim Prepscius <timprepscius at gmail.com> wrote:

> Why aren't the results from the http://pgp.mit.edu:11371 signed with their key?
> They have an http request but there is no way I can tell if I've been mitm-ed.
> 
 Just to say, as the develooper of thttpgpd/ludd[1], that such key
 server may sign its result using a new MIME-type
 "multipart/msigned"[2].

 You may try for example :
 $ curl -v -H "Accept: multipart/msigned" \
 "http://domesticserver.org:11371/pks/lookup?search=jbar&search=loubov&op=get"

 But that doesn't change the fact that, as Phil said, the main
 mechanism to trust a key is to use the OpenPGP WoT.
 And so if your certificate isn't connected to myself, the signature
 shouldn't be enough for you, to trust that the answer is coming from
 me, or from my own keyserver.

 By the way, if I said "There is no bad or malicious certificates on my
 key server" and you trust that and myself. Then such signed key server
 results may help you, even if it isn't as strong as checking the
 OpenPGP WoT of received certificates.

 Note: thttpgpd/ludd have yet no synchronisation mechanism
 implemented, even if I run daily a script that send updated key on
 the main SKS pool[3].

[1]:https://github.com/Open-UDC/thttpgpd
[2]:https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt
[3]:https://github.com/Open-UDC/thttpgpd/blob/master/scripts/check_pks_add_logs.daily.sh

> 
> I should be able to ask each server I request from, the public key of
> the other servers, and then check the signature of each against each
> other
> 
> ??
> 
> Is this implemented and I'm missing it somehow?
> 
> -tim
> 
> 
> On 9/9/13, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> > On 09/09/2013 02:12 AM, Phil Pennock wrote:
> >
> >> Note that most recipient mail-servers will not also run PGP keyservers,
> >> If you want that approach to take off, I suggest figuring out a DNS
> >> scheme for asking for SRV records _mail-openpgp._tcp.example.org or
> >> somesuch.  The details don't matter.
> >
> > If you do something like that, please don't make up your own scheme.
> > The current proposed draft for this kind of lookup is from Paul Wouters:
> >
> >   https://tools.ietf.org/html/draft-wouters-dane-openpgp
> >
> > If you are working on implementing this sort of scheme, and you evaluate
> > your threat models sensibly like Phil is suggesting, and you think you
> > see a problem with it, or a way it could be improved, you should mention
> > it to Paul.  i'm sure he would be happy to get feedback from
> > implementors for a revised draft if it is necessary.
> >
> > Regards,
> >
> > 	--dkg
> >
> >
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: </pipermail/attachments/20130911/b12ece35/attachment.sig>