Re: [netconf] crypto-types fallback strategy

[Schönwälder, Jürgen <[e-mail]>]

On Tue, Oct 08, 2019 at 12:12:16AM +0000, Kent Watsen wrote:
> 
> 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" }
>             ...
> 

I think there are

a) cryptographic algorithms (the primitives)
b) operating modes for symmetric algorithms etc.
c) combinations of a) and b) used by certain security protocols or
   sub-protocols (keyex vs data transfer)
d) key formats that are used together to combinations from b)

and we seem to sometimes confuse these things. If this is a proposal
for a), then fine. But these registries do not help much with b)-d),

I believe b) and d) tend to be security protocol specific (and may
even be security protocol version specific).

Looking at things from a management perspective, I assume the
relevance for configuration is d) to a).

Hence, I believe it makes sense to create a module with definitions
specifically needed for SSH and a module with definitions specifically
needed for TLS. (The SNMP model in RFCC 7407 has a several choices to
deal with different security "algorithms". This does not really matter
except that we also back then went for a security protocol specific
solution.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>