[openpgp] Re: Splitting replacement keys subpacket into related keys and trust equivalence?

[Justus Winter <[e-mail]>]

Hello :)

Daniel Huigens <d.huigens=[e-mail]> writes:

> After thinking a bit more about the fingerprint/imprint question after
> the meeting, I think they (and the entire subpacket in general) serve
> different purposes that perhaps should be split up into separate
> subpackets (but along a different axis than the forward/inverse
> split proposal).
>
> One purpose is identifying the replacement key so that it can be looked
> up (previous versions of this draft only had this purpose in mind AIUI).
>
> The other purpose is to create a trust-equivalence binding between two
> or more keys. I've advocated for adding this to the draft in the past,
> so I'm partly to blame for that extra scope, though in my defense, I
> didn't say that it should necessarily happen in the same subpacket :')

First of all, I have an issue with the terminology.  The text in
question does not mention "trust-equivalency" once.  I think it'd be
better to stick with the terminology established in the document under
discussion, or clearly say why the existing terminology is insufficient.

Further, I have a rule of thumb when discussing OpenPGP: any person
saying the word "trust" is likely confused and most certainly wrong.

For example:

> For some use cases (e.g. when using WKD with a hypothetical update that
> allows serving multiple keys) the first purpose is entirely irrelevant,
> as you already have all keys and the only thing you need is the trust-
> equivalence binding (if the user manually trusted one of the keys in
> the past, for example).

The phrase "trusted one of the keys" is meaningless.  There are two
kinds of trust being discussed in OpenPGP, and I'm pretty sure you are
thinking of the former, but the phrase has the shape of the latter:

- One can have a varying degree of confidence that a given certificate is
  appropriate for a given use.  Most often we think of (email address,
  cert) tuples, for example.  (Shape: tuple).

- One can also have a varying degree of confidence that a certificate
  holder's objectives are sufficiently aligned with ones own objectives so
  that the certificate holder can be used to authenticate other (email
  address, cert) tuples.  Adding to the confusion, GnuPG calls this
  owner trust.  (Shape: certificate).

I realize that I'm being pedantic here, but people get this wrong all
the time, and if we don't get it right (because we're using sloppy
language), how can we expect our downstream developers or users to get
it right?

> I also think the first purpose is potentially underserved by the current
> draft, since e.g. (as Andrew pointed out) there's no way to say "please
> find the replacement key on this other key server, which is different
> from the key server that I've been using to update this key".

Saying go find my replacement cert on that server is the web bug, that'd
be an antifeature.

> And.. actually there's a third purpose: identifying which key is the
> preferred one. I tend to think this is the least important among the
> three and could be replaced by just saying that the latest-generated
> valid (unrevoked etc) key among all trust-equivalent keys is the
> preferred one.

What if there are two keys with the same creation time?  What if the
newest key I create is not the one I prefer?  Do I need to lie about the
creation time then?

> So, as a strawman proposal, the way I'd slice it is with two subpackets;
> a "Related Key" subpacket (containing a fingerprint and perhaps a key
> server URL?), and a "Trust-Equivalent Key" subpacket (containing an
> imprint). Both of them can be included multiple times, and all trust-
> equivalent keys should refer to each other, such that they form a set
> rather than a tree or some such.
>
> The preferred key can be found by looking at all keys you have and
> looking up all related keys in them, then selecting all keys that are
> trust-equivalent with the one(s) you trust, and then picking the newest
> valid key from those.
>
> This of course doesn't help with the redundancy between fingerprint and
> imprint in the case SHA256 is used for both and you want to include both
> subpackets; but perhaps gzip compression in transit can fix the issue
> in that case :)

I don't think that splitting the subpacket into two makes any of the
spec, semantics, or implementations substantial easier.  On the other
hand, I can imagine it getting messier: what if I tell you about related
keys that I don't consider equivalent, or the other way around?

And we lose the straight forward compression dkg suggested, and I don't
think we can rely on transport compression to work on armored
certificates, for example, because if two identical fingerprints are not
a multiple of three bytes apart, they will appear differently in the
armored stream.


Best,
Justus