Subject: [Openpgp-dt] 2022-01-05 DT meeting notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Jan 2022 14:39:47 +0000

OpenPGP Design Team meeting

2022-01-05

Present

dkg
Daniel H
Gniibe
Justus
Stephen
Jeffrey

Agenda:

# MRs (did we get comments/feedback from everyone?)

- SF was lazy;-)

# list of MR's that are ready to merge, Paul can report back or figure 
out if trivial
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests?scope=all&state=opened&approved_by_usernames%5B%5D=Any 

- Currently: 110, 109, 107, 106, 105 104, 100, 90, 65, 48
- We can ask Paul to merge those

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/99
- we closed this as it's superseded by 107

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/73
- The signed OpenPGP PDUs may be hashed but we are using the standard 
non-prehashe sig scheme so this one is probably best closed
- SF will send mail to WG list so they know that we're closing this

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/74
- If we make this change, we'd need to add more explanation about the 
private key format and why that differs from other related 
specifications. It's therefore better to keep the OpenPGP-specific term 
here as that matches existing already-deployed implementations.
- DT think leaving things as-is is best
- SF will send mail to WG list so they know that we're closing this

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/50
- Even if goal is agreed, proposed text in MR needs a lot of work that'd 
not be worthwhile so we think closing this is best.
- If we wanted to better describe 3rd party certification, that's likely 
better done outside the crypto refresh.
- DKG to close.

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/77
- Some implementations may not have a need for this, some don't seem to 
want it
- DT think closing this is best, maybe create an issue (for later) about 
the difficulties in merging/changing key-ring like things without being 
unsafe or having a horrible UI
- Action: DKG to open an issue about that

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/82
- gniibe says this isn't strictly needed so ok to close really, DT agreed

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/91
- DT discussed this and figure keeping this idea is good.
- This one is analagous to how x.509 cert serial numbers helped with md6 
chosen-preface collision attacks.
- The proposed changes need a bit of git work, so action is on Justus to 
rebase
- Aside: we should check we're STRONGLY deprecating sha-1 (Daniel H to 
check)

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/96
- DT discussed.
- Terms like "consumed" and "interpreted" can be confusing, might be 
better to phrase the change in algorithmic-terms
- Action: DKG willing to try suggest different phrasing for the change 
that doesn't say what skipping over malformed stuff means
- Action: DKG to open an issue about how to handle specific cases of 
encountering malformed packet content

---

From: Paul Wouters <[email-masked]>
Date: Wed, 5 Jan 2022 21:33:03 -0500 (EST)

On Wed, 5 Jan 2022, Stephen Farrell wrote:

> # list of MR's that are ready to merge, Paul can report back or figure out if
> trivial

These have been merged with the exception of:

106 does not have anyone signing off on the MR. It might have seen
approval on the call, but if possible please approve it on gitlab
for me.

90 also seems weak in its approvals while containing a lengthly
discussion. I would like to see more up (or down) votes before
merging.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 06 Jan 2022 18:55:05 -0500

> approval on the call, but if possible please approve it on gitlab

This is the "security considerations on fingerprint usability" change,
the compromise that no one loves but i think we agreed on for moving
forward.  I recognize that it's no fun to "approve" such a beast, but
it's an improvement over the status quo, and it would be sad if we stuck
with the status quo because everyone wants to do better than the
collectively-discussed compromise.

Please review!  Remember also that if we can land the compromise, it
might make it easier to land an improvement that builds on the
compromise, instead of staying stuck.

> discussion. I would like to see more up (or down) votes before

The lengthy discussion on #90 is mostly about speculative future
mechanisms that could replace Designated Revoker.

The point of #90 is just to deprecate Designated Revoker in favor of
*existing* mechanisms (in particular, escrowed revocation certificates),
but not to try to actually offer a novel mechanism (!18 was an earlier
attempt to offer a novel mechanism for replacement, and it was more than
i think the WG wanted to bite off in the short term.  I've "resolved"
the outstanding thread that included much of the discussion about
novel mechanisms to make the point of the MR a bit clearer.

I'd appreciate any reviews on this too!

    --dkg

---

From: Justus Winter <[email-masked]>
Date: Fri, 07 Jan 2022 13:53:22 +0100

> compromise, instead of staying stuck.

I'm sorry, but could you please explain how 106 represents a compromise?
I remember a tension between usability and the need for 128 bits of
collision resistance.  In a compromise, one often deviates slightly from
ones goals to meet somewhere in the middle.  In contrast, in 106 we get
128 bits of collision resistance and no usability improvements.

In fact, my reading of 106 is "we messed up fingerprints, so sorry,
please don't display them to the user ever".  Merging it does not get us
unstuck, it gets us more stuck.

Justus

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Jan 2022 15:06:45 -0500

> better done outside the crypto refresh.

I've closed this, and also offered
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/117 that tries
to capture the useful ideas that it sounded to me like we had consensus
about during the meeting.

> - Action: DKG to open an issue about that

I've opened https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/70 to
describe this problem.

> that doesn't say what skipping over malformed stuff means

This is now:
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/116, which i
think is mutually-exclusive with !96.

> encountering malformed packet content

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

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Jan 2022 15:47:24 -0500

> 128 bits of collision resistance and no usability improvements.

It represents a compromise in the sense of acknowledging that 256-bit
fingerprints can't be used in the way that the community has tried to
use 160-bit fingerprints in the past, rather than just presenting them
as a drop-in replacement.

> unstuck, it gets us more stuck.

I'm not sure how it gets us more stuck; it makes it clear that there is
work to be done here, and (hopefully) clearly acknowledges the problems.
Acknowledging a problem is a reasonable first step toward trying to
actually solve it.

I had originally proposed an attempt to actually solve the problem
(!103) and it got a fair amount of negative feedback during DT
discussion.  I'm open to considering alternate suggestions about how to
solve the real problem you've identified in #44, but i was hoping we
could at least get consensus in the draft that there *is* a problem
first.

      --dkg