OpenPGP use cases for Arch (Re: WKD: returns only one pubkey (and why))

[Bernhard Reiter]

Hi David,


== use case key rollover

Am Freitag 09 Dezember 2022 13:38:01 schrieb David Runge:
> If I cycle out an old key I want to establish the chain of trust between
> two keys using cross-signatures. Both (revoked and active) keys need to
> be returned for someone else to be able to check the chain of trust
> between a revoked and an active key.

it may also be possible that a user already has the old pubkey,
including some established trust. It this is not the case,
there is no additional trust gained, by getting the old pubkey
via the same channel.

One idea of using different channels for building trust for pubkeys
is that an attacker would have to compromise several points in the 
instructure. So it can be a plus if the old pubkey has been found and 
verified earlier in the case of key-rollover.

> We currently use this mechanism in Arch Linux's WKD [1], as we must
> provide the signatures and revocation of signatures of main signing keys
> on packager keys not only for active but also for inactive keys
> (otherwise systems would be able to trust and install packages signed by
> distrusted keys).

(This usage of WKD seems okay, as long as the inactive pubkeys are revoked
for other reasons than "compromised", see reasons in
 https://datatracker.ietf.org/doc/html/rfc4880#section-5-2-3-23 )


== lost access to private key (and needs rollover)

> If someone loses access to their private key material and can no longer
> revoke their key, then we must provide both that key and any newer key.
> In this case there may be two (or more) keys active for a UID at the
> same time (for a while or indefinitely) and the old one should remain
> available.

As Andrew has pointed out: Still promoting a pubkey where the private part was 
lost, seems a bad idea. The superceded one should be put out of use as fast
as possible.

BTW: I believe that modern GnuPG versions create a revocation certificate by 
default, which sometimes is still in a backup and can be used,
even if the private material is lost.

So I consider this case quite unlikely, it would be embarassing for any
party to admit that they have lost the revocation certificate.


== retiring a key, with old signature still out there

> wants to switch from one key to another, they can not revoke
> that key right away, as there are still (hundreds of) software packages
> available in the repositories, signed with that key.

According to the OpenPGP standard RFC4880 "old signatures are still valid"
if the revocation reasons "superceded" or "retired" are given.
However I do not know if implementation always honors this in practice.
If they do, this use case seems feasable.
It is a general problem with verification of cryptographic signatures
which have been created in the past.

== distributing additional pubkeys

> In your described scenario, we would not be able to use WKD in a
> validation scenario for Arch Linux at all and additional keys besides
> the currently active (of which there could be several at a given time
> and from your notes above it would be unclear to me which exact key
> would be returned) would not be supported.

To summarise my thinking (which will have flaws as always,
which I hope someone will point out) up to this point:

WKD shall distribute the one recommended pubkey to use for new communication
(or verification). And because of this, it can be used for bringing in basic 
trust and making the whole trust building more robust.

If in the Arch Linux case, this new pubkey would sign the elder ones
(active and inactive) it gives them basic trust.
Can you sign the existing pubkey package always with the recommended key?
Then you could distribute other active keys with this package.

If users need higher trust levels, they will have elder pubkeys and have 
verified them, so for old active keys, they can sign the recommended pubkey
distributed with WKD and thus add to the basic trust.
What I see as advantage in this scenario is that if the WKD server
is compromised, publishing a new pubkey under Mary's control, users with 
higher security needs could detect this as the signature of the old
keys is missing.

Does this make sense to you?

Regards,
Bernhard
-- 
https://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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221213/79e0fb39/attachment-0001.sig>