Subject: [Openpgp-dt] meeting notes 2021-09-24

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Sep 2021 11:08:10 -0400

Hi folks--

Notes from today's DT meeting below:

OpenPGP Design Team Meeting
2021-09-24

Present:
	* dkg
	* sftcd
	* Justus Winter
	* Daniel Huigens
	* Paul Wouters

Agenda
------

# normalizing/tablifying existing specifications

dkg made MR !64 as an attempt to put the existing draft into tables.  Please review!
Justus commits to reviewing on Wednesday
Huigens will also review

# curve448

a series of trivial open questions on #37 -- please give feedback

We want to get consensus on the choice for 448 ("option 8"?) on the design-team list in the next week or so.

stephen will nudge GnuPG folks to weigh in on the list.

# Ed25519 clarifications

issue #48 suggests a minor bit of text could help a new implementer choose the right variant of both ed25519 and ed448.

# DT membership

SF dropped the chair-ball and forgot to swap out Werner and Gniibe. Fixed that during the meeting and have started a thread on meeting time slots to better match currently active DT membership.

# Possible meeting at IETF-112

The DT hope to emit a new I-D in time for discussion at IETF-112 so we've asked for a short meeting slot there but may decide to cancel that or move to a WG interim after IETF-112 depending on the list reaction to the DT output and the timing of the I-D emerging.

# Key sanity checks

Justus thinks that the proper mitigations are uncontroversial.

# S2K usage octets

!52 needs review & possible merge

this seems necessary for getting AEAD-protected private keys
dkg suggests that this might be another place where it would be useful to make an explicit table

# AEAD-protected private keys

what should be the AD for an AEAD-protected private key?
Huigens proposes that the AD should cover the body of the key packet
Justus: either include a normalized packet framing, or don't include the packet framing at all.  Doing whatever the fingerprint hashing does makes sense

4880bis-draft-10 includes a number of other data elements, but not the full key packet.

Do we have someone willing to propose a MR for this?  what needs to land before we do this?

Huigens volunteers to make a MR to propose a specific choice -- the MR might supercede !54, or depend on it -- and should be orthogonal to !53

dkg will look at !54 and try to clarify what's happening there

# Argon2 (new S2K)

stephen notes this is now RFC9106

Huigens has volunteered to make an MR for this

# S2K deprecation

Huigens & Wouters ask if we can deprecate old S2K types.
we can't remove them because of stored data, but we can tell people to not generate them.
dkg will offer a MR for deprecation of generation of older S2K types (this might be related to or supercede !42)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 27 Sep 2021 23:16:37 -0400

Following up on the bits assigned to me and noting how i've mapped some
of last week's meeting into the gitlab tracker:

> Justus commits to reviewing on Wednesday

I've added @twiss and @teythoon to the list of assigned "reviewers" on
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/64

> a series of trivial open questions on #37 -- please give feedback

There seems to be a rough consensus emerging on
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/37 for these trivial
issues:

 - use PureEdDSA in all cases, but using the OpenPGP hash of the input
   as the PureEdDSA "message"

 - always use the empty string as the "context"

 - use the RFCs from RFC 8410

 - use "X448" for the ECDH variant

 - EdDSA secret keys are 57 octets; X448 secret keys are 56 octets.

If any of these seem wrong to you, please speak up, either here or on
the gitlab issue!

> issue #48 suggests a minor bit of text could help a new implementer choose the right variant of both ed25519 and ed448.

I've proposed some text to make this as unambiguous as i could make it:

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/68

> this seems necessary for getting AEAD-protected private keys

I've rebased this to ensure it applies cleanly -- it rebased without any
manual intervention.  it'd be great to see it merged, as it's already
approved by Daniel Huigens.

> dkg will look at !54 and try to clarify what's happening there

!54 includes several things, despite being named "v5 SKESK AEAD" -- it
includes v5 SKESK, changes to secret key protection, feature signalling,
MTI decisions, and adjusted text about the MDC (which will have no
future expansions).

I've broken out *just* the v5 SKESK AEAD mechanism (and associated test
vectors) into its own MR:

   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/70

I think it's uncontroversial and if folks will review it we can probably
land it before the next IETF meeting deadline (or, maybe a review will
raise concerns that need to be addressed).

> dkg will offer a MR for deprecation of generation of older S2K types (this might be related to or supercede !42)

!42 was already mostly/kinda incorporated into the text by paul, so i
closed it (with a comment).

I've opened https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/69
for a more explicit deprecation of older S2K types.

Please speak up on the list or in the issue tracker when you get a chance!

    --dkg