Subject: [Openpgp-dt] 20211201 DT meeting notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Dec 2021 15:04:47 +0000

OpenPGP DT call 2021-12-01

Present:

     Daniel H
     Gniibe
     Justus
     Stephen
     DKG
     Jeffrey

Agenda:

# https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/61

Addition of AEAD mode identifier to encrypted session key.
Could this be done via AAD? Maybe not.
This relies on non-malleability of PK algs. We should check if there's 
any issue there. (Daniel H. will check)
If/when doing this, try not introduce redundant data.
Action: Daniel H to make a MR based on this.

# General question: has an v5 stuff been deployed?

So far as we know only experiments so far, no real deployments about 
which we need to care (when changing things such as issue #61).

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

Looks good to those on the call. Some approvals hit.

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

s/value/secret/ in the new text but looks good also; gniibe will tweak 
then ready to merge

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

If we merge this one, that raises the question as to whether we should 
allow continued interop with old-style packets (this 2.6.x interop being 
the last justification for that). Some deployed code does currently 
produce old-style packets for backwards compat but maybe now's a good 
time to stop doing that?
Action: Justus will propose two follow-on MRs: one to remove the 
appendix, another to mandate generation of new-style packets.
95 however looks ready to merge.

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

Action: DKG will make a tweak based on the conversation with Daniel H 
and then people can hit approve if they choose as it should then be 
ready to merge.

# https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/44

Fingerprints are fun! We earlier agreed to send full sha256 hashes on 
the wire in all cases but there remains the question as to whether and 
what to show to a human for similar purposes. On the call we figured it 
made sense to say that implementations SHOULD NOT display fingerprints 
to humans, but if they do (and they will) then we can provide a 
recommendation based on Justus' analysis here.

Action: DKG will try turn that into an MR. QR codes can be better than 
this even if they can't always be used, but we think that'd be better as 
a separate document.

Action: Daniel H will write up a description of case(s) where OpenPGP 
fingerprints are vulnerable to a collision attack (rather than a 
pre-image attack).  post it either to issue 44 or to the openpgp-dt list.