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

[Andrew Gallagher <[e-mail]>]

Hi, Daniel.

If we split up, then we have two subpackets with similar/complementary semantics, and which might still end up being used in conjunction with each other more often than not, because in some lookup scenarios one of them may be redundant and therefore could be omitted. But we cannot predict what key lookup methods our correspondents will use. We could define a method that delivers all of our equivalent keys in one convenient response, but this does not exist yet (WKD only strictly allows one valid key per query). And even once it does, our correspondents will not be compelled to use it - so we will still need to support other lookup methods, in which case the fingerprint will be necessary again. A split subpacket design also increases the combinatorics and UX complexity, which is already quite heavy.

I worry somewhat that we are quibbling over O(256) extra bits on the wire, when we are fast approaching a PQC future where keys and signatures are several kilobytes in size each.

A

> On 13 Sep 2024, at 13:01, Daniel Huigens <d.huigens=[e-mail]> wrote:
> 
> OK, fair enough.
> 
> Then, I want to try to go back to my original point: some people want this part, some people don't want it; ergo, should we split it up? :)
> 
> Best,
> Daniel
> 
> On Friday, September 13th, 2024 at 13:56, Heiko Schäfer <[e-mail]> wrote:
>> As Andrew outlined, in some of the existing PKI mechanisms, the fingerprint is currently the best/most specific lookup key.
>> It would seem unfortunate to me not to include the fingerprint in a replacement key mechanism (which is presumably often going to involve client software attempting to do PKI lookups).
>> 
>> Heiko
>> 
>> 
>> On 9/13/24 1:48 PM, Bart Butler wrote:
>>> I’m fairly agnostic on this as long as we don’t make it optional and introduce yet another degree of freedom. One other advantage of not including the fingerprint would be to force implementations to verify using the imprint. But either approach is fine.
>>> 
>>> 
>>> On Fri, Sep 13, 2024 at 11:01 AM, Andrew Gallagher <andrewg=[e-mail] <mailto:On Fri, Sep 13, 2024 at 11:01 AM, Andrew Gallagher <<a href=>> wrote:
>>>> 
>>>> On 13 Sep 2024, at 08:42, Daniel Huigens <[e-mail]> <mailto:[e-mail]> wrote:
>>>> >
>>>> > In the email case specifically, you _could_ take it as a signal to say,
>>>> > "oh there's a replacement key, but I don't know where/which it is,
>>>> > so I need to go fetch this contact's keys again (by email address)".
>>>> 
>>>> Sure, but I’m thinking specifically of the cases where lookup by email address isn’t efficient, e.g. if there is no WKD on the domain and there are a number of fake keys on the keyservers. If we compare with the design goal of trying to match the behaviour of subkeys as much as possible, leaving out fingerprints does complicate the lookup process in the general case.
>>>> 
>>>> A
>>>> _______________________________________________
>>>> openpgp mailing list -- [e-mail] <mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>>> 
>>> 
>>> _______________________________________________
>>> openpgp mailing list -- [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
> 
> _______________________________________________
> openpgp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]