[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]