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

[Daniel Huigens <[e-mail]>]

On Monday, April 29th, 2024 at 19:20, Andrew Gallagher wrote:
> To me at least, TOFU means (automatic) trust on first use (only), as implemented in SSH.

TOFU as implemented in OpenSSH is not automatic though, you have to
explicitly accept the key, and (ideally) you should manually verify the
key using an external authenticated channel first. If you do that, then
it makes sense to get a warning when the key later changes. But if you
don't, it's rather meaningless, and you might as well accept the new
key just as blindly as you accepted the first one - it's not that
different from the YOLO model either way.

Note also that in Signal and WhatsApp and so on, people usually ignore
such warnings. That's why Key Transparency was invented, as it offers
a much better UX (i.e. automatic key verification). And I'd argue we
should head that direction with OpenPGP, too, rather than insisting on
such warnings.

> 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 don't really see how it's more suspicious than the original key, or
why the replacement key subpacket would make it less so, in the absence
of any other signals, or any text in the draft that says so.

Is your position that Section 5 should be changed to say that the
subpacket may transfer some amount or type of trust that the user may
have in the original key (either due to having used it for a long time,
or by having explicitly trusted it after presumably having verified it
manually, for example)?

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

OK, but then I think we should squabble about what the meaning of such
a certification should be, before we decide if we need a new mechanism
for this. For example, we could say that if key A with user ID u has
trust level x, and certifies key B with the same user ID u, then that
should transfer the full trust level.

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

Yeah, fair enough, you still need to query by fingerprint to find out
the old key is revoked. But, querying by email address does give you
the new key, and tells you the old key is gone, which probably already
tells you that you should use the new key anyway, regardless of whether
the old key is revoked or not. Especially if the new key is signed by
the old key which you still have locally.

(But, whether or not the old key is revoked is still relevant for
signature validity, of course, so you might want to do both.)

Best,
Daniel