[Openpgp-dt] OpenPGP Design Team notes 2022-04-12

[Daniel Kahn Gillmor <[e-mail]>]

# OpenPGP Design Team Meeting
## 2022-04-12

Present:

  * dkg
  * stephen
  * justus
  * daniel h

# Agenda

# actions from IETF-113
  - meeting minutes https://datatracker.ietf.org/doc/minutes-113-openpgp/
  
  ## "Action on chairs: Start thread on mailing list to discuss whether people prefer the changes to modes of operation in -05 or Werner's proposal." - Stephen will try craft a mail on this and run it by DT/Werner before sending to WG list
  ## "Action for chairs: Start thread on the mailing list to discuss preference between a) the tentative proposal for v5 keys (see above) or b) the status quo (possibly better documented)." DKG to craft mail to WG list on that.
  ## "Action: Chairs: Create a thread on this topic (use of sha1collisiondetect as opposed to SHA1)" DKG to craft a mail to WG list on that.
  
# DT timing...
  - we (still) have a bunch of MRs (20 open now) and issues (49), how do we get to done before the universe cools?
  - we'll again ask the DT to do a full trawl of open MRs/Issues, express opinions and esp try to make issues closeable
  - we don't aim to close all issues before we're done (e.g. some will be for potential future work)
  - chairs need to ask Paul W if he still has bandwidth for merging stuff or if he needs help
  - we'd like a deadline: 
    - we'll plan to meet some more (2-3 hours) in the week leading up to the deadline, chairs will do polls for slots that work for DT folks
    - the deadline: 2022-05-13 (implies actions above have similar timing)
  - the GOAL: another draft after that and then WGLC
  
# Risks to interop:
   https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/107
  - Tricky issue, maybe goal here is just that those implementations don't reject message but treat v5 sigs as broken (possibly via ickky cheating as was done with tls versions)? Or, perhaps we do need allow v5 keys produce v4 sigs (sometimes)?
  - Might imply we need better guidance as to what to do when you have both v5 and v4 keys in-play
  - proposal A: give a deadline for having patches for all listed implementations, 
  - proposal B: invent a new way to transport a v5 signature as though it was a v4 signature
  
  We're hoping to get to the patches (A) in a reasonable amount of time.  if not, we can consider (B).
  Legacy implementations still can't reply to a v5 cert, so we expect people to stick with v4 keys for a while.
  Action: identify patches for each existing implementation.
  
  Another outcome of this: certificate lookup mechanisms by e-mail address need to be modified to permit multiple certificates per address.  at least one per primary key version; perhaps one per primary key algorithm?  Concerns about "ghost proposal" key injection for allowing inclusion of arbitrary keys.  What should a recipient do if they receive multiple keys?  use the first key that they can interpret?  use them all?
  
# more discussion around multiple encryption subkeys

there are legitimate reasons for people to want multiple encryption-capable subkeys on their certificate, where each message is encrypted to each subkey?  There are also legitimate reasons for a keyholder to have multiple encryption-capable subkeys where the keyholder wants users to prefer one over the other, but not to encrypt in parallel.  Most current implementations do not encrypt to all encryption-capable subkeys.  Should the keyholder signal their intent?  if so, which way: as a desire for parallel encryption (single encryption is default) or as a desire for single encryption (parallel is the default)?

## Fingerprint vs. wire format key ID

dkg: the spec doesn't need to have a fingerprint for v5 keys at all.  I can make a provocation MR that demonstrates this (e.g. key identifiers within a signature can use the same digest that the signature uses).  The point is that what we've been calling "fingerprint" is used in many places, and they do not need to all be the same thing.

## ECDH KDF params

stats:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/838#note_909813463

proposal: identify the most common KDF parameters for each known ECDH curve, and document them in the spec.  New ECDH keys with that spec MUST use the documented params.