[openpgp] Re: v4+v6
Daniel Huigens <[email protected]>
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <pqDtD7ijVDDwTGXYkwZa3yzFy56991hF-x335z-Hg9a0O2RIwPEufbptux5DUYiOBAO5C0_eVUxi-wNTm5YdzR5VoVoEARWecoNm-lsq_cI=@protonmail.com> |
On Monday, February 10th, 2025 at 15:09, Neal H. Walfield wrote: > Perhaps I'm missing something, but I think this is the same level of > complexity as computing the imprint. My thinking was the complexity would be more around expanding HKP servers and clients to be able to look up keys by some new field, for example. Obviously it's not very difficult work but still to coordinate everything might be a bit of a pain. > Lots of update requests are wasted in the sense that they return > nothing. For instance, how do we learn whether there is a key > replacement subpacket? We have to periodically check for updates (or > wait for them via, e.g., an in-band signaling mechanism). Most of > these checks return nothing, and that is okay, I think, but they do > serve a purpose: they help ensure that our local state is fresh. Yes, that's true, but at least for a normal key update lookup, you know that if the key server has it you'll find it. Checking for a v6 key that shares some key material with a v4 key doesn't ensure that your local state is fresh, since the key holder might have a different v6 key with completely new key material, for example. > Interesting observation. My impression is that the replacement key > subpacket introduces some complexity both for users (arranging the > cross signatures), and for the implementation (checking the various > constraints). I think I need to play with an implementation a bit. Fair enough, I also haven't implemented it yet so it's hard to say. > Thanks for your comments! Thanks for the interesting proposal! :) Best, Daniel _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]