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

[Stephen Farrell <[e-mail]>]

Hiya,

A friendly amendment...

Given the I-D cutoff for IETF-115 is Oct 24th, and our
editor needs time to make changes, that almost all of
these issues were discussed at IETF-114 and noted in
the WG minutes already, and we're planning to do a WGLC
shortly, I think it's fair to ask that any objections
to making these changes to crypto-refresh be sent to
the list before Wed Oct 19th. Barring such, Paul ought
feel free to make the changes below for -07.

Sound reasonable?

Cheers,
S.


On 11/10/2022 11:55, Daniel Kahn Gillmor wrote:
> 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
> 
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp