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

Andrew Gallagher <[email protected]> Wed, 19 Mar 2025 09:59:30 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
On 19 Mar 2025, at 07:58, Justus Winter <[email protected]> wrote:
> 
> 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.

Sure, however this was under the assumption that we would be allocating code points one at a time. If we agree to reserve ranges for certain kinds of algorithms (such as persistent symmetric) then this assumption may not be as safe as we previously thought.

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

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

This would be a significant breaking change though, and the old and new versions would have to coexist for an extended transition period. A backwards compatible extension would be more complex to implement, but would be transparent to the end user. And OpenPGP does not have a good track record for managing breaking changes… ;-)

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

I don’t believe storage efficiency is a notable property of UTF-8 when used for natural language - the key properties of UTF-8 are backwards compatibility with ASCII and self-synchronisation. For most natural languages, UTF-16 is the most efficient encoding.

Similarly, storage efficiency was not a consideration here - in fact, I specifically avoided two-octet encodings in order to improve the self-synchronisation properties, at the expense of storage efficiency.

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

If code point exhaustion is not a concern, then halving the available space is not a significant extra restriction; but if we ever do allocate half of any registry, it will have proven the need for an extension scheme and the reservation will have been worth it. In the meantime, we don’t have to implement anything. I doubt that any extension scheme would become necessary in the near future, and we may not want to use this particular one if and when the time comes. But I do think that we should be careful to keep our options open.

Thanks,
A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 833 B)