[openpgp] Re: I-D list for Open Specification for Pretty Good Privacy notification: Changes to draft-gallagher-openpgp-code-point-exhaustion

[Justus Winter <[e-mail]>]

Andrew Gallagher <[e-mail]> writes:

>> Then, you couldn't use multi-byte code points in any existing packet
>> version, because that would turn what every software on this planet
>> expects to be a fixed-size field into a variable-sized field, and
>> failing to understand the scheme leads to catastrophic loss of parser
>> synchronization (maybe with security implications).
>
> The use of octets >=128 for the extension scheme ensures that parser
> desynchronisation always results in the emission of an unallocated
> code point. In most cases the remainder of the packet is not parseable
> even in principle if the code point is unknown, and in the rest the
> errors are minor, with no security implications.

In Sequoia, we explicitly model unknown values, and parse and roundtrip
artifacts with unknown values just fine.  I strongly believe that this
principle has resulted in a very robust and forward-compatible
implementation.

And, I have identified aspects of RFC4880 where it was impossible to
parse (parts) of packets unless you knew the algorithms used in the
artifact.  Notably, it is not possible to compute the fingerprint of
secret key packets unless you know the key packet's asymmetric
algorithm.

I made an effort to avoid this and similar problems in RFC9580.

> I checked the wire format of every packet and subpacket that contains
> a code point, and the results are listed in section 5 of the
> document. If I have missed anything, please let me know!

Your proposal breaks computing the fingerprint of secret key packets
again unless the implementation understands your multi-byte encoding.
I consider that a regression.

I'm going to strongly push back on anything that makes parsing OpenPGP
artifacts impossible unless you know some as of yet unknown algorithm or
encoding scheme.  That is a nightmare for forward-compatibility.

I don't believe in the argument "well if you don't understand this part
here, you cannot use the packet anyway, so you might as well model the
rest as opaque bytes".


Best,
Justus