ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Requesting the editor to step down

2020-04-17 05:36:14
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=40my(_dot_)amazin(_dot_)horse(_at_)dmarc(_dot_)ietf(_dot_)org<mailto:look=40my(_dot_)amazin(_dot_)horse(_at_)dmarc(_dot_)ietf(_dot_)org>>
 wrote:


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

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

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