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

[Daniel Huigens <[e-mail]>]

Hi Johannes & all,

At the OpenPGP email summit, folks agreed that there shouldn't be chains
of replacement keys, mainly for simplicity, but I also think it's
unnecessary.

If you have existing keys A and B where B replaces A, and then you
generate C replacing both, *and* you don't have access to key A, then
you can't sign a statement with key A saying that key C replaces it.
Therefore you can't create an equivalence binding.

You can sign a statement with key C saying that it replaces A, but
that's fairly meaningless and shouldn't be trusted in the absence of
other evidence, because anyone could sign such a statement claiming to
replace your key. Hopefully, by that time you would at least have some
trust / third-party sigs or w/e in key B, such that it's sufficient to
sign a statement with key B saying that key C is the replacement key.

Also, if you don't have the key material of key A anymore, it can't act
as a fallback key. In that scenario, you only want folks to use B or C.
Ideally, you would thus have a revocation certificate for key A lying
around somewhere, and use that to revoke key A.

I do agree that the note in the draft saying that key equivalence is
transitive is potentially confusing and perhaps it should just be
removed, in favor of explicitly saying that all keys in an equivalence
binding are equivalent to all the others (in some sense).

---

All of the above does not totally remove the question of what to do
when an implementation encounters chains in violation of the spec.

In our implementations and applications, I don't imagine we'll
proactively follow pointers in keys to look up other keys, at all.
Rather, we'll look up all available keys from WKD/KOO/whichever sources
are deemed appropriate, and then make a decision on which of those to
use. Even there, we might prefer to just pick the key that's most
recently generated or "most secure" (according to some heuristic).

The way I then imagine us using the information in the replacement key
subpacket is in the scenario where the user has manually verified /
trusted key A, and not the latest&greatest key B. Then, iff key A and
key B are equivalent, we can use key B instead of key A without asking
the user explicitly. That way, there are no chains to follow at all,
and at least the low-level API can be very simple, we just need
"select the key we like the most" and "are key A and B equivalent".
(For high-level APIs like SOP we might want something more abstract
as I've argued before.)

And then, the first step could later be expanded to take into account
the replacement key subpackets, but perhaps only if they present a
consistent view of the key holder's preference (i.e. without chains
and loops and so on).

Best,
Daniel