Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

Hi Rich, Rob,

> > I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice
>  
> Every OID definition I’ve seen has a name, often both a short name and a long name.  Look at https://oid-info.com <https://oid-info.com/>  There is also a URN syntax for OID’s. The widely-used OpenSSL has a built-in mapping; see https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt <https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt> .

I believe that each OID has a common name that can be used.

nit: s/https/http/   (the site didn't resolve until I removed the 's')



> > I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required. 
>  
> I am strongly in favor of not trying to create a unified module for *all* cryptography, as I have posted before.  I don’t know enough about YANG to know if this is the only way to achieve that, but this seems like the right thing to do. There are new types of crypto coming (look at what CFRG is doing), and they are likely to create new object types.

Rich, can you explain why not try to define a unified module for all cryptography?   Is it because it is a monster effort?   Would many smaller efforts that, together, achieve the same thing be different in a meaningful way?


Kent