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

Andrew Gallagher <[email protected]> Mon, 27 Jan 2025 18:20:48 +0000

Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>

On 27 Jan 2025, at 17:46, Daniel Huigens <[email protected]> wrote:
> 
> On Monday, January 27th, 2025 at 18:09, Andrew Gallagher <[email protected]> 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

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 833 B)