> On Mar 23, 2022, at 5:45 AM, Peter van Dijk <[email protected]> > wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > On Mon, 2022-03-21 at 19:32 +0000, Paul Hoffman wrote: >> On Mar 21, 2022, at 11:34 AM, Wessels, Duane >> <[email protected]> wrote: >>> Is it in response to the DNS-OARC talk we saw about implementing PQC Falcon >>> in PowerDNS, and they used the next unused algorithm number rather than a >>> private algorithm? >> >> Nils could have picked 253 but probably didn't even think of looking down to >> the bottom of the list. He was just following the time-honored pattern in >> the IETF. :-) > > (I am not speaking for Nils, to be clear.) > > 253 is not for experiments - it is for private production. It requires > (as most of you might know) prefixing DNSKEY content with a private > algorithm specifier that looks like a domain name (or, for 254, with a > OID). This means if you were to use it for an experiment, your DNSKEY > content, and thus signer and validation code, would need to be changed > when you get a number assigned.
Hey! There is an RFC about this! RFC 4955. If you look that one up, you might understand why I might be aware of that one ;) That said, I didn't remember the number. Anyway, that RFC describes using the 253 and 254 private code points for *doing experiments*. Although, to be clear, we weren't really thinking of new DNSSEC algorithms as experiments (those would be "backwards compatible" experiments). > So, Paul, I support the idea behind your draft, but not the current > wording. While more 253-like points might be somewhat useful, what we > really need are experimental code points with non-253 semantics. Well, we clearly don't need more code points with 253 semantics. I can see that Paul updated it to say that (on 3/24): This document updates [RFC4034] to add seven more private use algorithms. Unlike private use algorithm 253, there is no restriction on the public key area in the DNSKEY RR and the signature area in the RRSIG RR. Thus, there are no domain names embdded in the public key or signature like there are with private use algorithm 253. This update brings the total number of private use algorithms that use the same format to eight. > > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - > https://secure-web.cisco.com/13BiMZSXDSomVBiVLMO81OOpFAzfdgvv6ubBC4kBzp0MFNVxHAjB-U0ggojjjGqRr633YTsQpP9EWS2fps_2PkDMl4Npp7TAkKrLQ2C7KPz71WB0XyUMrEira9LFixKJ542ReDXMA1xPBeIa1jrOCzOmcw2DovEmQ9MAC7IlFW1c37fpfSq7bAfpavOsW26_IDGIlwEGzkC77lfGns3pefv-h8jqziBjFgyH6i56EY5jDjBvamSiQ-HHL8SWzOYmC/https%3A%2F%2Fwww.powerdns.com%2F > > _______________________________________________ > DNSOP mailing list > [email protected] > https://secure-web.cisco.com/1vz4IYPF5-AIZvqtpsjPMKkgkz9QGkTMr5dT5w0nf5ZDaqS_-qldXesfTCcYQTeol3_NPfK3d9YqfbymSWVcfqDXTQlEmOrmNcN29FH9mGE68sjotlov22qiIl-4g_pIeY73R3IbIT0QJIVEpHXwTh2GeQ3r2InHV8vx0alG_5MogRrlrzX6b22SzZs2I5zkD1YgxbPt2ZPPGoo8ts3_4o2szbVNxORxLJjnkQPMkXYMyHRODX1hCyIaba4_YgTtm/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop > -- David Blacka <[email protected]> Verisign Fellow Verisign Product Engineering
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
