recommendation for key servers

[Jean-Jacques Brucker]

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