[openpgp] Confirming open questions discussed at IETF 114 [was: Re: Meeting Minutes for OpenPGP at IETF 114]

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

Hi folks--

I'm following up on the notes from IETF 114, which had a series of polls
that discussed open issues in the issue tracker, so that we can provide
guidance to the WG editors on what to merge.

If there are concerns about these recommendations, we need to hear about
it on-list.  If you think they look reasonable, noting that is also
welcome.

On Mon 2022-08-01 11:52:06 -0400, Daniel Kahn Gillmor wrote:
> # IETF-114 OpenPGP WG Minutes
[…]
> #### Issue #132: Padding octets (zero/random/other)
[…]
> **Poll** keep the random padding scheme: 8 yes, 1 no, confirm in the list, that we want to keep the current text. Huigens wants to remove the justification.

The support raised here suggests that we should close (without merging)
MRs !203 and !204.  Daniel Huigens, if you want to offer an MR to remove
the textual justification for random padding, please do so!

> #### Issue #134: AEAD Decryption failures
>
> **Poll** Should change the SHOULD to MUST for AEAD decryption failures as described in merge request 206: 15 yes, 0 no.

No one has raised objections to this on the list since IETF 114, and
this in-person result suggests that we should merge !206 as a means of
resolving
https://mailarchive.ietf.org/arch/msg/openpgp/tN2jWx4hUtiMGSo8-ILRXYNumVY/

> #### Issue #135: GCM
[…]
> **Poll**: Keep GCM as an option: 15 yes, 0 no.

Despite achieving clear support in the IETF meeting, this issue has
remained contentious on the mailing list.  No MR has been offered to
remove GCM, but advocates for removing GCM might still want to make the
case for doing so within the crypto-refresh.  Note that the registry for
non-MTI AEAD modes as it currently stands will be SPECIFICATION REQUIRED
(as are nearly all of the OpenPGP registries, with the exception of new
packet types and new packet versions, see discussion of #140 below), so
implementations that want to add GCM support to the standard could
follow up with a separate standard relatively easily.

> #### Issue #136: Binding Keys to Modes
[…]
> **Poll**: Keep HKDF for binding modes as per draft -06: 17 yes, 0 no. 

This mechanism had strong in-person support, and the on-list consensus
seems to support keeping it.  We should close #136 without making
changes.

> #### Issue #137: Direct Key Sigs
[…]
> **Poll**: Certificate-wide parameters live in Direct Key Sigs for v5, keep that: 8 yes, 0 no.

This change to the certificate format for v5 keys demonstrated in-person
support, and no objections on-list.  We should close #137 without making
changes.

> #### Issue #138: Revocation key subpacket is disallowed for v5 keys.
[…]
> **Poll**: Revocation key subpacket is disallowed for v5 keys, keep that: 10 yes, 0 no.

This constraint in updated certificate formats also had in-person
support, and on-list consensus seems to be to keep the simplified
format.  We should close #138 without making changes.

> #### Issue #140: IANA
[…]
> **Poll**: I'm happy with the changes to IANA registration rules (but we should give guidance to the DE): 11 yes, 0 no.

Ben Kaduk provided some reasonable suggestions about guidance to the
designated expert at
https://mailarchive.ietf.org/arch/msg/openpgp/3w9bwStWx4NMjvMUiOkVgvNNJlI
and no one objected to it.

We probably shouldn't close #140 without at least merging some guidance
to the designated expert similar to what Ben proposed.  Beyond #140,
though, completing all the IANA guidance will require some
detail-oriented work, identifying specific changes.

> #### Issue #142: Argon2

There was no poll on Argon2, and only a single person objected on the
mailing list to Argon2.  That person is "in the rough", so Argon2 should
stay in, and we should close #142 wihout making changes.

> #### Issue #143: Problematic keys
[…]
> **Poll**: should we remove the signature checksum from v5 sigs? 5 yes, 2 no.

This is MR !208 -- i don't think we have a clear consensus on making
this change, and no one has advocated for it here, so unless there is a
clear change of heart, i think we should close !208 without merging.

> **Poll**: Should we state that implementations MUST reject signatures (v4 or v5) with incorrect signature checksums? 9 yes, 1 no.

MR !213 attempts to address this, but i don't think it does so as
discussed at IETF 114: it seems focused on v3 signatures, instead of v4
and v5.  If !213 were updated to reflect this properly, i think this
could be merged.


------


I believe that the following MRs are also suitable for merging before we
release the next revision in preparation for WG last call:

Clarify that the fingerprint used in ECDH is the encryption-capable
subkey's fingerprint:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/199


Textual simplification: remove duplicated guidance to always use some
form of integrity protection:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/195


Reject malformed MPIs in v5 signatures, v5 keys, and v5 ESKs:

    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/212


Clarify guidance about newlines around ASCII Armoring to match all
existing implementations:

   https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/215



-----

Please give feedback on these issues!

       --dkg