[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 Heiko :)

Heiko Schäfer <[e-mail]> writes:

> Hello Justus, list,
>
> On 3/20/25 10:57 AM, Justus Winter wrote:
>> Further, the proposed solution (for which reserving one bit now is the
>> precondition, so I think it is fair to also consider it), seems to
>> complicate parsing (and there is precedence on how OpenPGP very cleverly
>> encodes things like packet body lengths, S2K hash counts, S2K mechanism
>> type, AEAD block sizes), and I like parsing to become simpler, not more
>> complicated.
>
> I tried to be clear, but will try to be even clearer:
>
> I didn't mean to say that I'm in favor of ratifying the specifics of
> the proposal.  I *am*, however, in favor of *just* reserving code
> points >= 128 (where applicable), until further notice.

Thanks for clarifying.

> Reserving a range of code points, by itself, certainly wouldn't
> complicate any parsing.  It would only clarify a policy for how the WG
> assigns code points, over the next few cycles of extensions.

That is true.

> Reserving the upper halves *for now* wouldn't in any way stop the WG
> from deciding (say, 5 years from now) that it is, after all, the
> lesser evil to just assign code points >=128 in one-byte
> representation.

That is true, but this precaution also has a non-trivial cost (Andrews
time, our time, IETF machinery time), for a problem that not everyone
agree exists (in fact, a relatively recent discussion in this working
group concluded that it doesn't), and the precaution is necessary only
to pave the way for a solution no one except Andrew seems to like (at
least no one spoke up yet, if you do, please speak up!).

> (Fwiw, I currently lean towards agreeing with you - I expect to favor
> avoiding the complexity of Andrew's proposal, myself. But maybe in 5
> years my view will have changed.  I expect we will collectively gain
> new insights about the appropriate future evolution of the format, as
> OpenPGP hopefully flourishes.)

Thanks for carefully clarifying your opinion on the proposed solution as
well.


Best,
Justus