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 _______________________________________________ IETF-Announce mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-announce
