[openpgp] Outstanding questions for the WG (Interim agenda)

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

Hi WG--

Since entering WGLC, We've had several substantive change suggestions
made, and we have some outstanding proposals available for merging.

This message is a summary of the top-level decisions we need to make,
and also serves as an agenda for the upcoming interim
(https://datatracker.ietf.org/doc/agenda-interim-2023-openpgp-01-openpgp-01/)
but i'll start separate threads on each issue.

# OpenPGP Interim Feb 2023

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

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:
    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
  https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130)

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


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


# Encryption

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


# Overall

- Guidance for designated expert?  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.

  (see
  https://mailarchive.ietf.org/arch/msg/openpgp/3w9bwStWx4NMjvMUiOkVgvNNJlI/
  and 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.


- Title of the specification? The current title ("OpenPGP Message
  Format") is confusing and unclear (see
  https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/144

  Some possible options are:

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

  This is trivial, so let's not bikeshed too hard.


If we can reach consensus in the interim on these, we can discuss
unchartered work, but i suspect this will consume the full time.

            --dkg