Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

I’m not sure that I have sufficient knowledge to properly comment on this point: “enable apps to create proprietary identities that work with the standard model”.

If feels to me that the ultimate solution here is that the individual protocols define protocol specific algorithm identities.  But it is unclear to me (i) whether it is helpful for those protocol specific algorithm identities to derive from a base generic algorithm identity or not, and (ii) whether it is helpful for those algorithm specific identities to be able to inherit a base algorithm specific identity.

As more concrete examples:
(i) Would be helpful for an ssh “rsa4096” identity to derive from “ssh-asymmetric-algorithm” which itself derives from “asymmetric-algorithm”?
(ii) Or would be helpful for an ssh “rsa4096” identity to derive from both “ssh-asymmetric-algorithm” and also a base cypto “rsa4096” identity that derives from “asymmetric-algorithm”?
(iii) Or is it just sufficient to have an ssh “rsa4096” identity derive from a “ssh-asymmetric-algorithm” base identity?

If the answer is (ii) then I think that there is also a further question as to whether the base “asymmetric-algorithm” identity should be defined in crypto-types.yang or in the IANA registry defined YANG file that defines the base identities?

Even if we can figure out what the identity hierarchy should look like, I’m not sure whether it makes sense to still define the “algorithm” leaf nodes in the groupings.  If they are only really truly required for the key generation rpcs then perhaps they are not required in the other places at all.e

At the moment,  I’m leaning towards leaving this out, and solving this in the future.  If we don’t put anything in, then we can’t accidentally constrain a future solution.

Rob
// As an individual contributor

From: Kent Watsen <[e-mail]>
Sent: 13 May 2020 23:13
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

Hi Rob,

Before makeing the edits to conform to Option #3 (remove “keygen”), I wanted to follow-up on a comment you made before:


One question I have, is whether the crypto-types could still define identities for the base algorithms.

I know that it’s not what you had in mind, but one possible half-step is as follows...

In ietf-crypto-types.yang, define two base identities:

     identity symmetric-algorithm {
        description "Base identity for symmetric algorithms.";
      }

      identity asymmetric-algorithm {
        description "Base identity for asymmetric algorithms.";
      }

And then, wherever there is an “algorithm” node, change its definition as follows:

OLD:

    leaf algorithm {
      type isa:symmetric-algorithm-type;
      mandatory true;
      description
        "The symmetric key’s algorithm.";
    }

NEW:

    leaf algorithm {
      type identityref {
        base symmetric-algorithm;
      }
      mandatory false;
      description
        "The symmetric key’s algorithm.";
    }

That the node would be “mandatory false” is not a big deal as the node’s existence in the configuration model serves a very passive role, just relaying anecdotal information.   Truly, the only place where the node MUST be set is in the keygen RPCs (e.g., generate-asymmetric-key).  These RPCs would be defined later, and of course would set the “algorithm" input node to “mandatory true”, where it’s needed.


PROs:
   - enable apps to create proprietary identities that work with the standard model
   - maintain placeholders to where the all the “algorithm” nodes are locations
   - negate needing to augment-in the “algorithm” nodes later

CONs:
   - will likely lead to confusion as there is no way to set a correct value until
     someone defines the concrete identities.


Thoughts?

Kent // contributor