Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

> To put an end to this email, recall above it was said that the secondary goal is to pass an "algorithm" parameter into the 'generate-symmetric-key' and 'generate-asymmetric-key' actions (what kind of key to generate, right?).   Most of the above regards the key formats (not algorithms, though the OneSymmetricKey and OneAsymmetricKey structs do self-identify their algorithms).   I don't have an answer for this yet, but maybe we can mimic some aspect of the above for it?
> 
> Comments?


Answering myself here.  Having identities for "key formats" is useful and maybe helpfully decouples things, but how to support the actions remains open and yet critical to support.

Other than the "IANA registry" based proposal I gave Sep 27th (which I still think is pretty good), I don't see any other way to do this other than by going half-way back towards the old identity approach.  By "halfway", I mean to say that it doesn't define all the algorithm types, just the subset needed for our immediate needs.  So, either in addition or as a replacement to the identities for key formats, I think we should do the following:

   In ietf-crypto-types:

	   // define base identities so they can be referenced by groupings
	   identity asymmetric-key-algorithm;
	   identity symmetric-key-algorithm;
	   identity hash-algorithm;

   In ietf-asymmetric-key-algs.yang:

	    identity foo { base "asymmetric-key-algorithm" }
            ...
    
   In ietf-symmetric-key-algs.yang

	    identity bar { base "symmetric-key-algorithm" }
            ...

   In ietf-hash-algs.yang

	    identity baz { base "hash-algorithm" }
            ...


The three new modules can also be defined in the crypto-types draft, but by putting each algorithm-type into a distinct module, and by only defining a minimum number of algorithm types (there were many more before), it gets closer to what Rich wants, some modularity and no grand-unified solution.  On the downside, servers would have to implement more than one module and it we continue to need some config-false list of algorithms supported by the server (i.e., implementing the module != supporting all identities in the module).

Thoughts?  Is this something everyone can get behind? Do you think we should continue to have an identity for the "key format", or combine it with the definition of the "algorithm" node?


PS: Tom, I think this email answers your "big picture" question.

Kent // contributor