<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 13 May 2024, at 02:18, Jacob Bachmeyer via Gnupg-devel <gnupg-devel@gnupg.org> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">it appears to me that the culpable parties are probably *not* on this mailing list. In other words, OpenPGP algorithm IDs should refer to algorithm types (RSA, DSA, EC-RSA, McEliece, Kyber, etc.) with details (key length, curve parameters, etc.) included in type-specific fields in the key packets. The other side of this debate is attempting to treat OpenPGP algorithm IDs like TLS ciphersuite IDs, which attach all of the details to each codepoint.</span></div></blockquote></div><br><div>OpenPGP algorithm IDs have historically referred to broad algorithm types. I think the crucial part of this disagreement is whether historical practice should be continued in this instance, or whether it is preferable to limit the number of free parameters for future algorithms.</div><div><br></div><div>(BTW this is not the same code point allocation model as TLS. TLS ciphersuites also include the AEAD mode, which remains a separate registry in *PGP)</div><div><br></div><div>A</div><div><br></div></body></html>