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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
