Content-Type: multipart/signed;
	boundary="Apple-Mail=_6BA6C4B4-93CB-4C70-93E1-5F82B2A36ADC";
	protocol="application/pgp-signature";
	micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\))
From: Andrew Gallagher <andrewg@andrewg.com>
In-Reply-To: <87tt7p8n9d.fsf@europ.lan>
Date: Wed, 19 Mar 2025 09:59:30 +0000
Message-Id: <D4D840C5-CD2F-47D8-8101-DF3F950B3ECB@andrewg.com>
References: <174231559348.277.2581535826712330509@dt-celery-57d64c6895-fcmg2>
 <B321DC63-56E0-44C2-96AA-D60205C148B2@andrewg.com> <87tt7p8n9d.fsf@europ.lan>
To: Justus Winter <justus@sequoia-pgp.org>
Message-ID-Hash: W6US4FCFJJ4HM5PYXRAHJPVGNWZ23XTG
CC: IETF OpenPGP <openpgp@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Re=3A_I-D_list_for_Open_Specification_for_Pretty_Goo?=
 =?utf-8?q?d_Privacy_notification=3A_Changes_to_draft-gallagher-openpgp-code?=
 =?utf-8?q?-point-exhaustion?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/Vkp8jzimlRLs78fjioxHI0cBWGI>


--Apple-Mail=_6BA6C4B4-93CB-4C70-93E1-5F82B2A36ADC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 19 Mar 2025, at 07:58, Justus Winter <justus@sequoia-pgp.org> wrote:
>=20
> 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 >=3D128 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=E2=80=A6 ;-)

> 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=E2=80=99t 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=E2=80=99t 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


--Apple-Mail=_6BA6C4B4-93CB-4C70-93E1-5F82B2A36ADC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAmfalYMACgkQXB7EBNWQ
Zind9g//cxmYhYwAkoaPVzoaNj/4knTEQ5MbtC7O4dbzxqRpF7LDYNCQ/SrLbHWk
c1hboiSis6NQWYrb8LxP87jJKWV0x1mv09siAD5mNgDBxdsVjl2DPZ8BH8H9a5GW
Hh6rvXOL0bUOfqv9b3zWM/a1dW1jamunYwzQI/gTILbbSY2PUAh4djQ3/QsPFgpd
C9alr5MxcUbzr8FI1twNn/imG7FcoFcGXy6fUB03TaUrv0mRCYDaQtR4o2CYUfz+
mrdj1K7otkOJ9e26xPfgwwXfY9Yw8lZV8Q360/vWd3bdJdUlkRJpRtZQu9Dm0dUh
DhIgc7UWaqorq3mpwYBlIYv1n1HCntE6zbACqkhmKCq41xX6IU9bq6bJRsEg/sOi
zHng2cmgwHLFqc81BdG9/MUC59ZKUzpoibhZKZnnm82Z1qRkLwFFQvo+dR8kv8cN
cqNVguUmSRcXu1MIDlGTHbUvcLUVSqkK9MX7c3BaT1gSBpaSrDTY8kj5RVpX+0SN
GuGCFejAgwFUdxNw2RcEN5brfRVQiZ0SqvY1UUdCp+5xCvqUtF8UIlQKLXRnyDVT
2aL2/7TTuQeJ9eMbJus6yJ4xUBB22UPKbRoV/2CEzN7e5mundPZajyyttiqWIymU
EeAf0vX3qat6ZwuvGHEEXqj8lOw1Ojy69XsCbWVo/MQ33nGuTlM=
=2b2l
-----END PGP SIGNATURE-----

--Apple-Mail=_6BA6C4B4-93CB-4C70-93E1-5F82B2A36ADC--