Subject: [Openpgp-dt] notes from 2022-02-23 OpenPGP Design Team meeting

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 23 Feb 2022 16:47:56 -0500

Hi folks--

We had a productive, smaller-than-usual meeting today.  i think we're
very close to having a draft ready for release.

OpenPGP Design Team meeting

2022-02-23

present:
    dkg
    gniibe
    justus
    paul

# Agenda

What is needed before a release?
- padding confirmation (see commits in main branch)

- aead / aed-algorithms are broken references (see
  https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/118#note_846026046)
  - fixed during meeting.

- broken ascii art tables (maybe this was only in an old branch) -- this
  is probably a chrome/chromium problem, not our problem, see
  https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/89

- discussion around !138 (SKESK key separation) -- after discussion, no
  concerns with the proposal cryptographically, but justus needs some
  time to re-generate the test vectors

ACTION: dkg to add a justification to the commit message and re-push,
  justus and gniibe and paul to review the commit message

- we need to clarify which versions of PKESK and SKESK belong with which
  version of SEIPD (#79)

ACTION: dkg to make an MR with a new table (see
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/79)

- #85 - AEAD MTI

  !137 discussed and merged on the call: OCB is now mandatory-to-implement.

- #67 -- Using KWP for ECDH, instead of the current spec.

  gniibe thinks this is better, and is willing to propose a change
  before the IETF, but doesn't expect it to be merged before the cutoff.

  dkg raises possible interoperability concerns -- how will the
  encryptor know which to use?

  justus observes that this seems similar to the different RSA
  encryption mode (OAEP, half of #22)

  dkg suggests that for ECDH-KWP and RSA-OAEP we could say that v5 keys
  use KWP and OAEP; other alternative would be to use feature flags

  justus prefers feature flags over binding to v5

  Either way, these changes are not going to land before this coming
  draft. (so they probably won't be bound to v5 keys)

  RSA-PSS (signatures) would be handled differently (Justus suggests a
  dedicated signing-only pubkey algorithm identifier)

- We don't see any other significant changes before this draft comes out.

- Additional test vectors wanted (might not be necessary before the next
  draft, but it would be nice to have):

  gniibe suggests a password-protected secret key
  (https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/90)

  v5 signatures
  (https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/92)

  v5 PKESK
  (https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/93)

Thanks to everyone for their ongoing work!

  --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 24 Feb 2022 22:06:04 -0500

>   justus and gniibe and paul to review the commit message

This has been done on !138 -- please review!

> https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/79)

This is https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/143

In the course of doing this documentation/clarification work, I realized
that the key ID must remain at 64 bits for any key that can receive an
SEIPDv1 message, because PKESKv3 requires 64-bit key IDs.

So the final commit of this series
(775d21a091ddfe2bb58e6e90d21d1c08028ae2a5) reverts the change to a
96-bit key ID from !123.

Here's my rationale in the commit message:

    Consider the case of encrypting a single message to two keys:
    
     a) a v4 key that has not indicated support for v2 SEIPD and
     b) a v5 key
    
    This can only be done with v1 SEIPD, and since (a) does not support v2
    SEIPD.
    
    But a v1 SEIPD packet MUST be preceded with v3 PKESK, and a v3 PKESK
    by definition uses a 64-bit Key ID.
    
    A 96-bit key ID of (b) cannot be encoded in the PKESK packet, which
    makes it impossible to encrypt the message to both recipients.

It is distressing to me that i'm effectively re-opening the wound about
human-unfriendly cryptographically-reasonable handles for v5 keys (#44,
again), but i think it'll need to be solved in some other way than
increasing the key ID to 96 bits.

I believe that all of my work in this series aside from this last commit
are merely clarifications.  That is, i don't think i introduced any new
concepts or requirements from what we've been talking about, so i felt
compelled by the situation to revert the v5 key ID length back to 64
bits.

But of course, i could be confused or simply wrong.  I welcome
corrections!

        --dkg

---

From: Justus Winter <[email-masked]>
Date: Fri, 25 Feb 2022 13:50:36 +0100

> This has been done on !138 -- please review!

Looks good.

> This is https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/143

Looks good.

> But of course, i could be confused or simply wrong.  I welcome

Sadly, that is a good reason to revert the change.

I think we will have to accept that we failed to resolve this problem
and move on.  Existing tooling that currently displays fingerprints will
display even larger fingerprints in the future.

I have committed support for v5 fingerprints in Sequoia just this week,
and it will format v5 fingerprints as 64 hex digits for human
consumption (as in "print(fingerprint)"), or 80 hex digits with spaces
if the user requests even more human-friendly output that groups the
digits in groups of four.

I don't think that this is a great outcome, but I don't see any other
way to deal with that as an implementer.  Most importantly, I don't want
this issue to hold up the standardization process any further.

Justus

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Feb 2022 21:01:21 -0500 (EST)

> This has been done on !138 -- please review!

I've merged it, as it basically had 4 approvals (Daniel who created the
text, dkg who agreed other than the commit message he updated, Justus
with an approval, and me).

> This is https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/143

This still needs some more approvals.

Paul