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

[Bart Butler <[e-mail]>]

I’d also be fine dropping the fingerprint and just keeping the imprint. I had a slight preference for having both in the meeting but I’ve changed my mind and decided that simplicity wins :)
On Thu, Sep 12, 2024 at 6:48 PM, Daniel Huigens <d.huigens=[e-mail]> wrote:  Hi Justus :)

On Thursday, September 12th, 2024 at 16:51, Justus Winter wrote:
> 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.

OK, fair enough. The draft talks about "key equivalence", and "bound-
equivalent", and just "equivalent". I think those are vague terms;
in my mind a v4 and a v6 key (or an ECC and a PQC key, and so on) are
obviously not equivalent in every way; the sense in which they are
equivalent is mainly that if you trust (in "my" terminology, see below)
one of them you can also automatically trust the other one. Hence,
trust-equivalence.

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

:D

> 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).

OK, perhaps I'm leaking Proton-specific terminology. In Proton Mail,
trusting (or pinning) a key means the former (and yes, the trust in the
key is specific to the email address of course). We don't have any
support for the latter concept.

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

I personally tend to agree but the draft talks about this [1], so I
thought people wanted it. Personally I don't care about this part of
the functionality of the proposed subpacket, which is why I proposed
splitting it up. But I would also be fine with dropping it entirely.

To be explicit, in concrete terms that would imply (to me) dropping the
fingerprint and keeping only the imprint, and not caring that it can't
be used to look up the replacement key on the web (at least for now).
But I was under the impression that some people do care about that part.

> 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?

I guess so. All of this also applies to subkeys - at least in our
implementations, we select the latest valid subkey to encrypt - I know
Sequoia behaves differently, and unfortunately the spec doesn't say
anything about it, but IMHO this behavior makes the most sense,
_especially_ when dealing with migrations to a new algorithm that not
everybody may support yet: up-to-date senders get the security benefit
by selecting the latest subkey (with the introduction of this subpacket,
across multiple TSKs), out-of-date senders are still able to encrypt
with an older subkey.

All of it also applies to subkey and user ID binding signatures, where
we select the latest valid one as well (and that part _is_ codified by
the spec). Obviously there are wrinkles and edge-cases for all of this,
but I don't think that makes it a bad policy in general.

> 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

There may be some use case for this, like saying: here's my other key,
but please use your WoT model (or w/e) to determine whether you want to
use it. But I'm not the best person to ask about this one as I don't
really care about having that part at all.

> or the other way around?

This one I did give a use case for: if you fetch two keys from WKD v2,
and the user has indicated their trust in the (email, cert) binding for
the first one, then you can also use the second one automatically
without asking the user about it.

For that, you don't need the part that refers to another key that can
be looked up externally, as the other key is right there in the response.

Just to be explicit, this is also the main use case I care about, FWIW.
So folks that care about a different use case may disagree with me,
of course :)

> 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.

Yeah, that's true. I mean, again I would be happy to drop the first one,
but others may disagree. I guess it's up to them to say whether they
think the overhead matters, not up to me.

Best,
Daniel


[1]: https://www.ietf.org/archive/id/draft-ietf-openpgp-replacementkey-00.html#section-3-2

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