Re: [openpgp] Marker packet for OpenPGP-NG (was: Confirming open questions discussed at IETF 114)

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

Hi Werner--

On Wed 2022-10-12 17:00:40 +0200, Werner Koch wrote:

> Given that the crypto-refresh I-D heavily deviates from OpenPGP as
> specified in RFC-2440 and RFC-4880 and deployed practise I have two
> suggestions to avoid confusion:

I'm surprised to hear that you think that the crypto-refresh deviates
heavily from RFC-4880.  Could you be more specific about the sources of
deviation you're concerned about?  From what i've seen, the design-team
has been pretty scrupulous about not breaking backward compatibility,
and about carefully staying within the lines of the previous
specification, making use of the extension points already within the
spec.

For example, when new wire formats are indicated, they are clearly
marked with a different version number, so they are identifiable.

> 1. All data including key packets shall make use of a marker packet
>
>    5.8.  Marker Packet (Tag 10)
>
>    This packet was used by certain PGP versions and flagged as obsolete
>    in RFC-4880.  With this specification it is repurposed to mark the
>    data and keys constructed as specified by this specification and its
>    successors.
>
>    The body of this packet consists of:
>
>      - The three octets 0x60, 0x67, 0x70  (which spell "pgp" in UTF-8).
>
>    Implementations SHALL use this packet to indicate packet formats
>    described by this specification.  It SHALL be the first packet of
>    each OpenPGP Message or sets of OpenPGP Keys.  Note that the old
>    marker packet used three different octets.

given that the new data elements are already identified by version
number, i don't see what is gained by including this packet?

> 2. Clearly identify the new specification as a new version of OpenPGP
>    with only limited backward compatibility.  For example
>      OpenPGP-NG or OpenPGP/2 or ModernPGP or IETFPGP
>    or maybe just PGP (if Broadcom allows for such a use)

I'm assuming here that by "the new specification", you mean the
crypto-refresh draft.  As chartered, that draft is certainly the new
version of OpenPGP, but it does *not* have limited backward
compatibility.  I don't see why giving it a different name is useful.

Can you explain more?

        --dkg