ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Requesting the editor to step down

2020-04-27 05:28:01
Fellow OpenPGP developers,

Vincent's email has resulted in a number of discussions among the
Sequoia team.  I believe that we roughly share the same opinion, and
I'd like to share that with you in this note.

In an increasingly heterogeneous computing landscape, having multiple
interoperable implementations is becoming an ever more important goal
for OpenPGP.  Incompatibilities are bound to confuse or anger users,
making them leave the OpenPGP ecosystem.  A common protocol and
interoperable implementations are a core concern of our effort.

Although we are working on a general-purpose OpenPGP implementation,
we take the position that multiple implementations are better for the
ecosystem.  Hence, we are convinced that a working group that includes
all stakeholders is essential to our individual and shared success.

From the top of my head, these are a few ways we tried or are trying
to improve the situation:

  - At the general meeting of the GnuPG e.V. in 2018 (Brussels,
    2018-02-02) we asked if and how we or the Verein can help the
    standardization effort.  Werner declined any help, dismissing the
    fact that help is needed.  He mentioned that there is a
    interoperating implementation (RNP) with respect to the largest
    change (the addition of AEAD), so rough consensus had been
    reached, and the finalization of the RFC was imminent.
    Unfortunately, there is no transcript that we know of.

  - We repeated that question in the following year at the 2019
    general meeting (Brussels, 2019-02-02).  It was again declined.
    There is no transcript that we know of.

  - We tried to collaborate on the RFC4880bis draft, but our
    contributions were largely ignored as Vincent described.

  - We created an interoperability test suite [0].  This test suite
    has been successful in identifying problems in many OpenPGP
    implementations.  We reported the problems that we found in the
    different implementations, and the response was almost universally
    positive.  The exception was the GnuPG project, where Werner
    outright dismissed any findings ([1], [2]).  Now, Werner is free
    to dismiss contributions in his personal project, but this alone
    should raise some red flags.

    0: https://tests.sequoia-pgp.org/
    1: https://dev.gnupg.org/T4725
    2: https://dev.gnupg.org/T4727

However, as editor of the RFC, he cannot treat contributors to OpenPGP
as he treats potential contributors to GnuPG, e.g., closing bug
reports with the reason "spite" [3].  The recent addition of the "key
block" subpacket to RFC4880bis which he committed on the same day as
the implementation in GnuPG suggests that Werner thinks that he has
the authority to change the standard like he changes GnuPG.  Changing
the standard should be a group effort, which we tried to engage in,
but were blocked by Werner.

  3: https://dev.gnupg.org/T4904

As the editor, Werner acted inconsistently.  For example, he cannot be
bothered to read and follow up on the merge requests and issues at the
Gitlab project he uses to work on RFC4880bis, saying that we agreed to
discuss any issues on the mailing list.  On the other hand, he quietly
works on the draft without involving the mailing list, requiring us to
pick up on changes by inspecting his repository.

With respect to the content, we can observe similar inconsistencies.
Over four years ago, the draft was changed to make user ids on
certificates optional [4], but just last month, Werner "clarified"
(sic), without any discussion, that this was not meant for general
purpose implementations, presumably to back his dismissal [6] of a patch
improving interoperability with https://keys.openpgp.org.  On the other
hand, he dismissed any changes to the AEAD encrypted data packet because
there are already implementations out there [7].

  4: 
https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/3c3120a02d7b44621f3a7361ef75bdb7b7ade259
  5: 
https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/6fd718d39fc8db20e4731350899db1b7c48c721e
  6: https://dev.gnupg.org/T4393
  7: https://mailarchive.ietf.org/arch/msg/openpgp/J428Mqq3-pHTU4C76EgP5sPkvtA/

We'd like to add another crass example to Vincent's list of examples
where Werner ignored questions, contributions or advice.  In the
aftermath of the EFAIL discoveries, there was a meeting of security
experts and implementers in the offices of the German BSI on
2018-06-29.  There were over two dozen people present including the
EFAIL authors, Phil Zimmermann and some people on this list (maybe
people that were present could corroborate the following anecdote).

The meeting started with the authors of EFAIL presenting their work
and potential solutions.  With the exception of Werner, everyone was
in agreement that EFAIL is a protocol and implementation issue, and
that a good solution would be to use AEAD to detect manipulated
ciphertext.  Werner disagreed.  He dismissed the EFAIL findings as a
MUA problem, and the solution as unnecessary.  A large part of the
meeting was then spent discussing Werner's position. Werner refused to
budge despite everyone else being in agreement on the major points.
We are not keen on rehashing the chunk size discussion here, but the
reccurring theme is that Werner dismisses contributions that he
disagrees with.


We have great respect for Werner.  For over two decades, he kept
OpenPGP alive in the form of GnuPG, despite the many, many naysers.
That's a forlorn fight.  And, we think it is worth noting, that we
have this respect for him despite the tragic ending to our
collaboration on GnuPG and our friendship nearly three years ago.

Unfortunately, we fear that what made Werner so strong---his ability
to discard criticism and focus on what he thinks is correct---makes
him unsuited to be in a position that requires consensus building,
which, as we understand it, is the fundamental role of the editor.  We
very much want to see OpenPGP evolve, but are afraid that Werner's
role as the editor is an obstacle to this.

We support Vincent's suggestion to restart work on RFC4880bis by
starting from RFC4880 and incorporating only changes in line with the
working group's charter.  We would be happy to contribute to this
effort.


For the Sequoia-PGP team,
Justus

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp