Mailing List Archive

On 5/27/19 4:39 AM, Phil Pennock wrote:
> hkps is limited because Kristian doesn't hand out certs to anyone who
> shows up with a new keyserver and asks; he tends to do so with people
> who've been around and part of the community, because of the fairly
> obvious problems with assuming TLS is buying you anything when entirely
> unknown-to-others folks run the servers. Kristian takes a lot of flak
> for not giving people the power they want just because they ask for it.
>
> With the various problems of SKS today, I tentatively suggest that not
> defaulting to the HKPS pool and choosing a different target for the
> keys.gnupg.net CNAME might be beneficial.

Adding some meta-info to this one. In addition to the above-mentioned
concerns about new actors (in particular those not part of strong-set),
it is also a question of capacity of the keyservers, so hkps pool is
requiring load-balanced setup with minimum of 3 nodes on modern hardware
(e.g a node today requires a minimum of 8 GiB of RAM to be responsive
during merge of certain keys). The propagation time between the servers
in the broader pool became quite big and servers dropping in-out
sporadically due to merges.

Now, this is somewhat better for the general pool since
https://dev.gnupg.org/T4175 results in retry on failover for 5xx codes,
but has caused a lot of problem reports in the past and not all distros
ship this in stable versions.

--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws

Hi all,
sorry for stepping in as I am not working on this topic, but following the
GDPA story for longer time I never read that we could simply prompt and
agree with the terms of the authority hosting the information of the
public key. The date and signature and probably reference to a version of
the agreement can be added to the key and it won't be much of overhead.
Isn't it more simple? Of course one should take care how the key servers
exchange information in a secure way, but IMO on the surface it is a matter
of an agreement between the person and the authority hosting the
information of the public key. As Tobias Mueller was writing, it is all
about handling personal information with care and not about fines. Of
course all of this should stand in court as well, because there are many
lawyers and companies that make money by legally blackmailing business
entities that down not comply to GDPA.

regards



On Mon, May 27, 2019 at 11:02 AM ilf <ilf@zeromail.org> wrote:

> Tobias Mueller:
> >> So far, I stand by last year's statement:
> >>> tl;dr: Keep calm and keep running keyservers.
> > Are you standing by your statement because you believe that processing
> > that data is lawful or because you don't fear the consequences of a
> > potentially unlawful processing of data?
>
> I stand by my statement because of the reasons I explained last year.
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html
>
> --
> ilf
>
> If you upload your address book to "the cloud", I don't want to be in it.
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>

On Sun, 26 May 2019 22:39, gnupg-devel@spodhuis.org said:

> With the various problems of SKS today, I tentatively suggest that not
> defaulting to the HKPS pool and choosing a different target for the
> keys.gnupg.net CNAME might be beneficial.

FWIW, keys.gnupg.net is since gnupg 2.2.7 not a CNAME name but aliased
by dirmngr in this way:

hkps://keys.gnupg.net -> hkps://hkps.pool.sks-keyservers.net
https://keys.gnupg.net -> https://hkps.pool.sks-keyservers.net
hkp://keys.gnupg.net -> hkp://hkps.pool.sks-keyservers.net
http://keys.gnupg.net -> http://hkps.pool.sks-keyservers.net
hkps://http-keys.gnupg.net -> hkps://ha.pool.sks-keyservers.net
https://http-keys.gnupg.net -> https://ha.pool.sks-keyservers.net
hkp://http-keys.gnupg.net -> hkp://ha.pool.sks-keyservers.net
http://http-keys.gnupg.net -> http://ha.pool.sks-keyservers.net

keys.gnupg.net -> hkps://hkps.pool.sks-keyservers.net
http-keys.gnupg.net -> hkps://ha.pool.sks-keyservers.net

this was needed to void problems with server name matching. Thus we
can't change that easily. Anyway, it is suggested tha the default
keyserver is used which is hkps://hkps.pool.sks-keyservers.net To
change this the keyserver option in dirmngr.conf needs to be used.

> suspect that >> subset.pool.sks-keyservers.net << is likely to be the
> best choice for GnuPG; the meaning of "subset" changes over time,

I am pretty sure that changing to this as the default will raise a lot
of concerns from the folks who want to elimiated the use of the string
"http://".



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Mon, 27 May 2019 13:30, kristian.fiskerstrand@sumptuouscapital.com
said:

> requiring load-balanced setup with minimum of 3 nodes on modern hardware
> (e.g a node today requires a minimum of 8 GiB of RAM to be responsive
> during merge of certain keys). The propagation time between the servers

Which would support my point to redesign the keyservers to

- Inhibit searches by user id.

- Drop all key signatures except for self-signatures and designated
revocations.

The first change will make Gnupg --search-keys useless and that command
could thus be changed to do a --locate-key with disabled local keyring.

The second requires that key-signatures must be send to the key owner
directly, which is anyway what most people do. And obviously the key
owner needs to distribute them by other means than the keyservers to
make the few WoT users happy.

Right, this requires that self-signatures are verified on upload.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

> On 29 May 2019, at 08:07, Werner Koch <wk@gnupg.org> wrote:
>
> Right, this requires that self-signatures are verified on upload.

...and on reconciliation?

A

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

On 29 May 2019, at 09:07, Werner Koch <wk@gnupg.org> wrote:

> Which would support my point to redesign the keyservers to
>
> - Inhibit searches by user id.

What is the reasoning behind this (as signing keys just are on the uploaded key with a keyid — so we are talking about the key its own data) ?

And pair this if needed with a submission protocol that insists on having the private key.

That would also openup, from a GDPR perspective, allowing the signing key ids back in.

Dw.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel