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

[Daniel Huigens <[e-mail]>]

Hi Andrew,

Thanks for proposing text :)
IMHO, this guidance assumes a fairly low-level interface, asking the
user to manage individual TSKs, and so on.

I would like to get to a point where we offer the user a single button,
"refresh keys" (or similar), which is only displayed if the current keys'
algorithms are considered out of date, and which updates all private
keys in one go.

Whether this involves adding a subkey, or adding a primary key with a
key equivalence binding, should be relatively transparent for the user -
after all, the goal of this draft is to make that transparent for their
contacts, as well.

So I wouldn't ask users to mark one key as a replacement for another,
and so on; rather the implementation can decide whether a new primary
key is needed, and if so mark it as a replacement of the previous
primary key(s) automatically.

This roughly matches my proposal for sop in [1], but also makes for a
more intuitive and high-level UI, IMHO.

At the very least, I'd argue the guidance shouldn't preclude such a UI.

Best,
Daniel

[1]: https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/99#note_2100646405


On Friday, November 1st, 2024 at 16:18, Andrew Gallagher wrote:

> Hi, all.
> 
> On 22 Oct 2024, at 15:08, Andrew Gallagher andrewg=[e-mail] wrote:
> 
> > * Do we need further UX guidance, and if so what should be included? [2]
> 
> 
> Please consider the following proposed text before next week’s meeting:
> 
> —
> 
> On creation of a new primary key, or on triggering an expert option, an implementation SHOULD:
> • If used interactively, ask the user whether this is a replacement key for an original key or keys
> • If a list of original keys is supplied (either interactively or via an expert option), obtain/refresh the corresponding certificates and make a selfsig over the new primary key with an inverse replacement key subpacket
> • If any of the original private keys are available, make a new selfsig on the corresponding certificate(s) with a forwards replacement key subpacket to create key equivalence bindings
> 
> On revocation of an existing primary key, or on triggering an expert option, an implementation SHOULD:
> • If used interactively, ask the user whether this key has a replacement key
> • If a replacement key is supplied (either interactively or via an expert option), obtain/refresh the corresponding certificate and add an inverse replacement key subpacket to the revocation sig over the original primary key
> • If the replacement private key is available, make a new selfsig on the corresponding certificate with a new or updated inverse replacement key subpacket, to create a key equivalence binding
> 
> On receipt of a new or updated certificate, an implementation SHOULD:
> • Check to see if it contains an unpaired replacement key subpacket that refers to any of the available private keys
> • Notify the user that a unidirectional reference exists
> • If used interactively, ask the user to confirm that they wish to complete the equivalence binding
> • If the user indicates (whether interactively or via an expert option) their acceptance of the equivalence binding, make a selfsig over the affected primary key(s) with the corresponding replacement key subpacket
> 
> —
> 
> A
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]