[netconf] IANA templates for algorithms

[Kent Watsen <[e-mail]>]

From our session at IETF 106, there was a suggestion to follow the “template” pattern forged by draft-ietf-dnsop-iana-class-type-yang, which provides an XSLT script that generates a YANG module by processing as input the XML for the separately maintained "DNS Parameters” registry, specifically https://www.iana.org/assignments/dns-parameters/dns-parameters.xml.  The IANA workflow is:

    1) whenever updating the DNS Parameters registry...
            - for whatever RFC may be requesting it

    2) also update the YANG module...
            - by re-running the XSLT script again over the updated XML file

The prerequisite for this process is that there exists separate registries to pull data from, i.e., the input to the XSLT script.  The closest comparable registries that we could pull from seem to be:

 - for TLS: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
 - for SSH: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml

Neither of these registries help us, at least not directly.  Yes, they provide enumerations for on-the-wire protocol values, but they fail to provide an enumeration for, e.g., a 2048-bit RSA key.

Keying off Rob’s comment from the 106 meeting for the IANA process to engage expert reviewers, it seems that a process akin to the following is needed:

    1) whenever some number of existing target registries are updated
          - for now, just the SSH/TLS registries listed above

    2) engage an "expert reviewer" to see if any of the new entries
        regard an undefined algorithm and, if so, a TBD process is
        used to add the new algorithms to the appropriate YANG
        module (e.g., iana-symmetric-algorithms), which would be
        automatically published by IANA.

Drilling into step (2) some, the process might actually be:

  2a) update some new TBD registry (e.g., “base algorithms”).
        This would need to be done by a crypto expert (not the
        NETCONF WG or YANG Doctors.  Good candidates might
        the Security ADs or, perhaps better, the WG that published
        the source RFC.

  2b) run a script over the updated new TBD “base algorithms” 
         registry to produce the desired updated YANG module(s).  
         Presumably IANA could do this in the same way as will
         Be done for the DNS Parameters registry.

Obviously (2a) relies heavily on buy-in from the Security Area experts.  The buy-in needs to be both that this is an important registry to define and support the publication of an RFC that creates and defines rules for maintaining said registry.   Our “crypto-types” draft could be this RFC, if they’re okay with that.

Rich, as someone more connected to the Security Area, what do you think about this plan and any ideas on how to proceed to get the needed buy-in?


Kent // contributor