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

[Daniel Kahn Gillmor <[e-mail]>]

Thanks for doing this work, Andrew.

With no chair hat on, my preference is for a mandatory imprint with an
optional fingerprint (i think that's your option 3b).

I would include guidance like:

------------

- If the imprint is identical to the fingerprint, the fingerprint can be
  safely omitted.  The generator SHOULD omit the fingerprint in this case.

- If the imprint is identical to the fingerprint, the generator SHOULD
  NOT omit the fingerprint, unless it has reason to believe that all
  consumers have a straightforward way to retrieve the referenced
  certificate without depending on its fingerprint.

------------

I don't think there is a large implementation cost for this -- the
codepaths will already be mostly in place.

This allows an isolated implementation ecosystem that expects to have no
interaction with the keyserver network to not consume the extra space,
but generally discourages it, which is the appropriate approach for the
current scenario.

As for the UX guidance, i'd be pretty wary about the level of detail
that you've proposed for the process of *generating* the replacement key
data in this thread.  I agree with Daniel Huigens that the ideal UX
shouldn't expose any information about specific
certificates/keys/algorithms to the user.

I like Daniel Huigen's proposal for augmenting "sop update-key" to be
able to make use of this specification, as i think it matches the level
that would be appropriate for most applications.

That said, i like the idea of describing more of the workflow for the
*consumption* of a certificate with such a reference.  I'm not convinced
about the part of the notifying the user or asking the user part,
though.  again, i'm not sure that we want to involve the user so deeply
at this level.  But i think it would be really useful to walk through
the steps that need to be taken, and the higher-level tradeoffs that
might be made there (e.g., whether there are privacy implications of
trying to fetch the associated keys, and if affordances should be made
for privacy-sensitive scenarios).

     --dkg