On Thu, 22 Feb 2018, Paul Hoffman wrote:
In what way is publishing Informational RFCs that specify country-specific cryptographic algorithms *not* considered to be good for interoperability?
Algorithms should be accepted based on their individual merits, not based on their origin. So for example, I'm fine with a suite for IoT algorithms, as those have specific requirements. National requirements however, are not international standards, and are often riddled with secrets. We should not codify that in RFCs
With respect to suites and profiles, saying "country-specific" is going to turn into a rat hole. What if an large industry trade association from one country wants to specify a suite in an RFC? What if a profile is developed jointly by three countries, two of which are obviously beholden to the third? Or...?
They would have to show the merit of these from a technical point of view. Not from an origin/inventor/vetted point of view.
You might say that there should be no Informational RFCs specifying cryptographic suites and profiles at all unless the profile was put together in the IETF, and that would make sense given that externally-generated cryptographic suites and profiles change over time. But that is just as true as protocol profiles that are common in industry trade associations. This is just a continuation of the question of what externally-generated specifications should be in the RFC series as Informational RFCs: it is not specific to suites, profiles, or "country-specific".
I'm fine with IoT profiles, 3gpp/mobile profiles, cloud profiles. interplanetary profiles.
Disclaimer: I got paid to help with the Suite B specs in the IETF and was completely open about it while doing so.
At the time, that was a good thing. Thanks for improving the standards of the time! Paul
