Re: [openpgp] Requesting the editor to step down

Justus Winter <justuswinter@gmail.com> Mon, 27 April 2020 10:27 UTC

Return-Path: <justuswinter@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299B63A09B0 for <openpgp@ietfa.amsl.com>; Mon, 27 Apr 2020 03:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiNvMLPAkx5P for <openpgp@ietfa.amsl.com>; Mon, 27 Apr 2020 03:27:43 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731613A09BB for <openpgp@ietf.org>; Mon, 27 Apr 2020 03:27:42 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id k1so19928150wrx.4 for <openpgp@ietf.org>; Mon, 27 Apr 2020 03:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=qJVHH8PBV+JrmZOGKamdtapKZRzI/lttwW7esEH9W1c=; b=rbILeQd03FADPAk4rXS2kw6i7KreCdbhzFD/yKgP7OO83zVIJh8YA9fyEMva/mMhsU beRy5YKvASNdI3/iMAIGx8qh8LFqVC4RGsiiwRAyuntCtjHd0ssatvSpIX1RyaH8H96G pdlaPUNZTXgJgRikgkjtB7xclqaV8x9NTwb+76Gbkok6GlSNiYFEcoE/AeVMmkkhG31V ukY4Kwf1p9aScgeSl6i5Uu0xargxvc+vD3g0mw5k4nqQ8qQMs5AMl8eud3h87KXrYxqJ fIF6ZGBupO6jvFEs1675/TZTSyK7m0K1oQnd1MOL1xJikRLnXECLvbX01ZGxKwoJVw89 hEYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=qJVHH8PBV+JrmZOGKamdtapKZRzI/lttwW7esEH9W1c=; b=ZeebOCaACHMnqiUjo2ZyX2m6QIximxdci1Nnn7VeET0DVEPUeW6nvD3R9mcgB7l9yb Wn0LArTbAmTKnjWgp+Rf1zy4Vhm0GSwvXuLsrESpV1Itt75TByX/SyldKLbm5CiBONnh FSosqeTt2YMxZMtVWPc4Tqaw7oX9bj+wYwhC+tZ2pibrFXimkB7BbuP3b6p8YY7qx082 sTdzUtSM29eU9WNDM1NGsWhkSKpDIf1OmjRXA+VtSZ0I3LYab7PLRjAZ2DQCG82lttha skGiEyq8K5Kzc1ydaU3ShGyySp9EmOq/VBv+nE3aWdYtKrYxGPTeIzrifJKOmdlqYdfX D2QA==
X-Gm-Message-State: AGi0Pubttg+g04/liodvRmLIC7jFc3p1xotSNp49hH0GC427B+2IqWz5 btG78BngPVCHzFmdzGV8Z7NuD/ch
X-Google-Smtp-Source: APiQypLJSQQ6QQt/wBngFxL5+TRJHz9TwOMJgfHHe7jzaYoXmasjlGQoFHce4+Wilh1CWIs3nHTo9Q==
X-Received: by 2002:a5d:664f:: with SMTP id f15mr25498553wrw.72.1587983260501; Mon, 27 Apr 2020 03:27:40 -0700 (PDT)
Received: from localhost (port-92-193-52-218.dynamic.as20676.net. [92.193.52.218]) by smtp.gmail.com with ESMTPSA id t2sm15510512wmt.15.2020.04.27.03.27.38 for <openpgp@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 03:27:39 -0700 (PDT)
From: Justus Winter <justuswinter@gmail.com>
To: openpgp@ietf.org
In-Reply-To: <3J6ZOTPGPXG6Y.2JRNW7TO2C5HZ@my.amazin.horse>
References: <3J6ZOTPGPXG6Y.2JRNW7TO2C5HZ@my.amazin.horse>
Date: Mon, 27 Apr 2020 12:27:37 +0200
Message-ID: <877dy1ql46.fsf@europa.jade-hamburg.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/QlVNNQIKn2qQOWwWUBcSS6B42Qw>
Subject: Re: [openpgp] Requesting the editor to step down
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 10:27:45 -0000

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