[openpgp] Notes from OpenPGP meeting at IETF 115

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

Today we had an OpenPGP meeting at IETF 115.  We had a good discussion
of issues that have come up during WGLC for
draft-ietf-openpgp-crypto-refresh.

You can find more details about the meeting here:

  Materials: https://datatracker.ietf.org/meeting/115/session/openpgp

  Video recording: https://play.conf.meetecho.com/Playout/?session=IETF115-OPENPGP-20221108-1300

Many thanks to Aron Wussler and Rick van Rein for taking notes which i'm
reproducing here below!  I've adjusted the formatting, filled in a few
spots that were thin, and normalized them a bit, hopefully without
introducing too many errors.

If you have any edits to make in the notes, please reply here (either to
me privately, or on-list) and i'll revise the notes stored in the
datatracker at the materials link above.

All the best,

    --dkg


----------------

# IETF-115 OpenPGP WG

- Tuesday Nov 8th, 1300-1430 UTC
- (Richmond 1 room)

Co-chairs: Stephen Farrell, Daniel Kahn Gillmor
Notetakers: Aron Wussler, Rick van Rein

# Agenda:

## Intro (chair, 5 mins)

  - Need draft readers; 3 in the room + 1 remote are pretty familiar with draft-ietf-openpgp-crypto-refresh-06 or draft-ietf-openpgp-crypto-refresh-07; that is too few.
  - Volunteers to send more reviews:
      -  Robin Wilton
      -  Rick van Rein
      -  Jonathan Hammell
      -  Daniel Huigens

### Avoiding conflicts with draft-koch-openpgp-rfc4880bis-00
  - Both define a key v5 and sig v5, but are different
  - Paul: we should not allow IANA registry squatting
  - Aron: V5 signature and keys are not deployed yet, deconflicting is not necessary
  - Daniel: Werner Koch hinted on the mailing list to being open to changes for keys and sigs, since they are not implemented yet. For keys and sigs the conflict does not exist yet.
  - dkg: Proposal to bump PKESK, OPS, Sig, and Keys to v6
  - Paul: let's not start a race to the latest version
  - Roman: what's the issue with a "race to the latest version"?
  - POLL: 13 for moving to v6, 0 against
  - Daniel: We should still reach out to Werner to ensure that he's not willing to adapt v5
  - Action: sftcd to Reach out to Werner about v5 changes

### Salt length
  - v5 sigs use 16 octet salt, enlarge in preparation of PQ sigs?
  - Aron: Bind sig salt size to signature hash ID
  - dkg: Variant: Column in hash algs table, with a length of the salt for that hash. Introduce new hashes when going PQ (that are the same as the old ones but with higher collision resistance). Withdrawn.
  - Options: 1. keep as-is 16 octets; 2. salt size bound to sighashid; 
  - POLL: 15 choose hash-bound salt size; 1 person chooses kee at 16, because 16 is big enough
  - Action: Aron volunteers to make a PR for this

### Aliased Signature Versions
  - v5 sigs over data < 4GiB can be turned into a v3 sig, sometimes also v4 sig, over subtly different data
  - cause is in old v3 format (deprecated), a modified v5 can at least be distinguished from v4
  - POLL: change v5 signature trailer to avoid aliasing. in favor: 8, opposed: 2
  - Action: dkg volunteers to make a PR

### Contexts for Encryption and Sigs
  - to allow separation of applications' uses of OpenPGP
  - doing this in an interoperable way (registry of known contexts; definitions of how to derive context string for each context;  peer signalling support) to raises a fair amount of complexity.
  - If we publish nothing but the "default" context string, that is similar to what we already have, but interop risks
  - if a registry of even one context, string derivation, and signalling mechanism are well-defined, should be easy to adopt a non-default approach in the future.
  - Kick this can down the road?
  - no poll

### EC point wire formats
  - ECDH and ECDSA pubkeys can move to x-coordinate only
  - Aron: Opposes, only representational, small savings, but adds complexity and breaks the previous format
  - POLL: 0 vote for change 9 votes against, keep the status quo

### IANA updates
  - Aron: I-D is the desired publication format for "specification required"
  - Version Numbers and Packet Types are special: RFC required; any type will do
  - Guidance for Expert Review: Open, stable, likely to foster interoperability
  - Are there registries so small that numbers are scarce?  Otherwise "specification required will do"
  - Action: Stephen and dkg write a text proposal to capture this

## Non-WG items, potential work if re-chartering

### PQC (Aron Wussler, 15 mins)
  - Composite multi-alg (classic+PQC)
  - Seek input: algorithms, binding sigsaltsize to hash ID, binding hashfunction to hash ID