Subject: [Openpgp-dt] 2022-01-12 design team notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Jan 2022 16:38:39 +0000

OpenPGP Design Team Meeting
2022-01-12

Present:

      dkg
      stephen
      jeffrey
      justus
      daniel huigens
      gniibe

- we've been active (yay!) but still creating new MRs (oops;-); we're at 
21 open MRs now

- Q: should we aim to pop out a new I-D? Justus figures too much in flux 
right now, we agree.

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101 (key 
separation)
- Daniel H reports on some issues: they've seen some AEAD messages in 
their DB now, 101 breaks compatibility based on the assumption that AEAD 
hadn't been deployed anywhere, but it turns out some people are using 
this already; it might be possible to "migrate" those messages but...
- gniibe: could be gnupg 2.3 (which supports AEAD messages as an 
experimental feature) on macos/homebrew maybe
- Daniel H: we could change MR to be backwards compatible for those 
cases maybe
- Justus: or we could define a new version of the AEAD data packet
- dkg: do we know anyone involved in macos/homebrew gpg 2.3?
- Justus: not only macos https://repology.org/project/gnupg/versions 
some distros using 2.3 since April 2021 maybe
- not clear how large scale an issue, Daniel H may be able to check DB

- Options:
- 1 - carry on and ignore, it's on them for deploying early
- 2 - keep AEAD enc data packet as-was, add PKESK v5 in a backwards 
compatible manner, for SKESK v5 follow 101 (breaking compat); drop 
requirement for AEAD to be preceded by PKESK or SKESK v5 packets
- 3 - bump version of AEAD skipping/reserving version 1, we define 
version 2 - early deployments less affected

- Daniel H will create an alternative to 101 for option 2 above and 
we'll revisit this next week
- dkg will make an MR for option 3

- Plan: next week we pick one of those and kill the other two

## Fingerprints 
(https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/103 and others)
- Justus: starting coding, considering doing same as v4, truncating fp 
to make a key id
- Justus to propose an alternative

## Raising the bar for new MRs

- for the moment, we agree new non-editorial MRs aren't welcome unless 
they close some other MRs or issues

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/119
- Approved, ready to merge we think

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/115
- Approved, ready to merge we think

## Padding, two alternative MRs
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/118
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/112

- 112 is more complex but better for old stuff, 118 simpler but  needs 
some signal (e.g. all recips have v5 keys)
- dkg proposal: drop 112 and modify 118 to specify some signally
- action: dkg to close 112 and will tweak 118
- grammar needs updating for this (raises other issues)
- maybe add sentence to justify random padding (because we'll get 
comments at last call about that for sure)

Action for editor: please merge approved MRs that have no thumbs down 
(as of now that's 6 out of 7 from 
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=opened&approved_by_usernames%5B%5D=Any)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Jan 2022 15:01:19 -0500 (EST)

On Wed, 12 Jan 2022, Stephen Farrell wrote:

> Action for editor: please merge approved MRs that have no thumbs down (as of 
> now that's 6 out of 7 from 

done.

Paul

---

From: Werner Koch <[email-masked]>
Date: Thu, 13 Jan 2022 17:25:47 +0100

> experimental feature) on macos/homebrew maybe

Actually it is not an experimental feature but we have deployed the code
for long time and got read-only support in the LTS version for quite
some time.  Only then this crypto refresh thingy started to repeat all
discussion, limited the scope by a DT, and increased the scope again.

OpenPGP is on a good way to a design-by-committee spec. :-(

Salam-Shalom,

   Werner

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