OpenPGP Interim Meeting 2024-09-09

Agenda:

• administrivia
• RFC9580
• Replacement Keys

No agenda bashing

Replacement Keys

• Draft:
  https://datatracker.ietf.org/doc/draft-ietf-openpgp-replacementkey/
• Slides:
  https://datatracker.ietf.org/doc/slides-interim-2024-openpgp-03-sessa-replacement-key-mechanism/
• Repo/issues:
  https://gitlab.com/andrewgdotcom/openpgp-replacementkey/-/issues

Outstanding questions

Are subpacket version and class octets necessary? #8

Is the class octet necessary?

Andrew: yes, class octet is necessary

dkg: what's the difference between a subpacket with null replacement and
absence of the subpacket?
Andrew: nullity is an explicit statement that there's no replacement,
absence just means it's not specified (yet)
Daphne: nullity implies you don't have to go looking for a replacement
key
dkg: but what if the producer changes their mind later?
Daphne: they could create a new signature replacing the replacement key
subpacket
dkg: that doesn't work for hard recovations
Andrew: in the case of a hard revocation you can't trust anything

Bart: wouldn't be opposed to having two subpackets (not sure if we need
nullity)

Stephen: name of the subpacket is confusing if you can have forward or
inverse direction
Daniel: could name it something like "trust-equivalent key" so that it
makes sense in both directions

Poll: should we drop the class octet?
0 yes, 8 no, 1 no opinion

Are subpacket version octets necessary?

Daphne: original intent was to enable fixing mistakes in the design
...: but can do the same by defining a new subpacket
...: not wedded to the version octet
Andrew: me neither
dkg (as implementer): scared of complexity

Poll: should we drop the version octet?
6 yes, 0 no, 3 no opinion

Are imprint fields necessary? #15

Daniel: we do something similar in ProtonKT (SHA256Fingeprint). I like
the idea of an imprint, though the attack is unlikely so not sure it's
really necessary here
dkg: the benefit is that we don't have to explain the use of SHA1
Justus: not convinced, even if we include an imprint we still have the
SHA1 fingerprint there as well
...: we should only include imprints and allow looking up keys by
imprint
Andrew: upgrading key servers would take a while, would slow down
adoption

dkg: we could deduplicate using the fingerprint length octet, and in the
future upgrade to always only including the imprint

Poll: should we drop the imprint field?
1 yes, 4 no, 4 no opinion

Poll: should the fingerprint be optional?
3 yes, 4 no, 4 no opinion

Poll: should we drop the fingerprint?
1 yes, 6 no, 4 no opinion

Andrew and dkg will think about how to make the fingerprint optional and
come back to the list with a wire format proposal

Bart: what's the advantage of making the fingerprint optional?
Andrew: if we allow lookups by imprint we don't need fingerprints
Daphne: does it really save much?

Andrew: we'll come back to the list with a few options for how to
proceed

Encryption to both the replacement and the original key? #14

Andrew: opens a can of worms, already have inconsistency around which
subkey(s) to encrypt to
...: already have mechanisms for this

Justus: motivation is if you have a v4 implementation and a v6 one, you
can't duplicate the subkeys
Daniel: perhaps we should say, don't generate a v6 key yet in that case?

Thore: how should the user know if their phone supports v6 or not? And
how should the implementation on their desktop know?
Andrew: don't know, haven't discussed this much yet

UX questions

dkg: we should think about how to update SOP to support this
...: both generating and consuming

Wrapping up

Stephen: timeline?
Andrew: would like to get this into shape this year
...: depends whether the scope expands more or not (e.g. multiple
encryption would push it back)

dkg: will send followup on the list, more feedback is welcome there
Stephen: we should ask for a session in Dublin