Mailing List Archive

Launching a new keyserver on keys.openpgp.org!
Hey gnupg-devel folks,

the Hagrid team is pleased to announce the launch of our new keyserver, running
at keys.openpgp.org!

https://keys.openpgp.org

Here's the short story:

* Fast and reliable. No wait times, no downtimes, no inconsistencies.
* Precise. Searches return only a single key, which allows for easy key discovery.
* Validating. Identities are only published with consent, while non-identity information is freely distributed.
* Deletable. Users can delete personal information with a simple e-mail confirmation.
* Built on Rust, powered by Sequoia PGP - free and open source, running AGPLv3.

Full news announcement: https://keys.openpgp.org/about/news#2019-06-12-launch

Our primary motivation was to have a place where OpenPGP clients can reliably
and quickly obtain updates to key material (subkeys, revocations, ...), and that
also has as a simple and useful way of key discovery.

Some of the things we do are a bit experimental. For some things we found that
there is no good mechanism at this point, so we decided to drop them for now.
Most notably this includes third party signatures on keys, because they in their
current form the difficulties wrt privacy and spam outweigh their usefulness.

The server implementation Hagrid (as in, "keeper of keys") is developed here:
https://gitlab.com/sequoia-pgp/hagrid
Feel free to file issues if you find anything out of place. Please read our FAQ
first ;)

Huge thanks to Kai for the initial implementation, Justus and Neal for creating
Sequoia and working with me on this, dkg and Paul for testing and tons of
feedback, Phil for providing us with the domain, and of course everyone who
helped us test and polish this thing!

Happy to hear your feedback!

- V


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
Dear Hagrid Team,

Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> the Hagrid team is pleased to announce the launch of our new keyserver,
> running at keys.openpgp.org!

[..]
> https://keys.openpgp.org/about/news#2019-06-12-launch
[..]

> Some of the things we do are a bit experimental. For some things we found
> that there is no good mechanism at this point, so we decided to drop them
> for now.

it is good to see more code around OpenPGP.
Maybe hagrid can be useful to improve the common infrastructure to
distribute public keys in the future.

From my point of view the service announcement and its description
is a bit problematic, though:

The choice of keys.openpgp.org let people assume that there is a larger
consensus in the OpenPGP world about hagrid. While from my point of view
some approaches are still controversial.

The announcement and domain name portraits the service as an "OpenPGP
keyserver" while at least with the distribution of pubkeys without user id it
is not in compliance with RFC4880. But he annoumcement makes it sound like
this is a defect with GnuPG. A clearer phrasing would have pointed this out:
GnuPG behaves according to the current standard from which we deviate (for a
reason.)

Hagrid uses an OpenPGP implementation which describes itself as "few to no"
products using it "not a lot of experience with it in the wild". So it is
experimental, just like you write here, but not in the official announcement.

People even further aways may have assumed that hagrid is an offering like the
old keyservers which means carrying third party signatures. The timing of the
announcement here works against hagrid as the attacks of the SKS keyserver
network have recently become public close to the time of the hagrid
announcement. Because being close in timing, people may assume some
correlation. Are you aware of any correlation? (Like you have accellerated
the announcement after you have learned about the attacks.)

Hopefully some of the descriptions can be improved. Though the press has
already picked up on some of the points.

Technically I believe that it is possible to preserve the current idea
of a keyserver to make it privacy aware, but still decentral and
non-validating while still transporting third party signatures and several
keys for an email address. I'll outline this in other emails to gnupg-devel@.

If hagrid could be turned into a more robust replacement for the current
keyserver software, to me it would be a useful addition.

Sincerely,
Bernhard

--
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
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
Hi.

Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter:
> Dear Hagrid Team,
>
> Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> > the Hagrid team is pleased to announce the launch of our new
> > keyserver,
> > running at keys.openpgp.org!
>
> [..]
> > https://keys.openpgp.org/about/news#2019-06-12-launch
> [..]
>
> > Some of the things we do are a bit experimental. For some things we
> > found
> > that there is no good mechanism at this point, so we decided to
> > drop them
> > for now.
>
> it is good to see more code around OpenPGP.
> Maybe hagrid can be useful to improve the common infrastructure to
> distribute public keys in the future.
>
> From my point of view the service announcement and its description
> is a bit problematic, though:

[snip]

I fully agree with Bernhard. And I, for myself, think that strißßing
off third party signatures is a bad idea as well. It should be possible
to implement some kind of validation for them. Another way could be to
make only signatures from keys which are already on the server
available. Something like "import-clean" does on import. This would
avoid flooded keys. It could also be possible to filter out double
signatures which are made unintented. So it happened to me with key of
Werner a while ago. Sorry for this, Werner, something went wrong.

The other pint is, the hkp protocol should be expanded to some kind of
authentication, so only the owner can upload and update a key. The
hagrid approach, which forces people to upload the keys via web, as far
as I could look into it, is a bad solution for automatic systems. Yes,
I know, they offer some kind of Api for this, but it doesn't work just
utilizing gpg itself, as far as I can tell at this moment.

I tested the new server and it works. It's not a bad solution, but I am
missing some functions.

I think we should not only touch the server side. We should improve
both sides, or in other words the underlying protocol.

I know, all People involved in GnuPG have enough work to do. I am
willing to help where I can.

Regards,
Dirk


--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel
wrote:
> Hi.
>
> Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter:
> > Dear Hagrid Team,
> >
> > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> > > the Hagrid team is pleased to announce the launch of our new
> > > keyserver,
> > > running at keys.openpgp.org!
> >
> > [..]
> > > https://keys.openpgp.org/about/news#2019-06-12-launch
> > [..]
> >
> > > Some of the things we do are a bit experimental. For some things we
> > > found
> > > that there is no good mechanism at this point, so we decided to
> > > drop them
> > > for now.
> >
> > it is good to see more code around OpenPGP.
> > Maybe hagrid can be useful to improve the common infrastructure to
> > distribute public keys in the future.
> >
> > From my point of view the service announcement and its description
> > is a bit problematic, though:
>
> [snip]
>
> I fully agree with Bernhard. And I, for myself, think that strißßing
> off third party signatures is a bad idea as well. It should be possible
> to implement some kind of validation for them. Another way could be to
> make only signatures from keys which are already on the server
> available. Something like "import-clean" does on import. This would
> avoid flooded keys.

It could be trivially worked around via uploading the flooding keys to
the server. After all, it accepts *all* keys, only UIDs it restricts.

> The other pint is, the hkp protocol should be expanded to some kind of
> authentication, so only the owner can upload and update a key. The
> hagrid approach, which forces people to upload the keys via web, as far
> as I could look into it, is a bad solution for automatic systems. Yes,
> I know, they offer some kind of Api for this, but it doesn't work just
> utilizing gpg itself, as far as I can tell at this moment.

This presumes you can trust the server, and therefore solves only half
of the problem. If the server eventually becomes distributed, you would
also need to authorize cross-server exchanges. This still could be done
via hacking on HKP but in the end I think it's preferable to store
the permission on the key somewhere, so that end users can also benefit
from it.


--
Best regards,
Micha? Górny
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
On 09/07/2019 13:31, Dirk Gottschalk via Gnupg-devel wrote:
> The other pint is, the hkp protocol should be expanded to some kind of
> authentication, so only the owner can upload and update a key.

No need to change the protocol. Just store unvalidated uploads in a
holding area pending confirmation via the email(s) in the user ID packet(s).

Same way we sign people up to this mailing list, in fact. :-)

--
Andrew Gallagher
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
Am Dienstag, den 09.07.2019, 14:40 +0200 schrieb Micha? Górny:
> On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel
> wrote:
> > Hi.
> >
> > Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter:
> > > Dear Hagrid Team,
> > >
> > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> > > > the Hagrid team is pleased to announce the launch of our new
> > > > keyserver,
> > > > running at keys.openpgp.org!
> > >
> > > [..]
> > > > https://keys.openpgp.org/about/news#2019-06-12-launch
> > > [..]
> > >
> > > > Some of the things we do are a bit experimental. For some
> > > > things we
> > > > found
> > > > that there is no good mechanism at this point, so we decided to
> > > > drop them
> > > > for now.
> > >
> > > it is good to see more code around OpenPGP.
> > > Maybe hagrid can be useful to improve the common infrastructure
> > > to
> > > distribute public keys in the future.
> > >
> > > From my point of view the service announcement and its
> > > description
> > > is a bit problematic, though:
> >
> > [snip]
> >
> > I fully agree with Bernhard. And I, for myself, think that
> > strißßing
> > off third party signatures is a bad idea as well. It should be
> > possible
> > to implement some kind of validation for them. Another way could be
> > to
> > make only signatures from keys which are already on the server
> > available. Something like "import-clean" does on import. This would
> > avoid flooded keys.

> It could be trivially worked around via uploading the flooding keys
> to the server. After all, it accepts *all* keys, only UIDs it
> restricts.

It could be done by cleaning the keys after recieving. At first there
surely will only a few signatures be shown, but with a growing
database, it would be a good idea. It would be possible to preseed the
database with the strong set, or with other well known clean keys.

> > The other pint is, the hkp protocol should be expanded to some kind
> > of authentication, so only the owner can upload and update a key.
> > The hagrid approach, which forces people to upload the keys via
> > web, as far as I could look into it, is a bad solution for
> > automatic systems.
> > Yes, I know, they offer some kind of Api for this, but it doesn't
> > work just utilizing gpg itself, as far as I can tell at this
> > moment.

> This presumes you can trust the server, and therefore solves only
> half of the problem. If the server eventually becomes distributed,
> you would also need to authorize cross-server exchanges. This still
> could be done via hacking on HKP but in the end I think it's
> preferable to store the permission on the key somewhere, so that end
> users can also benefit from it.

That could be one was. On the other hand, there is no need für the sync
to also use HKP. There are other options to sync the database. And I
prefer the decentralized approach, so decentralized servers are
mandatory.

Permission? I think you are talking about the permission to distribute
the UID. That doesn't need to be stored in the key and it should not
be. Assuming the recipient knows who he is talking to and has recieved
the complete key directly from the sender, is there any nead for the
recipient to know that the sender doesn't want his UID to be leaked on
the servers? This could lead to wrong assumptions on the recipients
side.

Regards,#
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
On Tue, 2019-07-09 at 14:54 +0200, Dirk Gottschalk wrote:
> Am Dienstag, den 09.07.2019, 14:40 +0200 schrieb Micha? Górny:
> > On Tue, 2019-07-09 at 14:31 +0200, Dirk Gottschalk via Gnupg-devel
> > wrote:
> > > Hi.
> > >
> > > Am Dienstag, den 09.07.2019, 13:59 +0200 schrieb Bernhard Reiter:
> > > > Dear Hagrid Team,
> > > >
> > > > Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> > > > > the Hagrid team is pleased to announce the launch of our new
> > > > > keyserver,
> > > > > running at keys.openpgp.org!
> > > >
> > > > [..]
> > > > > https://keys.openpgp.org/about/news#2019-06-12-launch
> > > > [..]
> > > >
> > > > > Some of the things we do are a bit experimental. For some
> > > > > things we
> > > > > found
> > > > > that there is no good mechanism at this point, so we decided to
> > > > > drop them
> > > > > for now.
> > > >
> > > > it is good to see more code around OpenPGP.
> > > > Maybe hagrid can be useful to improve the common infrastructure
> > > > to
> > > > distribute public keys in the future.
> > > >
> > > > From my point of view the service announcement and its
> > > > description
> > > > is a bit problematic, though:
> > >
> > > [snip]
> > >
> > > I fully agree with Bernhard. And I, for myself, think that
> > > strißßing
> > > off third party signatures is a bad idea as well. It should be
> > > possible
> > > to implement some kind of validation for them. Another way could be
> > > to
> > > make only signatures from keys which are already on the server
> > > available. Something like "import-clean" does on import. This would
> > > avoid flooded keys.
> > It could be trivially worked around via uploading the flooding keys
> > to the server. After all, it accepts *all* keys, only UIDs it
> > restricts.
>
> It could be done by cleaning the keys after recieving. At first there
> surely will only a few signatures be shown, but with a growing
> database, it would be a good idea. It would be possible to preseed the
> database with the strong set, or with other well known clean keys.

I don't think you understood my point. There is no reason why
the attacker wouldn't be able to upload all the garbage keys used to
create garbage signatures.

>
> > > The other pint is, the hkp protocol should be expanded to some kind
> > > of authentication, so only the owner can upload and update a key.
> > > The hagrid approach, which forces people to upload the keys via
> > > web, as far as I could look into it, is a bad solution for
> > > automatic systems.
> > > Yes, I know, they offer some kind of Api for this, but it doesn't
> > > work just utilizing gpg itself, as far as I can tell at this
> > > moment.
> > This presumes you can trust the server, and therefore solves only
> > half of the problem. If the server eventually becomes distributed,
> > you would also need to authorize cross-server exchanges. This still
> > could be done via hacking on HKP but in the end I think it's
> > preferable to store the permission on the key somewhere, so that end
> > users can also benefit from it.
>
> That could be one was. On the other hand, there is no need für the sync
> to also use HKP. There are other options to sync the database. And I
> prefer the decentralized approach, so decentralized servers are
> mandatory.
>
> Permission? I think you are talking about the permission to distribute
> the UID.

No, I'm talking about permission to distribute signature, i.e. the proof
that the key owner has accepted it. Otherwise, GnuPG is still
vulnerable to being hit by a single malicious keyserver in the pool.


--
Best regards,
Micha? Górny
Re: Launching a new keyserver on keys.openpgp.org! [ In reply to ]
Am Dienstag 09 Juli 2019 16:09:57 schrieb Micha? Górny via Gnupg-devel:
> Otherwise, GnuPG is still
> vulnerable to being hit by a single malicious keyserver in the pool.

The defense against malicious keyservers in a federated model I see
is that those keyservers get blacklisted (and potentially legal action taken).
So a typical defense against system on the internet.

Bernhard


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