Interoperability with OpenPGP crypto-refresh

[Steffen Nurpmeso]

deloptes wrote in
 <CAJJ4Ra+VMXBdt0B5PodfAgo75VnBNrZXUY6hnbV8BveXRE2GLA at mail.gmail.com>:
 |But that alone seems a poor reason to effectively split the community
 |> and fork OpenPGP (and by that probably help killing it).
 |>
 |> I was thinking exactly the same aside the technical part. At the end
 |community splits, software is not compatible any more and all is broken. It
 |seems it happens every 10y or so with this or that software.
 |Is it so hard to find a way to complete something together? (I ask it in
 |rhetoric way and I do not mean here GnuPG).
 |I hope however, you keep compatibility and user experience as top priority.

4880bis was "current" from 2015 to somewhen in 2021 (says Werner
Koch).  I as a spectator downloaded "draft 00" from July 6, 2016
on the 7th of July 2016.  It includes things like Ed25519.

That is around six full years (for Werner Koch -- to me it became
apparent no sooner but 2022) --- a very long time in software
development.  Software had been written and was in widespread use
for many years.  That is, as i see it, especially the most widely
used implementations ship code for a long time, and are
interoperable in that.  (Werner Koch has explicitly stated this in
a message in this thread.)

I am not an expert regarding OpenPGP.  (And most that i did know
i have forgotten.)  So there might be things that can be improved
in the OpenPGP format on top of what "V5" did say.  Creating
something that is incompatible with what was envisioned as "V5"
i do not understand given the long time that passed.  I would have
understood if some small compatible improvements would have been
made, and anything else been moved to a "V6".  But then i had the
gut feeling that in the working group there was "laughter"
regarding this "V5" / "V6" thing in that everything is "V5" now,
and it is not what was in 4880bis for many years anyway.  Other
participants of the group even create biased compatibility
overviews that looked to me moreover as (helpless, imho) tries to
build up a pressure scenario in favour of crypto-refresh (even
before there was crypto-refresh it could have been).  I find this
overly uncooperative, and anyway outstanding in all the WGs
i (have) track(ed), _for_sure_.

Maybe sometimes a small step is better than a big hit.

P.S.:

#?0|kent:tls-openssl.git$ git grep -i argon master
master:doc/designs/thread-api.md:  - Some algorithms are designed to be run in parallel (Argon2);
#?0|kent:tls-openssl.git$ git log --oneline master -- doc/designs/thread-api.md
d55fc027b9 Add thread pool design document (phase 1)
#?0|kent:tls-openssl.git$ git log -1 d55fc027b9 | sed -e 2,7p';d'
Author:     Hugo Landau <hlandau at openssl.org>
AuthorDate: 2022-07-25 13:51:42 +0100
Commit:     Tomas Mraz <tomas at openssl.org>
CommitDate: 2022-11-14 12:21:22 +0100

    Add thread pool design document (phase 1)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)