Hi Paul,
Thanks for the response. Please see inline, this is exactly the clarification I think the current document needs. Please see inline.
Yours,
Daniel
Daniel
On Thu, Sep 16, 2021 at 11:00 AM Paul Wouters <paul@xxxxxxxxx> wrote:
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.
The two paragraphs you propose are **exactly** the kind of text I am asking to be added to provide a clear path to anyone asking for the registration of a new algorithm. It clarifies the impact associated to standard and non standard code points, as well as that the mandatory-to-implement are defined by 8624 independently from the status of the code point. I also believe this could address interoperability - which could even get removed from the security considerations as this is clearly handled by 8624.
> If previous RFC addressed it, then it should be ease to add a reference.
I believe the only reference needed is already there 8624.
I agree 8624 is sufficient.
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
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
