looking up pgp keys

[Tim Prepscius]

Yes.. I'm thinking about something similar to the idea implicit in this email.

Basically, I would request that mail servers maintain a "good" list of pgp info.
(and I, myself, my mail-server, would run one)


At random times, or perhaps non random times, Bob's client would
verify that the information the mail server broadcasts is correct.
And the broadcaster (the mail server) would verify that the
information in the global servers is correct against what I know.



It would be incredibly useful to do this through a Tor/Proxy
configuration, so that I know that I am not MITM.  Or at least I know
that the NSA has gone through the trouble of MITM *every* key server.



There are still problems of course, like, if Bob doesn't check
periodically his own broadcast information, there are windows of
opportunity.  But I think this can be fixed if different mail servers
verify each other.  If there are changes, notify e-mail sender (before
actually sending) that the pub key has changed, "Joe's public key has
changed, the public key broadcast SuperMail.com is the same as stored
by MIT and by 3 other mailservers.  Do you want to accept this
change?"


I guess I am attempting to establish a web of trust via servers
checking each other and clients checking servers.



I would also fashion it, so that look ups are all done exactly, and
there is no "listing."  I'm actually sort of surprised there is any
listing mechanism.



Still thinking, but overall I think this is the plan.  Maybe not.  I
need a "machine compatible" method of finding someone's public key.

-tim


On 9/11/13, jbar <jeanjacquesbrucker at gmail.com> wrote:
> 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
>