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
- [openpgp] Requesting the editor to step down Vincent Breitmoser
- Re: [openpgp] Requesting the editor to step down Ronald Tse
- Re: [openpgp] Requesting the editor to step down Brian G. Peterson
- Re: [openpgp] Requesting the editor to step down Paul Wouters
- Re: [openpgp] Requesting the editor to step down Michael Richardson
- Re: [openpgp] Requesting the editor to step down Werner Koch
- Re: [openpgp] Requesting the editor to step down Wiktor Kwapisiewicz
- Re: [openpgp] Requesting the editor to step down Werner Koch
- Re: [openpgp] Requesting the editor to step down Michael Richardson
- Re: [openpgp] Requesting the editor to step down Ronald Tse
- Re: [openpgp] Requesting the editor to step down Justus Winter
- Re: [openpgp] Requesting the editor to step down Justus Winter
- Re: [openpgp] Requesting the editor to step down Nickolay Olshevsky
- Re: [openpgp] Requesting the editor to step down Ronald Tse
- Re: [openpgp] Requesting the editor to step down Werner Koch
- Re: [openpgp] Requesting the editor to step down Robert J. Hansen