Re: [openpgp] [PATCH 1/2] Make it possible to parse arbitrary PKESKv6 packets.

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

hey folks--

This change was proposed over a week ago.  it adjusts only the wire
format of the v6 PKESK packet (with no implications on any of the
cryptographic dataflows), with a goal of making it easier to parse
unknown fingerprint versions:

On Mon 2023-05-08 20:01:19 +0200, Justus Winter wrote:
> diff --git a/crypto-refresh.md b/crypto-refresh.md
> index 7842a68..e102325 100644
> --- a/crypto-refresh.md
> +++ b/crypto-refresh.md
> @@ -994,9 +994,13 @@ The v6 PKESK packet consists of:
>  
>  - A one-octet version number with value 6.
>  
> -- A one octet key version number and N octets of the fingerprint of the public key or subkey to which the session key is encrypted.
> +- A one-octet size of the following two fields.
> +  The size may also be zero, and the key version and fingerprint omitted for an "anonymous recipient" (see {{pkesk-notes}}).
> +
> +- A one octet key version number.
> +
> +- The fingerprint of the public key or subkey to which the session key is encrypted.
>    Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key N is 32.
> -  The key version number may also be zero, and the fingerprint omitted (that is, the length N is zero in this case), for an "anonymous recipient" (see {{pkesk-notes}}).
>  
>  - A one-octet number giving the public-key algorithm used.
>  
> @@ -1104,7 +1108,7 @@ In this case, the symmetric algorithm used MUST be AES-128, AES-192 or AES-256 (
>  
>  ### Notes on PKESK {#pkesk-notes}
>  
> -An implementation MAY accept or use a Key ID of all zeros, or a key version of zero and no key fingerprint, to hide the intended decryption key.
> +An implementation MAY accept or use a Key ID of all zeros, or an omitted key fingerprint, to hide the intended decryption key.
>  In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key.
>  This format helps reduce traffic analysis of messages.

This is represented in MR !304
(https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/304)

We haven't heard any objections on list here, or in the issue tracker,
so i think this can be merged.

   --dkg