Re: [netconf] Move generate key actions? (pulling on a string unravels all)

[Kent Watsen <[e-mail]>]

I completed moving the key-generating actions from keystone (KS) to crypto-types (CT).  The diffs can be seen here:

For CT: https://github.com/netconf-wg/crypto-types/commit/5116a8bd59c7253f404fb2ec00f21bcec9e27771 <https://github.com/netconf-wg/crypto-types/commit/5116a8bd59c7253f404fb2ec00f21bcec9e27771>For KS: https://github.com/netconf-wg/keystore/commit/20ce25acba43ce5c28e53aca7f76a3083aa125ad <https://github.com/netconf-wg/keystore/commit/20ce25acba43ce5c28e53aca7f76a3083aa125ad>

More importantly, the issue raised below disappeared, as I realized that we were only planning to move the “config false” supported algorithm lists (not the alg enums) to the SSH and TLS drafts, thus there was/is no need to introduce any base identities.

Kent // contributor



> On Feb 10, 2020, at 12:27 PM, Kent Watsen <[e-mail]> wrote:
> 
> All,
> 
> This is worse than it seems, so please dig in!
> 
> 1) currently the "generate-symmetric-key" and “generate-asymmetric-key” actions are defined in ietf-keystore, primarily so another keystore-key can be leafref-ed so that the output (i.e., the generated key) can be encrypted.
> 
> 2) however, it seems wrong that only servers implementing ietf-keystore should be able to generate keys.  Thus I was thinking to move the generate-* actions to ietf-crypto-types as RPCs (not actions).   
> 
> i) Them not being actions is not an issue as the only reason they were actions originally is because we were thinking that they would be like object-oriented methods, adding the generated key to the parent node’s list of keys.  But now that the generated keys are returned in the output, it no longer matters if it is an action or RPC.
> 
> ii) In order to retain the ability to encrypt the generated key, the ietf-keystore module can augment the ietf-crypto-types RPCs with the "encrypt-with” inout parameter.
> 
> 3) I started to make this change in my local copy to see how it would play out, and immediately ran into the seemingly unrelated issue that the “algorithm” input parameter is of type "iasa:asymmetric-algorithm-type” or  "isa:symmetric-algorithm-type”, depending on the kind of key that is being generated.  Mind you, the “iasa” and “isa” prefixed lists of supported keys are exactly that which we said we’d split/move to the ssh-client-server and tls-client-server drafts (PS: still waiting for someone to send a Pull Request for this change).  That is, the 3 lists of supported algorithms becomes 6 lists (i.e., 3 for SSH and 3 for TLS).
> 
> 4) But we can’t really move these algorithms to the SSH and TLS modules because the "public-key-grouping” and "symmetric-key-grouping” groupings have an “algorithm” leaf that leafref's these lists…so the move would cause an unresolved referenced and fail YANG validation.   FWIW, this issue exists regardless if we move the actions from keystore to crypto-types…it is only in my trying to do it that this issue was revealed...
> 
> 5) this issue suggests using “identities” rather than “enumerations” for the lists of supported algorithms.  That is, base identities in ietf-crypt-types enable identityrefs…. But if we use identities (instead of opstate-lists of supported algorithm enumerations), we could instead either have a “module” or “feature” per identity, which would still produce an opstate list (i.e., ietf-yang-library), but there would be many of either modules or features, which may be off-putting…
> 
> Options:
> module per identity (many modules, use YL to determine which algs server supports)
> module per alg-type (e.g., SSH/TLS * symmetric/assymetric/hash) with a feature per identity (many features!)
> module per alg-type + a separate runtime opstate list of supported algorithms (unnecessary lists?)
> Suggestions?
> 
> Kent // contributor
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf