Subject: [Openpgp-dt] 2022-02-02 design team notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Feb 2022 14:36:29 +0000

OpenPGP Design Team

2022-02-02

Present:
     dkg
     Paul Wouters
     Daniel Huigens
     Justus Winter
     Stephen Farrell
     gniibe

# Agenda

- Approved MRs with no thumbs-down:
     - 131, 130, 91
     - https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/131
     - ACTION: dkg, make this stronger as per Justus' comment on the MR 
and limit argon2 to only SKESKv5 (corresponding to AEAD encryption) as well
     - https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/130
     - merged
- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/91
   - daniel H: maybe add another ref to fault attacks (cf. eddsa thread 
on cfrg)?
   - dkg: maybe do that later - dkg will create issue for this, can be 
resolved later
   - merged

- Series of related MRs: 128/127/122
- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/128
- merged
    - https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/127
    - merged
  - https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/122
- merged
- justus: still needs a bit more work, which is happening
- open question is: what info param to use for KDF?
- daniel H: same as assoc data for s2k id 253
- justus: use public parts of public key packet?
- daniel H: shouldn't be needed (agreed)
- justus will follow up 
(https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/132), 
hopefully ok to merge that amendment soon

- padding (118)
- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/118
- Paul will pick this up today, then should be ready we hope

- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/129
- can v4 keys make v5 sigs (& vice versa)
- daniel H: thumbs-down on MR but fine with 1st half of MR, has issue 
with changes to subpacket (+1 sez justus)
- dkg happy to split that into easy/hard bits (done on call)
- justus: related issues
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/58
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/79
- after dkg changes on call: approved, merged (#81 is opened to cover 
guidance around mismatched versions)

- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/120
- daniel H: still likes, justus wonders if mutex?
- dkg: happy to raise downward thumb, will modify relaed issue wrt 
guidance (#81)
- justus not convinced guidance useful
- ready to merge, but has a conflict, justus will look at that today 
then paul will merge

- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/102 (gcm)
- daniel H will rebase given the above merges and to handle justus' 
comments, should be ready to go then

- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/114
- people want to keep this even though there'll be a pile of work wrt 
examples

- https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/132
- justus to rebase to current main, then should be ready to merge

- maybe controversial others:
- the age-old FP/KeyID debate (as a novelty, we didn't talk about it 
this time:-)
- do we want self-signature in userid or elsewhere?
- widely used s/w requires for this sometime, but it's nowhere in the spec
- also useful for expiration dates
- if not required, attacker can drop self-sig, losing expiration date
- options (not that well characterised as generated "live" on call):
- 0) do nothing
- 1) say self-sig not required
- 2) document current? convention requiring userid self-sig
- 3) require any self-sig, maybe not in userid (or in addition to)
- dkg: maybe we can split this into bits, not all of which may be 
controversial
- e.g. maybe want self-sig when encrypting-to but not when checking 
revocation-of
- justus, doesn't like (2)
- daniel H: option (1) would require changes to current s/w
- dkg: maybe offer guidance "for max. interop... do <foo>" (guidance may 
differ for v4 vs. v5 keys)
- daniel H: maybe we can be cleaner for v5 keys
- justus: more implementations don't require these sigs for 
encrypting-to vs. those implementations that do have that requirement
- gniibe: might be good to document current convention, maybe do more 
for v5 keys
- gniibe: for v5 keys, not requiring userid is ok, but project position 
may differ
- daniel H: happy to create MRs for any of the above...
- dkg: maybe start with an MR with v5-specific text suggestion?
- daniel H: maybe require a self-sig that has a key flags subpacket?
- perhaps: self-sig with key flags subpacket that applies to primary key
- justus: why include key flags?
- daniel H: to make it clear this self-sig is not just for revocation etc
- justus: <something the scribe missed> could be useful
- good one to discuss at IETF113
- action: daniel H will start a MR, treat this as non-blocking for now 
pending more discussion

- when should we update examples?
- daniel H can generate some as can justus
- correct new examples are good for next I-D but non blocking

- IETF 113 session?
- SF will ask for session, some of us may be physically there, some will not

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Feb 2022 20:07:57 -0500

> and limit argon2 to only SKESKv5 (corresponding to AEAD encryption) as

This is now done, though in the discussion on the MR Daniel Huigens
raised a significant enough objection disallowing Argon2 for SKESKv4
that i've walked it back a bit.

!131 now is just about limiting Argon2 to AEAD for secret key wrapping.

>    - dkg: maybe do that later - dkg will create issue for this, can be 

This is now: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/80

Thanks everyone for the productive meeting on Wednesday!

       --dkg

---

From: Daniel Huigens <[email-masked]>
Date: Tue, 08 Feb 2022 09:47:10 +0000

Hi all,

> - do we want self-signature in userid or elsewhere? (...)

After thinking about this more, I realized that if we're anyway going to
split the guidance between V4 and V5 keys, it would be simpler to,
rather than saying that at least one self-signature "anywhere" is
required, instead just always require a direct-key self-signature when
using a V5 key, if that's what we want to recommend anyway.
We could consider this "option 4", if you will.

I've created a MR [1] which says that, and also adds some guidance for
V4 keys (with the aim of interoperability, and also to have something
to "contrast" the guidance for V5 with).

Let me know if that seems reasonable, or if people still prefer option 3
or some other option, or if people prefer if I split this into two MRs.

Best,
Daniel

[1]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/134