Re: [netconf] The maintenance of the algorithm identifiers in draft-ietf-crypto-types

[Kent Watsen <[e-mail]>]

> This issue touches on an open issue that we never managed to solve:
> Given an arbitrarily extensible set of identifiers, how does an
> implementation announce the subset actually supported? And related to
> that, can a YANG module define a subset that is expected to be
> supported (i.e., a conformance requirement)? I am not sure we have
> a YANG next issue for this, but we should.

Just submitted https://github.com/netmod-wg/yang-next/issues/80 <https://github.com/netmod-wg/yang-next/issues/80>.

Perhaps YANG Library be used for this?



> 
>> 2.       Some deprecated algorithm are needed by their draft.
>> 
>> a.       Some expert suggested to define those identifiers by them own within their draft. I think this is a feasible solution.
>> 
> 
> This sounds a bit like hiding deprecated crypto somehow under the
> carpet. What if multiple technologies need the same deprecated crypto
> algorithm? They create multiple identifiers for the same thing or they
> get interesting module dependencies? Crypto algorithms come and go and
> ietf-crypto-types will sooner or later have identities that will need
> to be deprecated because the crypt algorithm is not considered secure
> enough anymore. So in the long term, hiding deprecated crypto
> algorithms in some corners "under the carpet" will not work. My point
> is that "we only have good crypto algorithms defined in
> ietf-crypto-types" is not going to work for long.

Agreed.  It would seem that crypto-types should define the universe of all known algorithms, even it deprecated or obsoleted, and let the solution to Issue #80 enable implementations identify the subset they support.


>> For the above issue, I think we can add some text in draft-ietf-crypto-types to guide users from other group how to handle the above two issues.
>> 
>> Beside that,  in the future, some new algorithms might be added and some algorithms will be deprecated, we have to figure out how to made the algorithm list defined by crypto-types flexible.
> 
> The obvious way of dealing with this is to deprecate the identities
> when algorithms are considered to be not secure enough anymore.

Yes, the identity takes "status" as a substatement, so this can be done.   

This discussion makes me wonder if the module should be called iana-crytpo-types and have IANA maintain the module.

Kent // contributor