[openpgp] Open Specification for Pretty Good Privacy (openpgp) WG Virtual Meeting: 2023-02-09 CHANGED

[IESG Secretary <[e-mail]>]

MEETING DETAILS HAVE CHANGED.  SEE LATEST DETAILS BELOW.

The Open Specification for Pretty Good Privacy (openpgp) WG will hold
a virtual interim meeting on 2023-02-09 from 12:00 to 14:00 Europe/Dublin (12:00 to 14:00 UTC).

Agenda:
# OpenPGP Interim Feb 2023

- time: 2023-02-09 12:00 UTC - 14:00 UTC

- location: [https://meet.jit.si/IETF-OpenPGP-WG-Interim-Feb-2023](https://meet.jit.si/IETF-OpenPGP-WG-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](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130))

    - MR that answers "yes" to the above: [!220](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/220)

- Update signature salt size from 16 octets? (see [#150](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/214)

## Encryption

- Add Context parameter for encryption? (see [#145](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/223)

## Overall

- Guidance for Designated Expert?  (see [mailing list discussion](https://mailarchive.ietf.org/arch/msg/openpgp/3w9bwStWx4NMjvMUiOkVgvNNJlI/) and [#146](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/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](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/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

## Overflow (if we have time)

- Other outstanding chartered work

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


Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=ba9363d0-0318-4c22-b3a7-f2037e345a02