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

[Justus Winter <[e-mail]>]

Hi Andrew,

Andrew Gallagher <andrewg=[e-mail]> writes:

> tl;dr: please keep code points >=128 free, because if at some point in
> the future we needed to extend the algorithm registry to more than a
> single octet, having these code points available would let us define a
> UTF8-like self-synchronising encoding that would be fully backwards
> compatible with all existing wire formats.

I'm not a fan of this.  First, we discussed code point exhaustion while
working on RFC9580, and decided that it is not a concern.  We are
nowhere near exhausting any code point space, not even the relatively
tiny packet tag space.

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).

Therefore, multi-byte code points can only be used in newer packet
versions.  But, if we design new packet versions, we can just make them
use a two-byte field for the code point in question, and say that the
new algorithms must only be used with the new packet version.

You bring up the comparison with UTF-8.  For text, we are interested in
storing it efficiently, and are okay with a complex encoding.  I don't
think this holds for our code points.  And even if storage efficiency
were a concern, a two-byte code point, or even a four-byte code point,
compares very favorably with OIDs.

Finally, your solution to the (again, non-existant) code point scarcity
makes the problem worse by halving the existing space.

Best,
Justus