[Openpgp-dt] 2022-05-12 meeting notes

[Daniel Kahn Gillmor <[e-mail]>]

Notes from today's meeting follow.  We managed to build consensus on a
number of outstanding MRs and deepened our understanding of a separate
issue.

Remember, we'll also meet again tomorrow at 14:00 UTC.

OpenPGP Design Team meeting
2022-05-12

Present:
	* dkg
	* stephen
	* gniibe
	* daniel huigens
	* justus

# Agenda

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/183
	- has approvals, maybe editorial concern
	- dkg proposes tweak in comments to MR
	- justus: we should also say to reject v5 keys that don't do the right thing for these curves, dkg added another bit to comments
	- those should resolve Paul's issue
	- TODO: justus to update accordingly then Paul can merge

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/186
	- depends on #183
	- meat of that is "To register a new elliptic curve for use with OpenPGP, its OID needs to be registered in {{ecc-oid-usage}}, its wire format needs to be documented in {{ecc-wire-formats}}, and if used for ECDH, its KDF and KEK parameters must be populated in {{ecdh-kdf-kek-parameters}}."
	- has to be merged after 183 (has been modified) #
	- TODO: dkg to align with #183 after the above change done then should be ready to merge
	
## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/185
	- fixes numeric typo, has approvals, ready to merge
	
## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/103
## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/106
	- these are two alternatives (at least partly)
	- hey, it's fingerprints! ;-)
	- proposal: drop 103, rebase 106 and take out line about additional studies (and handle merge conflicts)
	- TODO: dkg to do the above, then we think it should be good to go
	- we'll need approvals/remove thumbs-down when that's done

## https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/180
	- looks good, but might need an editorial pass, can be done at WGLC
	- there are some comments in the MR that'd be good to handle before merging (e.g. should->SHOULD)
	- has approvals
	- TODO: daniel to chase up with Lara before asking Paul to merge
	
The above exhausts our MRs for today, so issues... (we have 39 open)
	
	List of interesting open issues: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/?sort=created_date&state=opened¬%5Blabel_name%5D%5B%5D=unchartered¬%5Blabel_name%5D%5B%5D=test%20vector
	
## https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/117
	- seems like a nice-to-have (or better)
	- an MR based on this seems useful but needs nuance to get it right 
		- could approach it by saying what's disallowed where and how to handle that (at the risk of disagreeing about when to ignore or reject in some cases)
		- could approach it by saying when compression is allowed and how to handle other bad uses of compression
		- much bigger question: how should we handle unknown/surprising packets?
		- TODO: dkg to create a tightly scoped MR specific to compression
		- TODO: dkg to open a ticket about lenient parser vs. strict parser (e.g. https://tests.sequoia-pgp.org/#Malformed_messages) -- there might be room to generate an encrypted message that different implementations will yield different plaintext.
		- justus: prefers to answer bigger question (via a more comprehensive grammar)