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

[Andrew Gallagher <[e-mail]>]

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

It depends on your settings, with StrictHostKeyChecking=accept-new it doesn’t warn on initial connection but does on subsequent key changes.

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

In the strict OpenPGP meaning of “trust”, no. If you would use the new key anyway under your chosen trust model, then use it, otherwise don’t. But on top of that there’s an application-level decision about whether to notify the user that something has happened at the OpenPGP layer. That’s not a protocol issue, it’s a purely UX one, and I don’t think it should be specified here.

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

Yes, I did consider that we could define a “trust equivalence” signature that would be closer conceptually (and cryptographically) to a subkey binding signature than to a certification. But I’m not sure that belongs here either, and it certainly opens a *lot* more questions.

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

Being absent from a particular keystore is not strong evidence of anything, as it depends heavily on the policy and/or capabilities of that keystore. I keep coming back to WKD… since it can only serve one key, it is impossible to use it for an optional (e.g. PQC) transition, so either I keep my old key on WKD and direct people elsewhere (somehow!) for my PQC key, or I put my PQC key on WKD and leave my non-PQC correspondents in limbo.

A