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

[Andrew Gallagher <[e-mail]>]

On 19 Mar 2025, at 04:15, Daniel Huigens <d.huigens=[e-mail]> wrote:
> 
> 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.

Thanks! To be clear, I have no objection in principle to reserving a special range for persistent symmetric keys - my only concern is future-proofing the namespace. :-)

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

I’m not convinced either - I doubt that the majority of the registries will ever reach 128, let alone 256. However, I wanted to be as complete as possible, so that there is some form of extension scheme available for each registry, just in case. And minimising the number of distinct extension schemes feels like the most conservative option.

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

I did think about that, however algorithm IDs are used in all sorts of potentially ambiguous places, not just preference packets, and self-synchronisation ensures that there can be no aliasing in any context. Remember also that this scheme would have to be robust against arbitrary future specifications, not just currently-existing ones.

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

Absolutely do not implement any of this yet! This is far-future stuff - but I still believe it is worth publishing now, to remind ourselves that OpenPGP is a multi-decade project, and we should avoid painting the spec into a corner that future developers will not thank us for.

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

We could do that - but then we’d need to support the v1 and v2 formats in parallel for some time while implementations catch up, and there would be potential for confusion if they were inconsistent. And this is just one registry...

A