Paul, You wrote, "You cannot use two algorithms to sign or delegate at the same time." If there are two or more independent signers for a zone -- see RFC 8901 -- then multiple algorithms might be in use at the same time.
I think there is some wording that says the algorithms must be the same, I believe there is an effort to remove that restriction. If there are multiple signers, each of them will likely change the algorithm it uses, so it's necessary to permit the concurrent use of distinct algorithms. With respect to MUST, etc., I'm not a big fan of these designations in this context, but the terms are deeply embedded in the RFC culture and impossible to avoid. That said, both 8624-bis and our lifecycle document anticipate there may be multiple acceptable algorithms to use at any one time. Indeed, in order to support transitions from one algorithm to another, use of multiple algorithms concurrently is necessary. I'll leave it to Wes or Warren, the co-authors of RFC 8624-bis, to respond more fully. Thanks, Steve On Sat, Oct 12, 2024 at 11:27 AM Paul Hoffman <paul.hoff...@icann.org> wrote: > Earlier, Wes said "I believe the 8624bis document is functionally "done" > and should be published." However, there has been too little discussion on > what the new columns actually mean, and someone reading the new IANA > registries would not know what to do. > > In specific, "Use for DNSSSEC Signing" and "Use for DNSSSEC Delegation" do > not make sense if there is more than one "MUST" in that column. You cannot > use two algorithms to sign or delegate at the same time. > > Table 2 is for "Domain Name System Security (DNSSEC) Algorithm Numbers". > It reads in part: > > +==+===============+===========+===========+===========+===========+ > |N |Mnemonics |Use for |Use for |Implement |Implement | > | | |DNSSEC |DNSSEC |for DNSSEC |for DNSSEC | > | | |Signing |Validation |Signing |Validation | > +==+===============+===========+===========+===========+===========+ > +--+---------------+-----------+-----------+-----------+-----------+ > |8 |RSASHA256 |MUST |MUST |MUST |MUST | > +--+---------------+-----------+-----------+-----------+-----------+ > |10|RSASHA512 |NOT |MUST |NOT |MUST | > | | |RECOMMENDED| |RECOMMENDED| | > +--+---------------+-----------+-----------+-----------+-----------+ > |13|ECDSAP256SHA256|MUST |MUST |MUST |MUST | > +--+---------------+-----------+-----------+-----------+-----------+ > |14|ECDSAP384SHA384|MAY |RECOMMENDED|MAY |RECOMMENDED| > +--+---------------+-----------+-----------+-----------+-----------+ > |15|ED25519 |RECOMMENDED|RECOMMENDED|RECOMMENDED|RECOMMENDED| > +--+---------------+-----------+-----------+-----------+-----------+ > |16|ED448 |MAY |RECOMMENDED|MAY |RECOMMENDED| > +--+---------------+-----------+-----------+-----------+-----------+ > > How can both 8 and 13 be "MUST use for signing" at the same time? > > How can 14 and 16 be "MAY use for signing" if there are other values that > MUST be used instead? > > Is 15 more recommended than 14 and 16 even though 14 and 16 are currently > obviously stronger? > > Without more description of what the new columns mean, a reader of the > IANA registry will have no idea what to use when choosing a signing > algorithm. The same is true for the new column in the DS table. Either > there has to be definitions of the terms above the new tables at IANA, or a > pointer to a concise description of the terms in an RFC, such as in a short > appendix in this draft. However, I still don't see how defining these terms > using the normal use of MUST in the IETF would make sense for this new > column. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > -- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
