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

[Bart Butler <[e-mail]>]

Not to expand the scope even more, what about an optional HTTP URI field instead to fetch the key? Thus could presumably handle both WKD and HKP backends, as well as simple web hosting of a file. Imprint used to verify content.
On Fri, Sep 13, 2024 at 3:43 PM, Andrew Gallagher <andrewg=[e-mail]> wrote:  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]>
      wrote:
       On 13 Sep 2024,
        at 08:42, Daniel Huigens <[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]

        To unsubscribe send an email to [e-mail]

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

        



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