All
I am all for hacky ideas, and I think this one is oK. I would suggest putting a beginning date into the list and maybe later folks can say "is 18 months enough time for MAYO-512-MEOW ?" Because you want to test them, and keep the ones that are liked and make them into Real Code Points (tm). I do agree with Joe on "If it's too hard to create a registry or to add code-points to a registry we should find imaginative ways to solve those problems" But I think the problem with updating the IANA registry is removing it from an IANA registry, even private/reserved things. tim On Fri, Jun 26, 2026 at 10:19 AM Paul Hoffman <[email protected]> wrote: > On Jun 26, 2026, at 01:26, Joe Abley <[email protected]> wrote: > > > > On 26 Jun 2026, at 03:08, Paul Hoffman <[email protected]> wrote: > > > >>> \It is also one thing to experiment with a single new algorithm (and > then use 253 or 254). But in the PQ space there are *many* algorithms. In > our name servers we currently do testing with 15 different algorithms (4 * > MAYO, 2 * FALCON, 3 * SNOVA, 3 * ML-DSA, SQISIGN, SLH-DSA-128s and one of > the QR-UOV algs). The amount of kludgery that would need to be added to the > code by not knowing what algorithm it is until the DNSKEY has been fetched, > an identifier string has been extracted from the public key and mapped > against the algorithms that the code even knows how to use is not > reasonable. So we do code point squatting instead, which makes > collaboration with others much more difficult (see above). > >> > >> Our registry requires no such kludgery. You look at the first three > bytes of the DNSKEY or RRSIG: if the first byte is 0x01, and the third is > 0x00, you know it might be in the unofficial registry. > > > > I need to look harder at both proposals, but what you write above just > seems like a different kind of kludgery. > > Correct. Duane and I proposed a kludge that takes a lot less effort for > DNSOP (and thus the rest of the IETF), one that we believe will cause less > downstream damage (when the community picks a final algorithm and now it > would have two codepoints), and that likely adds just one more if-tree to > implementations that are being used for experimentation. > > > I am not against kludges, and I appreciate pragmatism in all its varied > and admirable forms, but this does have the aroma of "the process is too > hard, let's avoid the process". > > That is definitely a fair assessment, but we live in a world where the > people in charge of the process are exceptionally conservative with code > points. > > > There ought to be no reason why creating a new registry for a purpose > that has a ticking countdown clock cannot be expedited. > > And yet here we are. But even if that new registry could be created, you > will later be confronted with the issue of having at least two code points > (the one in the experimental range, and the one in the real range). The > IPsec community had a massive problem with this 30 years ago. > > > If it's too hard to create a registry or to add code-points to a > registry we should find imaginative ways to solve those problems. I think > using that energy to avoid the problems instead of solving them doesn't do > much to help the next person\. > > > > Note again, I am not arguing about your specific proposal, here. This is > a more general opinion. > > Duane and I chose an explicitly path that makes testing easy, and makes > switching off of testing easy. Informal paths that cannot later turn into > formal paths seem to work well. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
