Steve Crocker <[email protected]> writes: Originally I actually didn't see the point of this draft, but obviously came around in the end. So let me explain my thinking, which may help others come to a decision (either for or against!) who might be on the fence or don't understand the "why".
> Implementers, i.e. the folks in control of software crypto packages, > will make their own decisions, of course, but the intent here is to > give them clear guidance, with accompanying data, to make their > decisions much easier. Similarly, operators, i.e. the folks in > control of which algorithms in the crypto packages are enabled or > disabled in their services, will also find the guidance helpful. As Steve has put it multiple times, right now there is a lack of guidance on what an "ideal" transformation over time would mean. In the RFC9904 document we carefully laid out how each algorithm can have different recommendation values for implement vs usage combined with implement vs deploy. This allowed us the assembly language to document how the current world and standards sees "right now". But there isn't a document that specifies the hopeful steps that an algorithm will progress through over time. Steve, Russ, and I along with some others had disagreements about RFC9904 and whether it should be prescriptive in this regard. My stance was "no" because 9904 was designed to be the assembly language that could encode *any* state, not just the ideal ones that we believed would be the perfect transmission path. The algorithm-lifecycle document fills the hole that provides guidance over the longer term path an algorithm *might/should* take (and this may be where Steve and I disagree). There is no way we'll encode the perfect path sometimes, and the SHA1 case is a fairly good example of that where the rush to deprecate an algorithm made us move faster than was otherwise planned. And this is the important point: I've seen arguments against this draft saying "you can't always go through phases; what happens when an algorithm is truly, suddenly broken?". Absolutely! I don't think anyone has said there aren't times where you must jump straight to "MUST NOT" in all fields because the cryptography world flipped faster than expected. The algorithm-lifecycle document prescribes advice *only* on "if we had the best forward vision, this is what responsible adoption and deprecation would look like". That's at least my view. So in the end, I think the document is needed as it does fill that hole. Is it exactly where I want it to be yet? probably not. Do I think DNSOP should take it on so we can get it to where it needs to be, including making sure that it doesn't force an algorithm to only fit specific values to the 9904 table? Yes. Should it force a row in the 9904 table to only encode specific values? No, which I've argued many times. There will always be exceptions to the perfect. -- Wes Hardaker Google _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
