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

[Andrew Gallagher <[e-mail]>]

On 29 Apr 2024, at 16:10, Daniel Huigens <d.huigens=[e-mail]> wrote:
> 
> 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.

Opportunistic encryption with silent key rollover isn’t really TOFU though, and IMO neither is anything that requires explicit confirmation on first use. To me at least, TOFU means (automatic) trust on *first* use (only), as implemented in SSH. I agree completely about TOFU’s bad UX, but making all the warnings go away is surely closer to dkg’s “YOLO". :-) I’d also argue that WKD isn’t really TOFU either, since unlike Autocrypt it has a fairly secure binding to the X.509 trust framework.

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

Not necessarily. Say that a particular correspondent’s emails starts to include a new key in their autocrypt header. In the absence of a replacement key subpacket on the old key, it could be considered suspicious. An MUA might use this to decide whether or not to display a “this person’s security key recently changed” notification (similar to e.g. WhatsApp).

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

Sure, but certifying key B with key A will generally result in a weaker trust value for B than A, and unless key A had explicit or delegated ownertrust, the trust value allocated to B due purely to A’s certification would probably be zero. Only by recommending that B is also certified by the same upstream signatories as A do we have a decent chance of B getting a meaningful trust value.

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

Say that a key has been hard revoked, and we are following the advice in https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-abuse-resistant-keystore-06#section-7.4 :

> If the primary key of a certificate is revoked via a key revocation signature (type 0x20), an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation.

In that case, key lookup by user ID will fail to return the revoked key, so we still need to update by fingerprint.

A