On Thu, 16 Sep 2021, Daniel Migault wrote:
The concern is interoperability.
I think the real concern, that this document solves, is that if there is a new algorithm some group wants to use for DNSSEC, that it can be at least _specified_ in RFCs and registered in IANA registries, be in standards track or experimental or informational. This document ensures that. Right now, one could not specify an informational algorithm completely, only partially, due to the inconsistent registration policies for the related IANA Registries. Once specified, whether something should or should not be mandatory to implement (for validators or for signers) is up to RFC 8624bis. That document would take into account operational concerns, as well as cryptographic concerns, and interoperability concerns. For example, it would like first try to promote (via MAY or perhaps SHOULD) that the algorithm can be used/tested. Possibly it would then proceed to to make validation a MUST before promoting the signers to SHOULD or MUST.
If previous RFC addressed it, then it should be ease to add a reference.
I believe the only reference needed is already there 8624. Possibly, one could refer to the DNSSEC BCP document, RFC 6781. It has a section 3.4 on "Cryptographic Considerations", but it does not really provide any advise on the interoperability issue you are raising. Perhaps you could review 6781 and if you think your concern warrants it, propose starting a draft on 6781bis ? Paul -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
