Set up OpenPGP WKD #39

caesar commented 2022年11月19日 08:28:22 +01:00

We should set up WKD for our OpenPGP public keys. This aids discovarability and authentication of the keys and is effectively a federated alternative to keyservers.

The easy way is to publish the keys to keys.openpgp.org (which we need to do anyway) and delegate to them via a DNS record like this:

openpgpkey.forgejo.org. 300 IN CNAME wkd.keys.openpgp.org.

The alternative is to self-host the keys on our own domain at the .well-known/openpgpkey/hu/ path. It is complicated to calculate the required filenames but there are generators.

We should set up [WKD](https://wiki.gnupg.org/WKD) for our OpenPGP public keys. This aids discovarability and authentication of the keys and is effectively a federated alternative to keyservers. The easy way is to publish the keys to [keys.openpgp.org](https://keys.openpgp.org) (which we need to do anyway) and [delegate to them](https://keys.openpgp.org/about/usage#wkd-as-a-service) via a DNS record like this: ``` openpgpkey.forgejo.org. 300 IN CNAME wkd.keys.openpgp.org. ``` The alternative is to [self-host](https://wiki.gnupg.org/WKDHosting) the keys on our own domain at the `.well-known/openpgpkey/hu/` path. [It is complicated to calculate the required filenames](https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service#section-3.1) but [there are generators](https://keyoxide.org/util/wkd).

caesar commented 2022年11月19日 08:53:50 +01:00

There is also a conversation to be had (maybe deserving of its own issue...) regarding exactly what OpenPGP keys we should have and what addresses should be on them.

Obviously releases and security both need their own keys, and those have both already been created.

• The security key has the email address security@forgejo.org. Only @Gusted currently has the private key.
• The releases key (which is as-yet unpublished) has the email address contact@forgejo.org. I think this should be changed to the release team's email address, release@forgejo.org.

That would leave open the possibility to create a "general" keypair for contact@forgejo.org, which could be used for a Keyoxide proofs verifiably linking together our various online points of presence.
However, the addition of a third key could complicate matters, and arguably there would be no need for it in addition to the security key. Therefore an alternative would be to add contact@forgejo.org as a second address on the security key and turn it into a generic key.

There is also a conversation to be had (maybe deserving of its own issue...) regarding exactly what OpenPGP keys we should have and what addresses should be on them. Obviously releases and [security](https://codeberg.org/forgejo/meta/issues/37) both need their own keys, and those have both already been created. - [The security key](https://keys.openpgp.org/search?q=1B638BDF10969D627926B8D9F585D0F99E1FB56F) has the email address `security@forgejo.org`. Only @Gusted currently has the private key. - The releases key (which is as-yet unpublished) has the email address `contact@forgejo.org`. [I think this should be changed](https://codeberg.org/forgejo/forgejo/issues/4#issuecomment-690595) to the release team's email address, `release@forgejo.org`. That would leave open the possibility to create a "general" keypair for `contact@forgejo.org`, which could be used for a Keyoxide proofs verifiably linking together our various online points of presence. However, the addition of a third key could complicate matters, and arguably there would be no need for it in addition to the security key. Therefore an alternative would be to add `contact@forgejo.org` as a second address on the security key and turn it into a generic key.

Ghost commented 2022年11月19日 09:09:53 +01:00

@Gusted could you please send me the private key for the security key at loic@dachary.org encrypted with https://codeberg.org/dachary.gpg for safekeeping?

@Gusted could you please send me the private key for the security key at loic@dachary.org encrypted with https://codeberg.org/dachary.gpg for safekeeping?

Ghost commented 2022年11月19日 09:18:10 +01:00

@caesar my intuition here is that releases and security are likely to remain two different group of people with two different threat models and are better served with two keys managed independently rather than a single one.

I think it makes sense to use the release signing key as the "general" keypair that you describe. Its primary use is to sign releases and, as a forgejo user, I would not expect to find a keypair for contact@forgejo.org that does not allow me to verify releases.

@caesar my intuition here is that releases and security are likely to remain two different group of people with two different threat models and are better served with two keys managed independently rather than a single one. I think it makes sense to use the release signing key as the "general" keypair that you describe. Its primary use is to sign releases and, as a forgejo user, I would not expect to find a keypair for `contact@forgejo.org` that does not allow me to verify releases.

caesar commented 2022年11月19日 09:23:56 +01:00

@caesar my intuition here is that releases and security are likely to remain two different group of people with two different threat models and are better served with two keys managed independently rather than a single one.

Absolutely. I didn't mean to suggest that those two should be combined, although I can see that I wasn't very precise with my wording.

I think it makes sense to use the release signing key as the "general" keypair that you describe. Its primary use is to sign releases and, as a forgejo user, I would not expect to find a keypair for contact@forgejo.org that does not allow me to verify releases.

That's an interesting idea, I hadn't thought of that. It could indeed make sense.
In that case I would propose that:

• The main key be renamed from Forgejo Releases to Forgejo
• A subkey be used for signing releases (this is already the case I believe as you have already created a signing-only subkey with a one-year validity).

If you agree that the above makes sense, I will go ahead and add Keyoxide identity proofs for the domain and the Codeberg org to that key.

> @caesar my intuition here is that releases and security are likely to remain two different group of people with two different threat models and are better served with two keys managed independently rather than a single one. Absolutely. I didn't mean to suggest that those two should be combined, although I can see that I wasn't very precise with my wording. > I think it makes sense to use the release signing key as the "general" keypair that you describe. Its primary use is to sign releases and, as a forgejo user, I would not expect to find a keypair for `contact@forgejo.org` that does not allow me to verify releases. That's an interesting idea, I hadn't thought of that. It could indeed make sense. In that case I would propose that: - The main key be renamed from `Forgejo Releases` to `Forgejo` - A subkey be used for signing releases (this is already the case I believe as you have already created a signing-only subkey with a one-year validity). If you agree that the above makes sense, I will go ahead and add Keyoxide identity proofs for the domain and the Codeberg org to that key.

Ghost commented 2022年11月19日 09:25:35 +01:00

@caesar you have me convinced, I will change the id of the release keypair to be release@forgejo.org rather than contact@forgejo.org.

@caesar you have me convinced, I will change the id of the release keypair to be `release@forgejo.org` rather than `contact@forgejo.org`.

caesar commented 2022年11月19日 09:29:14 +01:00

Haha well I was also convinced by your suggestion, so we have succesfully swapped opinions 😉

I'm fine with it either way really but I do find your argument convincing that the master key currently used for signing could be the main master key for the organisation, rather than creating a third key. It would probably be simpler in organisation terms than my previous suggestion.

Haha well I was also convinced by your suggestion, so we have succesfully swapped opinions 😉 I'm fine with it either way really but I do find your argument convincing that the master key currently used for signing could be the main master key for the organisation, rather than creating a third key. It would probably be simpler in organisation terms than my previous suggestion.

Ghost commented 2022年11月19日 09:54:17 +01:00

The release key can be used for a generic purpose although it has a release@forgejo.org email, I think. I suppose people who have some GPG expertise (they are very rare but also very precious) won't be disoriented by the fact that the email is not contact@forgejo.org.

The release key can be used for a generic purpose although it has a `release@forgejo.org` email, I think. I suppose people who have some GPG expertise (they are very rare but also very precious) won't be disoriented by the fact that the email is not `contact@forgejo.org`.

caesar commented 2022年11月19日 10:04:54 +01:00

I have now implemented WKD delegation as described in the first post of this issue.

This means than any keys which are published to keys.openpgp.org will automatically be available via WKD.

In the future if we prefer we can always switch to the more complicated route of "self-hosting" WKD.

I have now implemented WKD delegation as described in the first post of this issue. This means than any keys which are published to `keys.openpgp.org` will automatically be available via WKD. In the future if we prefer we can always switch to the more complicated route of "self-hosting" WKD.

Gusted commented 2022年11月20日 15:02:40 +01:00

@dachary I've send over the secret GPG key.

@dachary I've send over the secret GPG key.