Subject: [openpgp] Requesting the editor to step down

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 17 Apr 2020 12:18:30 +0200

Hi OpenPGP folks,

Five years ago, the OpenPGP working group was reopened. It was chartered as
a "crypto refresh" of OpenPGP, and a decision was consciously made to not add
features beyond that. The newly reopened working group strayed from this goal
quite a bit, got lost in a confused silence, and was closed again due to inactivity.
Despite the formal status of the working group as closed, rfc4880bis is still
being worked on. This work happens on this mailing list, but most of the actual
progress happens on the openpgp-wg/rfc4880bis repository on gitlab:
https://gitlab.com/openpgp-wg/rfc4880bis There have also been a couple of
releases of this spec as I-Ds, and it is used in practice as a reference by
implementors.

Since the original reopening, the role of the editor has been held by Werner
Koch. The formal description of the Document Editor is described in [BCP25] as
"The Document Editor is responsible for ensuring that the contents of the
document accurately reflect the decisions that have been made by the working
group." Following this, I believe the following to be a reasonable set of
expectations towards an editor:

1. Communicate decisions and updates to the working group.
2. Foster cooperation.
3. Work out specification content from group consensus.

Myself and others have been increasingly dissatisfied with the way that all of
these expectations have not been met in the editing process of RFC4880bis. More
subtle attempts at communicating this have failed, which is why I am bringing
the issue up on this list.

I'd rather spare everyone the exercise, but it seems necessary to give a few
concrete examples of this dissatisfaction. Feel free to skip ahead.

==

The repository on gitlab currently has seven open merge requests, that have been
open for many months. Those range from trivial fixes for typos, to dkg's work on
User IDs and replacement of Revocation Keys, and a fix for a test vector(!) that
received no attention in six months.

On the other side of things, Werner commits his own changes directly to master,
sometimes without any communication.  A recent example from two weeks ago, was
the introduction of a new "key block subpacket":
https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/30d8397c9fd304691d5628813a38cd61389c76c7
Regardless of whether this mechanism is a good idea (it probably is), or whether
the spec wording is good (is "key block" the best term?), there was no attempt
made to find consensus about it, on this list or elsewhere. (This feature was
also implemented into GnuPG on the same day it was pushed to master in the spec,
and released as a backport into GnuPG 2.2.20 just a few days later.)

As noted above, the decision process of whether a proposal makes it into the
spec seems arbitrary at best. But even when consensus is achieved, the actual
editing process is haphazard. In August of 2019, dkg and myself worked out
a draft for "attested certifications". This work found some consensus on the ml
(including from Werner), and eventually led to a merge request:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/20
When Justus Winter and Heiko Stamer reviewed this MR, they found an oddity about
the way that signatures were made, and also two typos.  Despite those issues
that obviously still required attention, Werner merged the MR, leaving no
comment and offering no follow-up.  The typos and cryptographic oddity of the
signature remain to this day.

Facilitation of cooperation has failed as well. On March 19th last year, Justus
Winter opened an issue on the repository saying that he could not build the spec
in its current form:
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/7
Six months after the issue was posted, Werner closed it with the single remark
"I can't replicate that."  dkg reopened the issue, noting that the toolchain
works only on Debian stretch (then already oldstable by a few months), but did
not in fact work on Debian stable. The ticket remains open to this day, even
though the issue itself was eventually resolved with a merge request from dkg
that converted the toolchain to kramdown.

This is not an exhaustive list. I tried to pick examples that illustrate their
points in a clear way, and hopefully relatively free of personal bias.

==

I appreciate the work Werner has put into RFC4880bis, and of course into OpenPGP
in general. However, a document that is published under the ietf-* namespace
bears a quality of officialness, and thus an expectation to reflect consensus of
the working group. The draft-ietf-openpgp-rfc4880bis-* documents do not, in my
opinion and that of several others I have talked to, meet this expectation.

In consequence, I formally request Werner Koch to step down from his position as
editor for the OpenPGP specification.

Of course, this means we will need a new editor. I'm confident that we can find
someone for this role, once the air has cleared a bit.

As a general thought for a way forward, I would suggest to restart work on
RFC4880bis conceptually, in the way it was originally chartered as a pure crypto
refresh.  A good starting point would be for a new editor to bring the original
RFC4880 into a modifiable state with a modern toolchain, to allow work on actual
set of patches going from 4880 to 4880bis. A portion of the changes made on
RFC4880bis so far certainly don't match the chartered "crypto refresh", so it
makes sense to cherry-pick from them in an ordered fashion, with a check for
consensus and implementation status.

I would further suggest to orient future work more on concrete proposals, i.e.
diffs against the spec. By explicitly asking contributors to submit and maintain
concrete patches as a basis for discussion, we encourage contributions that are
better thought out, continuously reflect the state of thinking, and can be
weighed against one another - or combined on their merits - more easily.

I apologize for bringing up this unpleasant topic. Thanks for reading, and
considering.

 - Vincent Breitmoser

[BCP25]: https://tools.ietf.org/html/bcp25#section-6.3

---

From: Ronald Tse <[email-masked]>
Date: Fri, 17 Apr 2020 10:35:48 +0000

Without going into details of these accusations:

1. I disagree with the proposal to remove Werner from being the document editor of RFC 4880bis. My experience with Werner’s openness and expertise in this document has been great.

2. I disagree with the proposal to “start over” a refresh of RFC 4880bis. All existing content incorporated in 4880bis have been attributed to consensus (when the WG still existed), yet this proposal seems to completely overthrow that.

It is hardly Werner’s fault that consensus is difficult to come by in this group. Given that the OpenPGP Working Group has “already” been disbanded, these complaints of participation are unfairly attributed towards the document editor of RFC 4880bis.

The said issues would be better resolved by finalizing the RFC 4880bis document and publishing it.

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Apr 17, 2020, at 6:18 PM, Vincent Breitmoser <look=[email-masked]<mailto:look=[email-masked]>> wrote:

Hi OpenPGP folks,

==

==

- Vincent Breitmoser

_______________________________________________
openpgp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/openpgp

---

From: "Brian G. Peterson" <[email-masked]>
Date: Fri, 17 Apr 2020 05:43:49 -0500

I haven't worked deeply in crypto or PGP related code in many years, so
feel free to discard my comments.  I do work extensively in a large
number of open source projects still, often as a member of the
management team, so perhaps my perspective has some merit.
I'll note that you had two main points here, and they are somewhat
muddled together
- the working group suffered from scope creep
- Werner isn't doing a good job as editor
I think these topics would be best separated.
On the scope creep model, you propose throwing out 4880bis and
replacing it with a new draft, and a whole new process for effectively
creating feature branches around a specific feature proposal.  You
further suggest limiting the scope to the originally envisioned scope
of 4880bis.  
I have no comment on whether narrowing scope to the "crypto refresh"
scope.  I'm not enough of a cryptogrphy coder anymore to have an
informed opinion.

So to deal with scope creep, you suggest discarding this draft.  That
seems extreme, and seems like it would greatly slow what little
momentum the working group has.
You also suggest moving to a feature branch model, where individual
described features would exist in a branch, and the branch would garner
comments and fixes from the working group before being merged to
master.  This is a common pattern among open source projects, so I
doubt many would disagree that it has merit.
On your second point, that Werner isn't adequately fulfilling his
duties as editor, you propose that he give up the title.  I have no
comment on this, as I am not following the details closely enough to
have an informed opinion.
You further give as a reasons that the editor should be "fostering
cooperation" ...  I'm not sure that usually falls to the editor, but
rather to the Chair of the working group.
I have little comment on your desire for better communication.
Different teams communicate very differently.  You want more formal
communication of planned merges of features.  That is a proposal worth
discussion.
The IETF process alllows for multiple co-chairs, but formally has only
one Document Editor.  I'll note that this process predates the wide
deployment of distributed version control systems or distributed text
editors.  In many modern open source projects, more than one person has
the authority to merge changes to master.  I would suggest that perhaps
this is a simpler solution...  
- give more than one individual 'co-editor' status to merge changes to
master
- revise the process to a formal feature branch model, one feature per
branch,for all committers
- revise the process to communicate on this list the intended merge of
a given feature branch, and offer opportunity for review, patches, and
comment   
Regards,
Brian

On Fri, 2020-04-17 at 12:18 +0200, Vincent Breitmoser wrote:
> Hi OpenPGP folks,
> Five years ago, the OpenPGP working group was reopened. It was
> chartered asa "crypto refresh" of OpenPGP, and a decision was
> consciously made to not addfeatures beyond that. The newly reopened
> working group strayed from this goalquite a bit, got lost in a
> confused silence, and was closed again due to inactivity.Despite the
> formal status of the working group as closed, rfc4880bis is
> stillbeing worked on. This work happens on this mailing list, but
> most of the actualprogress happens on the openpgp-wg/rfc4880bis
> repository on gitlab:https://gitlab.com/openpgp-wg/rfc4880bis There
> have also been a couple ofreleases of this spec as I-Ds, and it is
> used in practice as a reference byimplementors.
> Since the original reopening, the role of the editor has been held by
> WernerKoch. The formal description of the Document Editor is
> described in [BCP25] as"The Document Editor is responsible for
> ensuring that the contents of thedocument accurately reflect the
> decisions that have been made by the workinggroup." Following this, I
> believe the following to be a reasonable set ofexpectations towards
> an editor:
> 1. Communicate decisions and updates to the working group.2. Foster
> cooperation.3. Work out specification content from group consensus.
> Myself and others have been increasingly dissatisfied with the way
> that all ofthese expectations have not been met in the editing
> process of RFC4880bis. Moresubtle attempts at communicating this have
> failed, which is why I am bringingthe issue up on this list.
> I'd rather spare everyone the exercise, but it seems necessary to
> give a fewconcrete examples of this dissatisfaction. Feel free to
> skip ahead.
> ==
> The repository on gitlab currently has seven open merge requests,
> that have beenopen for many months. Those range from trivial fixes
> for typos, to dkg's work onUser IDs and replacement of Revocation
> Keys, and a fix for a test vector(!) thatreceived no attention in six
> months.
> On the other side of things, Werner commits his own changes directly
> to master,sometimes without any communication.  A recent example from
> two weeks ago, wasthe introduction of a new "key block subpacket":
> Regardless of whether this mechanism is a good idea (it probably is),
> or whetherthe spec wording is good (is "key block" the best term?),
> there was no attemptmade to find consensus about it, on this list or
> elsewhere. (This feature wasalso implemented into GnuPG on the same
> day it was pushed to master in the spec,and released as a backport
> into GnuPG 2.2.20 just a few days later.)
> As noted above, the decision process of whether a proposal makes it
> into thespec seems arbitrary at best. But even when consensus is
> achieved, the actualediting process is haphazard. In August of 2019,
> dkg and myself worked outa draft for "attested certifications". This
> work found some consensus on the ml(including from Werner), and
> eventually led to a merge request:
> When Justus Winter and Heiko Stamer reviewed this MR, they found an
> oddity aboutthe way that signatures were made, and also two
> typos.  Despite those issuesthat obviously still required attention,
> Werner merged the MR, leaving nocomment and offering no follow-
> up.  The typos and cryptographic oddity of thesignature remain to
> this day.
> Facilitation of cooperation has failed as well. On March 19th last
> year, JustusWinter opened an issue on the repository saying that he
> could not build the specin its current form:
> Six months after the issue was posted, Werner closed it with the
> single remark"I can't replicate that."  dkg reopened the issue,
> noting that the toolchainworks only on Debian stretch (then already
> oldstable by a few months), but didnot in fact work on Debian stable.
> The ticket remains open to this day, eventhough the issue itself was
> eventually resolved with a merge request from dkgthat converted the
> toolchain to kramdown.
> This is not an exhaustive list. I tried to pick examples that
> illustrate theirpoints in a clear way, and hopefully relatively free
> of personal bias.
> ==
> I appreciate the work Werner has put into RFC4880bis, and of course
> into OpenPGPin general. However, a document that is published under
> the ietf-* namespacebears a quality of officialness, and thus an
> expectation to reflect consensus ofthe working group. The draft-ietf-
> openpgp-rfc4880bis-* documents do not, in myopinion and that of
> several others I have talked to, meet this expectation.
> In consequence, I formally request Werner Koch to step down from his
> position aseditor for the OpenPGP specification.
> Of course, this means we will need a new editor. I'm confident that
> we can findsomeone for this role, once the air has cleared a bit.
> As a general thought for a way forward, I would suggest to restart
> work onRFC4880bis conceptually, in the way it was originally
> chartered as a pure cryptorefresh.  A good starting point would be
> for a new editor to bring the originalRFC4880 into a modifiable state
> with a modern toolchain, to allow work on actualset of patches going
> from 4880 to 4880bis. A portion of the changes made onRFC4880bis so
> far certainly don't match the chartered "crypto refresh", so itmakes
> sense to cherry-pick from them in an ordered fashion, with a check
> forconsensus and implementation status.
> I would further suggest to orient future work more on concrete
> proposals, i.e.diffs against the spec. By explicitly asking
> contributors to submit and maintainconcrete patches as a basis for
> discussion, we encourage contributions that arebetter thought out,
> continuously reflect the state of thinking, and can beweighed against
> one another - or combined on their merits - more easily.
> I apologize for bringing up this unpleasant topic. Thanks for
> reading, andconsidering.
>  - Vincent Breitmoser
> _______________________________________________openpgp mailing 
> [email-masked]
-- 
Brian G. Peterson
ph: +1.773.459.4973
im: bgpbraverock

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Apr 2020 18:07:28 -0400 (EDT)

On Fri, 17 Apr 2020, Ronald Tse wrote:

> It is hardly Werner’s fault that consensus is difficult to come by in this group. Given that the OpenPGP Working Group
> has “already” been disbanded

I'm also confused what that means for the bis draft. If there is no
working group, then anyone can submit any kind of draft proposal
as a bis document. But there is no WG, so I don't think the WG
can decide to replace anyone on any draft?

I'm not sure though a "bis" document could replace an existing standard
without a WG behind it? It would seem odd for an AD sponsored document
to replace a WG document ?

As for the editing situation. It is possible that it would be beneficial
for an editor to be added to the document for improved response time to
various edits of the document. Maybe even someone less involved in
openpgp so they can keep their role as much administrative as possible
without technical bias?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Apr 2020 18:33:35 -0400

Paul Wouters <[email-masked]> wrote:
    Paul> On Fri, 17 Apr 2020, Ronald Tse wrote:

    >> It is hardly Werner’s fault that consensus is difficult to come by in
    >> this group. Given that the OpenPGP Working Group has “already” been
    >> disbanded

    Paul> I'm also confused what that means for the bis draft. If there is no
    Paul> working group, then anyone can submit any kind of draft proposal as
    Paul> a bis document. But there is no WG, so I don't think the WG can
    Paul> decide to replace anyone on any draft?

You are certainly right: without a WG, whomever wants to edit a document can
do so.

    Paul> I'm not sure though a "bis" document could replace an existing
    Paul> standard without a WG behind it? It would seem odd for an AD
    Paul> sponsored document to replace a WG document ?

It would violate the rules for an ISE to replace an document that had IETF
Consensus.
An AD sponsored document does get IETF Consensus, so yes, it can "bis" a
now-disbanded WG document.  It is really the only way to do that other than
spinning up a WG, or perhaps, adopting the document somewhere else.
(SAAG?..)

    Paul> As for the editing situation. It is possible that it would be
    Paul> beneficial for an editor to be added to the document for improved
    Paul> response time to various edits of the document. Maybe even someone
    Paul> less involved in openpgp so they can keep their role as much
    Paul> administrative as possible without technical bias?

I strongly agree: more authors produce better documents, up to some n^2
Mythical Man Month limitation.  Three people working together is ideal in my
opinion.

I also think that we disband WGs *WAY TOO SOON*, and it's one of the major
reasons we don't have more Internet Standards.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Apr 2020 11:01:16 +0200

> document and publishing it.

Except for some unimportant details we already had rough consensus on
the I-D a long time ago.  There are even at least 3 interoperable
implementations of the new features.

With the attacks on the keyserver in the last summer there was the idea
to add countermeasures to the I-D.  They are now specified (attestation
key signatures) and I am not aware of technical problems with that
proposal.  I do regularly publish revisions of the I-D to keep it from
expiring.  Since -09 these are in the queue:

722ed9e * Typo fix
30d8397 * Introduce the Key Block subpacket to align OpenPGP with CMS.
669f73f * Typo fix
6fd718d * Revert to the RFC4880 requirement of having a User ID.

Right, the Key Block subpacket[1] has not yet been discussed but I hope
this is non-controversial because it is another workaround for the
keyserver problems and allows for better decentralized use.  Experience
has show that this is very useful and should, similar to S/MIME, not be
done at the MIME level.

Open editorial tasks are:

 - Clarify how MPIs are used with 25519 and X448.
   (Gniibe proposed a change last fall)
 - Add X448
 - Fix some fallout with the recently done markup language change.
 - Final proof reading

Salam-Shalom,

   Werner

[1]
--8<---------------cut here---------------start------------->8---
Key Block

(1 octet with value 0, N octets of key data)

This subpacket MAY be used to convey key data along with a signature
of class 0x00, 0x01, or 0x02.  It MUST contain the key used to create
the signature; either as the primary key or as a subkey.  The key
SHOULD contain a primary or subkey capable of encryption and the
entire key must be a valid OpenPGP key including at least one User ID
packet and the corresponding self-signatures.

Implementations MUST ignore this subpacket if the first octet does not
have a value of zero or if the key data does not represent a valid
transferable public key.
--8<---------------cut here---------------end--------------->8---

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Mon, 20 Apr 2020 11:29:45 +0200

Werner, I think what Vincent meant was that you don't address community
feedback ("The Document Editor is responsible for ensuring that the
contents of the document accurately reflect the decisions that have been
made by the working group.").

That e-mail is an example of that: there is list of things done or to be
done (which is very welcome, I look forward to X448) but zero replies to
the points what Vincent wrote.

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Apr 2020 14:29:17 +0200

> made by the working group.").

Please give an example of an _decision_ made here which is not reflected
in the I-Ds.

Vincent seems to complain that I am not checking the GitLab bug tracker.
It is correct that I only rarely look into the bug tracker; however we
also agreed initially that all change requests should be directed to the
mailing list and not silently to some bug tracker.

If relevant changes to -09 have been posted here and I missed to include
them, please be so kind and repost them. 

Shalom-Salam,

   Werner

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Apr 2020 14:09:44 -0400

> mailing list and not silently to some bug tracker.

That's doubly important given that there is no WG.
There are ways to get the issue updates into the ML.
(It's even possible to have the converse, but its unfortunately complex)

I think that people simply would like to be able to engage you on the list.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ronald Tse <[email-masked]>
Date: Mon, 20 Apr 2020 18:32:19 +0000

Michael, thanks for the constructive conversation.

Paul, a slight clarification is that the bis document was under the purview and work of the WG — but the WG got disbanded while the draft was still underway.

The current draft probably best represents the “previous" consensus of the WG (while it existed).

Since Werner has already listed out remaining issues, I suggest we attack those one by one and freeze the document for publication:

- Key Block subpacket
- Clarify how MPIs are used with 25519 and X448. (Gniibe proposed a change last fall)
- Add X448
- Fix some fallout with the recently done markup language change.
- Final proof reading

As one of the co-authors of the bis, I for one would be happy to volunteer performing edits with Werner.

____________________________________

Ronald Tse
Ribose Inc.

---

From: Justus Winter <[email-masked]>
Date: Tue, 21 Apr 2020 11:46:33 +0200

Werner,

Vincent expressed concerns about *how* you fulfilled the role as the
editor, not *what* you did as editor.  Your response is only about
technical details.

> implementations of the new features.

There is clearly no consensus, not even a rough one, on key aspects of
the draft.  The fact that there are multiple implementations supporting
the features of said draft does not change that.

On the contrary: The official appearance of the draft and the fact that
the main author and editor of that draft also controls the most widely
used implementation is a strong incentive to implement it.  As an
implementation, you need to be compatible with GnuPG, whatever it does.
If GnuPG starts emitting something, you should better be ready to
consume it, otherwise your users will assume that your implementation is
faulty.  But, that is not consenting, that is being bullied.

From the top of my head, areas of major contention are the scope of
changes and AEAD.

> proposal.

Vincent mentioned a major technical problem with this: What is supposed
to be hashed for attestation signatures differs from all other
signatures.  There is no motivation given for this.  This either needs
to be aligned with how other signatures are computed, or properly
motivated.

> keyserver problems and allows for better decentralized use.

Have you considered discussing this with us?

For the record, this idea has been discussed on this list before [0],
and there were concerns raised in that thread.

0: [email-masked]

All the best,
Justus

---

From: Justus Winter <[email-masked]>
Date: Mon, 27 Apr 2020 12:27:37 +0200

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

---

From: Nickolay Olshevsky <[email-masked]>
Date: Mon, 27 Apr 2020 13:46:33 +0300

Hi group,
While it’s almost the same and (mostly) duplicates contents of the previous messages, it adds links to some closed issues in GnuPG bug tracker.
Those seems to be closed absolutely logically, since were pointing to unsupported configurations/non-release GPG versions.
And I don’t think we should mix together development of some project(s) with work on internet draft.

Best regards,
	Nickolay Olshevsky
	[email-masked]

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

---

From: Ronald Tse <[email-masked]>
Date: Mon, 27 Apr 2020 11:42:55 +0000

Since our implementation (RNP) is mentioned, I’d like to clarify our stance — in the past 2 years, we have had zero issues with Werner’s editing of the draft.

From my experience he was always collegial and understanding regarding comments given on this mailing list (and in personal communication).

It seems that a number of objections were raised from personal interactions occurring outside of the list, and those are not representative of all members of the ex-“OpenPGP working group” (certainly not mine). It would be prudent to steer this discussion away from personality attacks.

I suggest that the current draft, which we have had significant consensus for the past many months, to move forward as the outcome instead of “rewriting the bis” which there has been no consensus on. This will resolve the complaints of “the editor is not acting”.

Ronald Tse
Ribose Inc.

On Apr 27, 2020, at 6:46 PM, Nickolay Olshevsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi group,

Best regards,
Nickolay Olshevsky
[email-masked]<mailto:[email-masked]>

...

...

For the Sequoia-PGP team,
Justus
_______________________________________________
openpgp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/openpgp

_______________________________________________
openpgp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/openpgp

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Apr 2020 14:33:03 +0200

Hi!

>     standardization effort.  Werner declined any help, dismissing the

Right, the minutes say nothing about this [1].  However, I remember very
well and just checked with another participant that after the official
meeting you and Neal asked the _GnuPG_ Verein for financial support for
Sequoia development; which was obviously rejected.

Given the continued personal attacks I will just once list a few facts
as background for other readers:

- Neal, Kai and Justus are founding members of the Verein.  Further they
  all were employed by my company to work on GnuPG.

- I have asked them several times to work on assigned tasks including
  pushing forward 4880bis; which they mostly ignored.

- One of them started to talk with the pEp Foundation, a competitor,
  about cooperation falsely pretending to officially speak for my
  company.

- After I rejected the plan to completely rewrite GnuPG in Rust and
  asked for weekly work reports, they moved on to the pEp Foundation.
  There they wrote there own implementation based on the experience they
  collected in the years working at my company.

- I am also quite disappointed to see folks, whom I once considered
  friends, to behave in public like they do now.

Salam-Shalom,

   Werner

[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-verein.git;a=blob;f=office/meetings/gm-2018-02_minutes.pdf
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 27 Apr 2020 09:17:16 -0400

>   friends, to behave in public like they do now.

I have seen this sort of passive-aggressive behavior flare up with
annoying regularity on this mailing list and elsewhere in the community
(and sometimes it's been aimed at me, for reasons I genuinely do not
understand).

I would respectfully suggest that everyone in the community take a deep
breath and think long and hard before hitting "send", and let's please
leave any personal grudges at the door.  We're better than this, all of us.