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

Daniel Huigens <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <09_pBNGQp8U3bJBeEpRqAggxanUlbvZNMtEvjS6qu1LUbACtuK9ttEKH6FUksLHkLyH9jTL4gI6Ua1gs4cXL_L9Hw1jW_2lSf3Cwgpd1kr0=@protonmail.com>
Hi Heiko & all,

The persistent symmetric keys draft currently proposes to use the public​ persistent key algorithm ID range 0b10000000-0b10001111 (128-143) for symmetric algorithms, to make it easy to check whether a given algorithm is symmetric.

We could of course shift this over, to e.g. 0b01000000-0b01001111 (64-79). Though, then we're putting them much closer to the currently used algorithms. Whether that's a good or a bad thing I don't know. Perhaps it doesn't matter much.

So, if the WG is in favor of that I can make that change, of course. But, I just personally think that reserving half of every OpenPGP registry for future expansion purposes is unnecessary; reserving a single value (e.g. 255) should be enough.

Once we fill all the IANA registries with "128-255: Reserved", I imagine in might require a lot of arguing to revert that, so I would prefer that we do that arguing and agree on a strategy for future expansion now, if we think it might be needed at some point :)

Best,
Daniel

On Thursday, March 20th, 2025 at 15:44, Heiko Schäfer <[email protected]> wrote:

> Hello,
>
> I'm sure much discussion would be needed to positively decide in favor of the scheme proposed in draft-gallagher-openpgp-code-point-exhaustion.
>
> However, as I understand it, the only immediate question that this draft is effectively asking is: "do we want to reserve bit 8, for now?"
>
> I have not seen any compelling argument against this proposition, so far.
>
> So as a defensive stance, I'm in favor of "reserving bit 8" for all code points where this bit is still unused. At least until there is a compelling argument why the currently vacant second half of a particular code point space is required for some proposed new feature.
>
> Thanks,
> Heiko
>
> On 3/18/25 5:44 PM, Andrew Gallagher 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]>](mailto:[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]>](mailto:[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]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.