Revoking main key, creating a new elliptic curve key

I’ve been using OpenPGP since years now (2008), with my lovely known-to-be-very-unsecure key (I know, I know). I recently discovered some changes in the community that I’ll describe bellow. It was a good time to revoke it and create a new one with up-to-date security standards. Elliptic Curves are default now for new keys in Fedora.

Here is the old one that I revoked:

sec   dsa1024 2008-07-15 [SC] [revoked: 2023-08-15]
      241D 5D1E A64C 83E5 3B8F  D34C 5B58 243C BE50 0356
uid           [ revoked] Nicolas TANDE (nittch) <nittch at linkea.org>
uid           [ revoked] Nicolas TANDE (nittch) <nittch at gmail.com>
uid           [ revoked] Nicolas TANDE <nicolas.tande at gmail.com>

sec   rsa2048 2018-11-21 [SC] [expired: 2019-11-21]
      1A58 2BB7 358E 9E44 3E49  9E63 F03A 9930 4654 1FCF
uid           [ expired] Nicolas TANDE (nittch) <nittch at cumulogranite.fr>

And the new one.

sec   ed25519 2023-08-15 [SC]
      9FC4 568F 08AB 50F5 9C5B  8CCE 6C58 6D06 8943 F81F
uid           [ultimate] Nicolas TANDÉ (Nittch) <nicolas.tande at linkea.org>
uid           [ultimate] Nicolas TANDÉ (Nittch) <nittch at gmail.com>
uid           [ultimate] Nicolas TANDÉ (Nittch) <nittch at linkea.org>
uid           [ultimate] Nicolas TANDÉ (Nittch) <nicolas.tande at gmail.com>
ssb   cv25519 2023-08-15 [E]

Why I don’t use web of trust anymore

At the beginning, when I’ve set it up in 2008, OpenPGP was based on the web of trust principle, the idea was to determine a trust based on the trust you have on already known signatures. You had sometimes key signing parties to have a more dense web trust within a particular group. Signatures were publicly shared so everybody could determine its trust to others.

I’ve slowly stopped using OpenPGP because it was less and less in contact with the people I knew in this web of trust. This model is based on the trust you have in your surroundings, which also has to maintain the web of trust. It’s also really difficult to evaluate the trust you have in other people while not knowing their online-privacy practices.

The problem is because signatures were exchanged publicly, malicious people could inject or discover personal data about users (lots of stories about compromised data in servers). It’s also a way to make files about group of people. I even started to get spams on identities I only published on keyservers! In the EU, GDPR somehow made a bit step forward about controlling personal data but it seems that work needed to adapt it to decentralized / public solutions like this web of trust was huge.

At the same time, common key sharing servers started to became a mess:

• pool.sks-keyservers.net was a project to have a decentralized network to exchange keys, but it was taken down in 2001 (on their website: “Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.”). (keys.gnupg.net was part of the pool.)
• pgp.mit.edu is really getting slow and missing signatures… But still alive somehow!
• keyserver.ubuntu.com works but is really Linux oriented

A GDPR compatible central authority: keys.openpgp.org

I recently discovered that in 2019 keys.openpgp.org/about was started (I’m late, I know ^^). This is a project started with community joint work of people from Enigmail, OpenKeychain, Sequoia-PGP. Now it also is the default choice for clients in GPGTools, Enigmail, OpenKeychain, GPGSync, Debian, NixOS and others…

Basically, this is service that do not leak personal data, only you can publish your key, and you can remove it later if you wish so (GDPR compatible). To stay reliable and serious about personal data, they don’t want to be decentralized also, which is a good choice in my opinion. They announced to be working on ways to control which signature is exposed, to give control on that (their track: require cross signatures between users).

Through HTTPS: Web Key Directory (WKD)

The idea behind Web Key Directory is to provide the key directly by https on the domain website: https://openpgpkey.[DOMAIN]/.well-known/openpgpkey/[DOMAIN]/hu/[HASH-OF-USERNAME]. (To have the hashes for the usernames, use gpg --list-keys --with-wkd-hash).

This is the solution used by biggest developper communities using OpenPGP (Arch, Debian, Gentoo, kernel.org…).

It is quite simply documented on GnuPG wiki, and here. To generate the directory structure you can use gpg --list-options show-only-fpr-mbox -k @example.org | gpg-wks-client -v --install-key

There is also a configuration checker here, checking a lot of things like content-type in your webserver for these keys.

Through DNSSEC (DANE):

If you can trust your DNS (ie: you have a DNSSEC enabled infrastructure), another option is to use DANE. The idea behind it is to retrieve key by getting DNS record OPENPGPKEY at [USER-HASH]._openpgpkey.[DOMAIN].

To create the entry, I used “hash-slinger” package which is super easy. You just have to do opendnskey --create user@example.net to have the DNS output to inject in your zone. opendnskey --verify user@example.net is also a good check tool. Again this is simpler if you already have a DNSSEC infrastructure, which is a big entry cost and which is really not that common.

Retrieving a key from somebody

Of course GnuPG supports these three methods by default. Depending on your configuration gpg --locate-keys user@example.net will use one or another method. Take a look on auto-key-locate option.