Subject: [Openpgp-dt] first set of PRs created from step-by-step branch

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Jul 2021 11:27:22 -0400 (EDT)

Hi,

As agreed, I've started creating branches for each topic and created
PRs for these. I've not yet created a PR for the branch "v5-keys-aead"
as it depends on the merge of branch "v5-keys".

I've also stopped creating more branches for now, as it makes my life a
lot easier if we first pull in the v5-keys and aead, as otherwise I'm
just counter-massaging these branches for conflicts only to have to
de-conflict them later on the merge again.

Please leave your reviews at the PRs and then one of the Editor's
(Werner or me) will merge them if there are enough positive reviews
and no negative reviews after a couple of days.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 23 Jul 2021 20:08:12 -0400

Thanks for doing this, Paul!

> as it depends on the merge of branch "v5-keys".

With no hats on, I reviewed these branches, and i've tried to mark
things as "approved" where they seem reasonable.

I think we already have v5 keys in the draft, so i think what you are
calling "v5-keys" is actually "v5 SKESK".

As i wrote over on
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/54, i think
the v5 SKESK and "AEAD-style" S2K #253 really depend on our AEAD
definition, and i think it'll be easier for us to have the AEAD
conversation first.

If you'd like, i can try to propose an alternate, short series that just
includes the current AEAD specification plus the AEAD-specific set of
test vectors.  If we can get consensus on that, then moving through the
v5 SKESK and #253 S2K should be simpler, bite-size pieces by comparison.

If it would be useful, i can also propose a variant of AEAD with many
fewer knobs as a comparison.  Each knob can cause negotiation failures
and deprecation difficulties, and i'm worried that the current amount of
flexibility could saddle future implementations with a lot of technical
debt.

> de-conflict them later on the merge again.

this makes sense, we can always review the outstanding changes in the
step-by-step branch to pull them in once we've tackled the harder stuff.

             --dkg

---

From: Paul Wouters <[email-masked]>
Date: Sat, 24 Jul 2021 08:41:04 -0400

> calling "v5-keys" is actually "v5 SKESK".

Yes, i did.

> v5 SKESK and #253 S2K should be simpler, bite-size pieces by comparison.

That would be good.

> flexibility could saddle future implementations with a lot of technical

How would that interfere with current deployment ? I would like this to be a separate issue on the tracker.

> step-by-step branch to pull them in once we've tackled the harder stuff

I’m still trying to get more text moved in, but yes we can always do that later.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 26 Jul 2021 14:08:21 -0400

>> v5 SKESK and #253 S2K should be simpler, bite-size pieces by comparison.

I've done that over here:

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/59

Hopefully commentary on that MR should be able to be more
tightly-focused than dragging in all the SKESK, preferences, etc stuff.

> How would that interfere with current deployment ?

I think we could win this simplicity and avoid interfering with any
pre-existing deployment by just picking a different "version number" and
documenting that, leaving documentation of "version 1" for some future
document.

> I would like this to be a separate issue on the tracker.

I agree this would be an entirely separate issue, and one mutually
exclusive with the AEAD stuff we're trying to pull in from the old
draft-10.  If anyone else on the design team wants to propose text, i
would be happy to review it.  or, i could take a stab at writing an
example text if y'all want.

If the DT deems this idea too crazy and off-the-wall and disruptive to
current deployments to consider, i'm also happy to drop it.  i'm
proposing it because having a less-flexible option might be a useful
comparison.

      --dkg