[openpgp] Re: I-D Action: draft-ietf-openpgp-replacementkey-02.txt

[Andrew Gallagher <[e-mail]>]

On 27 Jan 2025, at 17:46, Daniel Huigens <[e-mail]> wrote:
> 
> On Monday, January 27th, 2025 at 18:09, Andrew Gallagher <[e-mail]> wrote:
>> It would only work if B was already the (bound equivalent) replacement of A, and then the key holder subsequently lost access to A. It could be years later they misplaced the passphrase or some such. They could still say “upgrade from A to B if you can”, but without encouraging fallback.
> 
> In this scenario, perhaps key A could designate key B as a delegated revoker <https://www.ietf.org/archive/id/draft-dkg-openpgp-revocation-01.html#delegated-revoker> as well, such that key B can revoke key A once it's time for that? (And once that idea or some variant of it is implemented, of course..)

That would definitely give us the desired functionality (and a bit more). The main semantic difference would be that delegated revocation is permanent by design, whereas replacement can evolve over time. And from a practical point of view, a delegated revoker would have to be created for every equivalence binding, because by the time you need one it’s to late to create one - and this might be too heavy for a feature that we expect to be rarely used. (Remember that we decided not to use certification signatures for equivalence to keep the mechanism lightweight, and delegated revokers would negate that saving)

That said, you could equally argue that it’s not worth adding flag bits for a feature that we expect to be rarely used. And I suppose this whole subject comes down to a cost/benefit argument.

A