Skip to main content

OpenPGP Interim - Feb 2023
agenda-interim-2023-openpgp-01-openpgp-01-08

Meeting Agenda Open Specification for Pretty Good Privacy (openpgp) WG
Date and time 2023-02-09 12:00
Title OpenPGP Interim - Feb 2023
State Active
Other versions markdown
Last updated 2023-02-08

agenda-interim-2023-openpgp-01-openpgp-01-08

OpenPGP Interim Feb 2023

Signing

  • Should the new key and signature formats change codepoint designations from v5 to v6? (this avoids collision with the v5 codepoint which has seen some pre-specification deployment and could cause confusion in the wild)

    • Should the fingerprint and signing octet for the new form also move from 0x9a to 0x9b? (v4's comparable octet is 0x99)

    • MR that answers "yes" to both of the above: !231

  • Should hashed data for v5 signatures revert to a 4-octet length field? in -07 it is an 8-octet length field, which causes a risk of aliased data streams with v3 or v4 signatures, (see #130)

    • MR that answers "yes" to the above: !220
  • Update signature salt size from 16 octets? (see #150)

    • Should this be a uniform increase to 32 octets? or should it be bound to the hash function used?

    • Should the size of the salt be indicated on the wire in the Signature packet?

    • MR that answers "bound to the hash function used" and "indicated on the wire" to the above questions: !219

  • Add Context parameter for signatures? Marcus Brinkmann's messages on this list provide examples of why a context parameter can be useful (see also #145)

    • if so, how do we specify or register the context parameter for different use domains?

    • MR that says "yes, add a context parameter" and "don't specify any specific context or set up a registry", and is also coupled to a context parameter for encryption: !214

Encryption

  • Add Context parameter for encryption? (see #145)

    • if so, how do we specify or register the context parameter for different use domains?

    • MR that says "yes, add a context parameter" and "don't specify any specific context or set up a registry", and is also coupled to a context parameter for signatures: !214

  • Remove checksum and padding for v5 PKESK? This reduces the bytes on the wire at no loss of functionality as there is already a checksum in the key wrapping algorithm.

    • MR that does this: !223

Overall

  • Guidance for Designated Expert? (see mailing list discussion and #146). This doesn't have an MR yet, hopefully Stephen or i can make one before the interim. Do we want to suggest that Designated Experts be given substantial leeway, but advise that they follow the following guidance when considering a specification for the Specification Needed registrations:

    • avoid codepoint squatting and vanity registrations

    • require that the specification is concretely useful

    • require that any registered algorithms meet the security requirements of the community and the message structures for which they are proposed to be used.

  • Title of the specification? The current title ("OpenPGP Message Format") is unclear and confusing (see #144). This is trivial, so let's not bikeshed too hard. Some possible options are:

    • OpenPGP
    • OpenPGP Protocol
    • OpenPGP Wire Format and Semantics
    • OpenPGP Messages, Signatures, Keys, and Certificates
    • OpenPGP Data Format

Administrivia

  • Do we want to meet in Yokohama (IETF 116)?

Overflow (if we have time)

  • Other outstanding chartered work

  • Collect list of unchartered work for consideration of a re-charter