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

[Daniel Huigens <[e-mail]>]

On Tuesday, April 30th, 2024 at 13:33, Andrew Gallagher wrote:
> 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.

I don't think we can really separate the intended trust/security model
from the specification in that sense, because it's important that the
creator and consumer of the subpacket agree on the meaning, and the UX
decisions in turn depend on that. For example, with the current text, I
would personally not be comfortable removing a warning about a changed
key, because the text explicitly says that we shouldn't trust the key
more than we otherwise would.

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

But I'm not sure we need a new signature type for that; we could just
interpret a third-party certification with type ID 0x13 (Positive
certification of a User ID and Public-Key packet) made by a key with
the same User ID as having that meaning, for example? Then we don't
need any new mechanism for this.

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

Yeah, fair enough. But regarding WKD, I think we should discuss the
transition separately, and allow serving multiple keys (perhaps only if
the client signals that they support that somehow). Because I don't
think having to put one key on WKD and one key on HKP is a particularly
good solution - it's a lot of added work on both sides, difficult to
keep in sync, and clients who use WKD will prefer to receive both keys
from there somehow, presumably.

Best,
Daniel