Mailing List Archive

On 23/10/2020 10:14, Bernhard Reiter wrote:
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.

I've thought about this quite a bit after my previous attempts to
reconcile recon with selective retention. I believe the solution is to
segregate the "recon" part of the process from the "retention" part.

Our current recon model requires that all packets that exist in the
keyserver network be reconned via the same method. This causes problems
when trying to apply retention policies to certain packets and not
others. For example, we almost always want revocation packets to recon,
almost *never* want user-attribute packets, and other packets such as
user-id fall somewhere in between.

If we segregate the recon and retention components, we can recon an
agreed bare minimum of packet types, without needing to apply per-key
filters and thereby avoiding any split-brain or sync-storm failures.
This minimal list of packet types would have to include primary keys and
revocation keys, but little (perhaps nothing?) else.

Along with these packets each keyserver would gossip a list of
associated hints from other keyservers. These hints would declare that
an "authoritative keyserver" exists that is serving the full key,
presumably having performed validation. The full set of packets would
not be advertised for recon, but would be available through hkp(s) as
normal (for the purposes of this section, the existence of an entry in
WKD would count as an "authoritative keyserver"). Other keyservers would
gossip that they have recently been able to download the full key from
one or more authoritative locations. Such hints would not be
cryptographically part of the key in question, so they should have an
expiration date in order to prevent stale info accumulating in the network.

A keyserver that is not willing to retain the full set of packets for a
given key could instead choose to serve them via a caching proxy or an
HTTP redirect to a server that is willing. This would allow for the full
public key to be discovered and refreshed by the usual methods, but
without every keyserver in the network having to retain its own copy.

It would still be advisable for a user to upload their full key to more
than one validating keyserver, in order to guard against service
outages, but even in the case where the only copy of the full key
becomes unavailable indefinitely, primary and revocation packets
associated with it would continue to recon. This model also has the
advantage of significantly reducing the number of packets in the recon
database.

Some other initial ideas:

* The new pool would have to be completely separate from the old pool,
because the deltas would be astronomical.

* Existing validating keyservers could cheaply "join the new pool" by
setting up a separate reconning keyserver in the pool that a) advertises
the appropriate hints on behalf of the validating keyserver and b)
submits any newly-synced packets into the validating keyserver.

* Hints could take the form of fake preferred-keyserver subpackets, in a
similar manner to fake "fpr:DEADBEEF" user-id packets that have been
previously discussed to support UID-less key refresh on legacy systems
(could both be combined in a single fake BIND sig?). These would be
amenable to recon, and naturally come with a timestamp that could be
used to expire them from the cache. Cryptographic non-verification
should ensure that real preferred-keyserver subpackets would override
such hints in client applications.

Thoughts?

--
Andrew Gallagher

On 23/10/2020 13:23, Andrew Gallagher wrote:
> * Hints could take the form of fake preferred-keyserver subpackets, in a
> similar manner to fake "fpr:DEADBEEF" user-id packets that have been
> previously discussed to support UID-less key refresh on legacy systems
> (could both be combined in a single fake BIND sig?).

After a little further thought, such a combined-bind is wrongheaded. The
entire point of fake userids is that userids are (potentially) personal
data and therefore can't sync. ;-) So we'd have to bind the fake
preferred-keyserver subpacket separately.

--
Andrew Gallagher

I can only speak for myself and see that when it comes to SKS that there can
be no consensus achieved between privacy loving EU citizens and (US
based) SKS operators, while Mailvelope and Hagrid respect the users wishes.

With that being said I am out and better let Mr Barr and Mr de Kerchove decide
what the SKS future will bring.

Last but not least I no longer need public SKS key servers.

Best regards
Stefan




On Fri, Oct 23, 2020 at 12:55 PM Bernhard Reiter <bernhard@intevation.de> wrote:
>
> Am Samstag 19 September 2020 23:34:32 schrieb Stefan Claas:
> > I stand by my points that hockeypuck can solve the issues
>
> To me
> it makes sense to preserve a decentalised network of public keyservers [1].
>
> In my post
> Preserving non-central and privacy with a "permission recording keyserver"
> [Reiter 2019-07 a]
> https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html
> there is a concept allowing for compatibility with strong privacy laws.
>
> Some ideas how we could conceptually preserve third party
> signature information on public servers:
> Preserving third party signatures distribution [Reiter 2019-07 b]
> https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html
>
> So yes, I also believe that improvements to hockeypuck or a fresh
> implementation could step by step get the public keyserver network up again.
>
>
> Best Regards,
> Bernhard
> ps.: Because I believe funding more qualified dev time is part of the
> solution: You can become a sponsor for hockeypuck development, see
> https://github.com/sponsors/cmars
> (my company Intevation is one, we also gave a small donation to KF Web running
> https://sks-keyservers.net/).
>
>
> [1]
> Web of Trust's usefulness [Reiter 2019-07 c]
> https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html
>
> | as additional source of trust and history.
>
> | Abandoning the web of trust common infrastructure works against usage
> | models where there is anonymous usage, several identities, non-email use
> | and offline usage. All those maybe not the majority case, they may even be
> | niche models, but I think they are important to add diversity and
> | resiliance against manipulations of mainstream players.
> (spelling improved)
>
> --
> www.intevation.de/~bernhard +49 541 33 508 3-3
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

> On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users <gnupg-users@gnupg.org> wrote:
>
> there can
> be no consensus achieved between privacy loving EU citizens and (US
> based) SKS operators

Most SKS operators are (were?) based outside the US. This is primarily a technical challenge, not a political one.

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

If it is a technical challenge and Kristian as head (pool maintainer),
why does he not ask publicity
the hockeypuck author, dkg and the sequoia-team, for help?

As an example, if I would be Kristian I would do so, set-up with my
pool gang a hockeypuck
test-net (bootstrapped with a handful of pub keys) and work with the
programmer(s) on long
standing issues. Secondly I would give my gang a timeframe of a couple
of months to
gracefully shut down their SKS servers.

Would that have any disadvantages for GnuPG users worldwide, while we also have
Mailvelope and Hagrid?

On Sat, Oct 24, 2020 at 1:39 PM Andrew Gallagher <andrewg@andrewg.com> wrote:
>
>
> > On 24 Oct 2020, at 10:41, Stefan Claas via Gnupg-users <gnupg-users@gnupg.org> wrote:
> >
> > there can
> > be no consensus achieved between privacy loving EU citizens and (US
> > based) SKS operators
>
> Most SKS operators are (were?) based outside the US. This is primarily a technical challenge, not a political one.

Regards
Stefan

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