Re: [openpgp] Call for adoption of draft-gallagher-openpgp-replacementkey

[Daniel Huigens <[e-mail]>]

Hi Andrew,

On Wednesday, April 24th, 2024 at 16:41, Andrew Gallagher wrote:
> Key distribution methods that carry implicit trust (such as Autocrypt and WKD) do not strictly require a key replacement mechanism, however implementations that perform TOFU should(!) normally warn if they see that a key has changed.

IMO, this is only true if we are in a scenario where the user has
explicitly opted to trust the original key. If we use Autocrypt or WKD
for "opportunistic" (so to speak) encryption automatically, without any
user interaction, we shouldn't then turn around and warn the user when
the key changes, either, as they'll have no context on what they're
being warned about.

But, even if we are in the first scenario...

> In such a scenario the key replacement subpacket could suppress the TOFU key-change warning.

... this is only true if the key replacement subpacket is considered
to transfer the trust from the old key to the new one, right? I read
Section 5 of draft-gallagher-openpgp-replacementkey as saying that
we shouldn't place any special trust in the new key based on this
subpacket. I'd imagine, that if we do want to transfer trust, we can
sign the new key using the old key - but that's already possible today.

So to me, the main advantage of (the preferred key server subpacket in
combination with) the replacement key subpacket would seem to be being
able to signal how to automatically (update, and now) replace the key,
in cases where you weren't able to do that before, e.g. if the key was
uploaded manually. Or, when using Autocrypt, it'd allow you to update
the key proactively if you haven't received an email from a contact in
a while.

But, both of those things are only true if the key already has a
preferred key server subpacket when it's uploaded (or if the client is
willing to make some guess(es) about which key server might likely have
updates to the key - but at that point, it might as well query by email
address, rather than querying by fingerprint and then following the
replacement key subpacket to find the new key).

So, if that's the use case you want to serve, I'd think we should
recommend putting the preferred key server subpacket in a self-signature
*before* the key is replaced. Though, to be perfectly honest, that'd
require a level of foresight on the side of the generating party that
I'm not sure is realistic, but one can hope, of course :')

Best,
Daniel