[netconf] Supported algorithms lists

[Kent Watsen <[e-mail]>]

All,

We had a discussion awhile back about split/move-ing the 3 “supported algorithm” lists into the SSH- and TLS- client-server drafts (a total of 6 lists when done).  The thinking was SSH and TLS might (perhaps likely?) support different algorithms, which would be good to capture.

That said, we noted that this was a compromise as there may be more than one SSH or TLS library used by an application, and thus having protocol-specific lists may be too  course (compared to library-specific lists).

I’m wondering if we can do better and maybe even simpler…

One idea is to stick with having a single list per algorithm type (i.e., symmetric, asymmetric, hash, etc.), but then to allow each list item to contain a list of *where* that algorithm can be used.   In the simplest case, the “where it can be used” could be enumerated values (“SSH”, “TLS”) but perhaps better could be a list of XPaths?

However this seems a bit upside-down, as what would likely be preferred is to have a list of XPaths and then, for each, as list of supported algorithms.     Better, but messy, but it suggests a 3rd idea, which is to have an RPC that takes an XPath (to a key) and returns the list of supported algorithms for that key.

	rpc get-support-algorithms {
	   input {
	      leaf schema-path {
	         type string;
	         description
	            “Schema path to a ‘key’ node.”;
	      }
	   }
	   output {
	      choice key-type {
	         case symmetric-key {
	            leaf-list symmetric-algorithm {
                       type symmetric-algorithm-type;
                    }
	         }
	         case asymmetric-key {
	            leaf-list asymmetric-algorithm {
                       type symmetric-algorithm-type;
                    }
	         }
	      }
	   }
	}

This seems elegant as the implementation complexity scales with the complexity of the application.  An application that uses only a single crypto library could have a fairly static response, whereas complex applications could vary the response by the path (knowing which crypto library would be used).

Thoughts?

Kent // contributor