Thanks for your comments. Regarding the lack of mention of the Red Hat incident, it seemed to me that an RFC proposing an organized way to manage the lifecycle of algorithms should not include mention of a particular incident. If someone feels it's necessary to document the triggering event, perhaps there's another way to do so.
Regarding national algorithms, I don't see any restriction. They can be given IANA identifiers, and they can move through the lifecycle phases. The life cycle model does NOT require selecting which algorithms are advanced through the cycle. Steve On Sun, Oct 6, 2024 at 12:24 PM S Moonesamy <sm+i...@elandsys.com> wrote: > Hi Steve, > At 11:31 AM 05-10-2024, Steve Crocker wrote: > >Thanks for your comments. This submission was triggered by the Red > >Hat snafu. Red Hat removed an algorithm from the library when they > >determined it should not be used. However, as their users > >discovered quickly, messages signed with that algorithm continued to > >arrive, with consequent disruption of their operation. > > > >It seemed obvious to me that removal of an algorithm from services > >should be done carefully. Validation should continue to be > >available long after the new signing is quenched. > > > >I assumed there would be fairly explicit advice along this line > >somewhere in the RFCs. RFC 8624 gave the status of various > >algorithms, but it did advise how to introduce and how to remove an > >algorithm in coordination with other algorithms. > > One of the good things that came out of the IAB was BCP 201 (authored > by one of the co-authors of > draft-crocker-dnsop-dnssec-algorithm-lifecycle-01). There is a part > in it which I am not that enthusiastic about. > > I did not understand the rationale for > draft-crocker-dnsop-dnssec-algorithm-lifecycle-01 as that document is > silent about the RedHat confusion (re. Section 1). There is a > message at > > https://mailarchive.ietf.org/arch/msg/tools-discuss/kvqXZ8-NXTuwPTzIVtL4rjxNoL8/ > which, in my opinion, explains the ietf.org angle. > > One of the potential issues would be national algorithms. It might > be somewhat awkward to not approve a request for inclusion in the > "protocol parameters" registry. It might also be somewhat awkward to > push for a phased approach (please see Section 3.1 of RFC 8624). > > Regards, > S. Moonesamy > > -- 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
