Subject: [Openpgp-dt] 20210813 meeting notes

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Aug 2021 16:44:28 +0100

OpenPGP Design Team

2021-08-13

present:
dkg
stephen
justus
werner
jeffrey
paul

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/59
We're aiming to break the back of this tricky one today if we can.

chunk size seems to be a main bone of contention.
- is limit of 56 the right choice?
- what does "MUST support" mean?
- how does chunk size relate to a streaming interface?
- what are the downsides of small chunks?
- what are the downsides of large chunks?
- how much needs to be stored in memory?
- should there be a configurable chunk size?

wk: larger buffers make decryption faster because of parallelization
justus: really large buffers fail to fit in memory on some machines
wk & justus: we cannot presume that the overall size of the packet is 
known in advance
paul: we need to ensure that some implementations do not generate 
packets that others cannot decrypt.
wk: i would be fine with a 4MiB upper limit on chunks (chunk size: 16)
paul: what about smartcards? (answer: smartcards are reserved for 
asymmetric, this is symmetric)

wk: i'd be fine with 16
justus: chunk size octet value of 16 is fine with me.

sftcd: propose: your implmentation SHOULD be able to emit or 
receive/process a packet with chunk size 16
werner proposes MUST NOT support a value larger than 16
ACTION: Paul to propose wording for that.

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/55

Intended Recipient seems to have consensus of everyone present
Editor hit merge during call