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

Hi Andrew,

Thanks for writing this up and raising this. I was planning to mint a last-minute new revision of the persistent symmetric keys draft but will hold off on it now. In our original implementation we actually used 64&65 instead of 128&129 so I'm happy to revert back to that if needed.

However, to be perfectly honest I'm a bit worried by the additional complexity proposed here and I'm not sure it's fully necessary in general. Especially in the preferred algorithm subpackets, needing to parse a list of variable-length algIDs turns a simple copy into a loop, with error cases that need to be handled, and so on. It's not rocket science of course, but especially for the algorithm registries that are covered by preferred algorithm subpackets, I'm not sure it's needed - the highest ID we have in there is 14 for SHA3-512; do we really think we're gonna get 241 more hash algorithms, or symmetric algorithms?

The most (potentially) constrained algorithm registry seems to be the public key algorithms (especially if folks want to add a lot more hybrid combinations and so on), but even there we have a lot of space. And it's not covered by a preferred algorithm subpacket so the self-synchronizing property is not needed, I think. So, we could do something much simpler, like saying 255 = see next two octets, or something like that.

And similarly, for the packet types and subpacket types we could do something simpler as well (and we'd basically need to do something specific anyway as you've written).
For packet types specifically, we might also want both a (currently already defined as) critical and non-critical surrogate ID, e.g. 39 and 59. But again we can define that when needed as long as we make sure not to fully exhaust the registry.

So, I would personally be tempted to say: let's figure this stuff out if we actually get anywhere close to running out of algorithms; I'm not sure we gain all that much from doing the work to support variable-length algorithm IDs for all registries before it's needed anywhere, and there might be many registries where it's never needed.

In the worst case scenario where we're in 2050 and we need/want 250 new hash algorithms, perhaps to celebrate the joyous year, we could always define a "Preferred Hash Algorithms V2" subpacket which e.g. uses two octets per algorithm ID instead of one, so that parsing is still super simple (at the cost of a few extra bytes) and then in all other contexts we can also just use 255 = see next two octets.

Best,
Daniel

On Tuesday, March 18th, 2025 at 23:44, Andrew Gallagher <[email protected]> wrote:

> Hi, all.
>
> Apologies for uploading this so close to the meeting date, but it’s been sitting in my draft documents for some time now and I want to bring it to the list before we make a final decision about code point allocation for PQC and persistent symmetric algorithms.
>
> 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.
>
> Yes, I said “all”. Please read the document, and feel free to ask questions! ;-)
>
> Thanks,
> A
>
>> Begin forwarded message:
>>
>> From: IETF Secretariat <[email protected]>
>> Subject: I-D list for Open Specification for Pretty Good Privacy notification: Changes to draft-gallagher-openpgp-code-point-exhaustion
>>
>> Date: 18 March 2025 at 16:33:13 GMT
>> To: <[email protected]>
>>
>> Hello,
>>
>> This is a notification from the I-D list for Open Specification for Pretty Good Privacy.
>>
>> Document: draft-gallagher-openpgp-code-point-exhaustion,
>> https://datatracker.ietf.org/doc/draft-gallagher-openpgp-code-point-exhaustion/
>>
>> Change by Andrew Gallagher on 2025-03-18 09:33 PDT:
>>
>> Changed document external resources from: None to:
>>
>> gitlab_repo https://gitlab.com/andrewgdotcom/openpgp-code-point-exhaustion
>> mailing_list https://www.ietf.org/mailman/listinfo/openpgp
>>
>> Best regards,
>>
>> The Datatracker Internet-Draft tracking service
>> (for the IETF Secretariat)

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]