Hi OpenPGP folks!
We've talked it over and we've asked Paul Wouters to share the
editorship with Werner Koch for the draft that will hopefully become the
cryptographic refresh for RFC4880. Many other people also offered to
stand in that role, and we thank them for that! Hopefully everyone will
keep contributing to the process so we can fulfill our charter.
We want to incorporate as much of draft-ietf-openpgp-rfc4880bis-10 as is
in-charter, has consensus of the newly-reformed WG, and has multiple,
interoperable implementors, plus whatever work remains in our charter.
Here's how we're thinking of doing that:
- To signal that we're in a "reset", we'll make a new draft,
draft-ietf-openpgp-crypto-refresh, with Paul and Werner as editors.
This new draft will be marked as a replacement for
draft-ietf-openpgp-rfc4880bis-10.
- crypto-refresh-00 (that is, the first revision of the new draft) will
incorporate just the text of 4880, inconsequential editorial updates,
the verified errata of 4880, and incorporation of the relevant text
from RFCs 5581 (Camellia) and 6637 (ECC), so all substantive changes
from 4880 are things that have already been through the IETF document
publication process already.
- We hope to be able to point the list to that -00 document shortly,
and we hope everyone will review it and confirm that it offers no
substantive changes to 4880 beyond those listed above, and that it
faithfully mirrors the already-published documents it incorporates.
The aim for this initial review is not "is this the best possible
text?" but rather "is it a correct integration of already-published
work?"
- If we can accept that crypto-refresh document as a starting point,
we'll have a series of diffs proposed (every week or two) to the WG.
Each cycle will aim to incorporate a specific, thematic set of
changes from 4880bis-10 into crypto-refresh-xx. The editors will
describe the specific theme, propose a coherent diff to the current
draft of crypto-refresh, and the WG will have an opportunity to
comment on that change. If the comments show rough consensus and we
can hammer out any wordsmithing details, the editors will incorporate
the changes. If there are concerns that show that there is no
consensus, we can put that set of changes aside. Hopefully that
won't happen much.
- Our initial changesets might be the easier ones, so that the group
can get comfortable with the cadence and working together again,
focused on the document. Please stay engaged even if the proposed
changes look simple/trivial/obvious to you! A simple "I support the
inclusion of this change" message to the WG is also an important
contribution. (don't worry, we'll get to the harder stuff too).
It's possible (indeed, quite likely) that some of the text currently in
rfc4880bis-10 won't make it into the eventual version of crypto-refresh
that becomes (hopefully) an RFC, whether that's because of a lack of
consensus, being out-of-charter, or not having enough implementers to
show interoperability.
That's OK! If some text that you care about doesn't make into the
revised OpenPGP standard, that doesn't mean we've given up on it -- it
just means that we need to work on it separately from this chartered
work. We encourage WG participants who care about things that might not
make the cut for this version to help get this cryptographic refresh out
the door in an effective way, so that we can recharter the WG in order
to help document the evolving and active OpenPGP ecosystem.
For the chairs,
--dkg and Stephen Farrell
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp