recommendation for key servers

Jean-Jacques Brucker jeanjacquesbrucker at gmail.com
Mon Jun 28 11:41:43 CEST 2021


"Hell is paved with good intention."

GDPR came from the laudable intention of limiting the power of GAFAMs 
and other data brokers, inside our private lives.

But the text maintains a confusion between personal data and private 
data. Some personal data is not and should not be private. Email could 
be one of them, if everyone used a web of trust, which would allow us to 
know more precisely who is the sender, and to fight more effectively 
against SPAM.

(NB: In addition, the text annoys small organizations more than large 
groups which have the means to circumvent it, via internationalization 
and lobbying)

I have a public email, and i would like to have a email service or 
client which may delete automatically unsigned messages, and give me the 
feature to order received email depending from a "proximity" regarding 
the WOT, or a "confidence" regarding my trustdb.

About the keystore, I imagined 9 years ago that a key server receiving a 
certificate update, not signed by its owner, could send a message to the 
owner (by default 1 time per day), in order to ask it to validate, or 
not, the modifications, before synchronizing the updated certificate, 
signed by its owner, on other key servers.

So I had to write a draft and start implementing a new MIME type for 
HTTP for these purposes, to upgrade HKP protocol :

https://github.com/Open-UDC/open-udc/blob/master/docs/rfc/HTTP_OpenPGP_Authentication.draft.txt

https://github.com/Open-UDC/thttpgpd

But unfortunately I was perhaps too shy to talk about these ideas on an 
international mailing list, and they received little echo in my French 
environment :

https://linuxfr.org/users/jbar/journaux/thttpgpd-ou-comment-openudc-a-ressuscite-le-bon-vieux-thttpd


Today WKD / WKS seems to me a good compromise for the trilemma keystore, 
and probably the best way to get the last version of 
"first-party-attested" certificates, which fresh uid / sub-keys updates 
and revocations.

But it's only today that I discovered your git repository 
https://gitlab.com/openpgp-wg/rfc4880bis and your idea of 
​​"first-party-attested third-party certifications" (1pa3pc).

I therefore apologize if I do not add anything new or interesting to the 
debate today.

----
Jean-Jacques B.


Le 28/06/2021 à 01:41, Jason Harris via Gnupg-devel a écrit :
>
> There are still SKS servers running, but several are unsynchronized, 
> including, apparently, pgp.mit.edu.  Of course, they have the same key 
> import/poisoning problems already mentioned on these lists…
>
> Here are the hockeypuck servers I could find, all synchronizing 
> properly and apparently exchanging data (minus the unwanted packets) 
> with the SKS servers that are synchronized:
>
>   * http://keys.andreas-puls.de/pks/lookup?op=stats
>   * http://keys2.andreas-puls.de/pks/lookup?op=stats
>   * http://keys3.andreas-puls.de/pks/lookup?op=stats
>   * http://pgp.cyberbits.eu/pks/lookup?op=stats
>   * http://pgp.re:11371/pks/lookup?op=stats
>   * https://pgpkeys.eu/pks/lookup?op=stats
>   * https://keybath.trifence.ch/pks/lookup?op=stats
>   * https://keyserver.trifence.ch/pks/lookup?op=stats
>
> HTH.  (Please excuse the HTML.)
>
> Sent from my iPad
>
>> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel 
>> <gnupg-devel at gnupg.org> wrote:
>>
>> 
>> Hi, we heard that sks-keyservers.net <http://sks-keyservers.net> will 
>> be depreciated
>> so we were wondering what service we should use in the application 
>> default settings
>> We I mean TDE devs
>>
>> where do we go from here?
>>
>> thank you in advance
>> BR
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210628/32529101/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA3983A40D1458443.asc
Type: application/pgp-keys
Size: 40225 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210628/32529101/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210628/32529101/attachment-0001.sig>


More information about the Gnupg-devel mailing list