<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 2 Feb 2023, at 08:31, Kai Engert via Gnupg-devel <gnupg-devel@gnupg.org> wrote:<br><div><blockquote type="cite"><br><div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">I'm asking the OpenPGP community to work together and find a standard that works for everyone.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote></div><br><div>I’d like to whole-heartedly second this. It is not only client software that will be forced to make unpalatable decisions if the standard forks, but also keyservers.</div><div><br></div><div>Hockeypuck relies heavily on Protonmail’s fork of gopenpgp. Protonmail are invested in crypto-refresh and will certainly implement the new RFC when it is finalised. Hockeypuck does not have the developer resources to maintain yet another fork of gopenpgp, and so will have little choice but to track upstream. This would mean that the vast majority of synchronising keyservers, including <a href="http://keyserver.ubuntu.com">keyserver.ubuntu.com</a> (gnupg’s default keyserver) would not be able to handle v5 keys created by gnupg. Hagrid's dependency on sequoia-pgp means that <a href="http://keys.openpgp.org">keys.openpgp.org</a> would also similarly be unavailable, leaving gnupg users without a reliable keyserver service. Conversely, keys created using the new RFC could not be processed by gnupg-wks-server, potentially forcing individual users to conform to a domain-wide policy re the split.</div><div><br></div><div>This is not simply a case of a standard forking, because neither side ends up owning sufficient share of the pieces to rebuild a functional ecosystem. This prospect is IMO unthinkable, and would set OpenPGP back by many years, with potentially irrevocable consequences. I don’t believe that the technical disagreements are insurmountable if there exists sufficient political will to bridge the gaps.</div><div><br></div><div>A</div><div><br></div></body></html>