Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

>> The problem that I have with <generate-key> generating configuration
>> directly in <running> is that <running> on the device is now different
>> from what the management system thinks should be in <running> on the
>> device.
>> 
>> I.e. it breaks the architectural simplicity that it is only the client
>> that controls what goes into in <running>

I'm confused.  At least it seems that, regardless if the client uses <edit-config> or <generate-key>, the client is performing the operation and can be fully aware of what it is <running>.  For other clients, presumable they receive a yang-push notification alerting them to the update to <running>.

Before I thought the objection regarded non-compliance to the document model, but that's not true in that, once the configuration is set (via an action), it becomes part of the document, even if nacm:default-deny-all.

Now I'm unclear what the objection is.  Martin has twice identified some issues, and both times I replied that it is acceptable to constrain the actions so as to avoid those issues.


>> If the clients would like to see the keys in the configuration then
>> they can monitor <operational> (or <intended>), and then add the keys,
>> either in raw form, or encrypted in some way.  But I still think that
>> it is architecturally cleaner if it is always the client that updates
>> the <running> configuration and never the device.
> 
> I agree.  I think it would be worthwile to explore the
> "non-action-based" solution that Rob proposed.  Is there anything in
> that solution that doesn't work?


I discussed this option in my "wide-screen needed" email from last Friday.
There are 3 cases to consider:

1) the manufacturer creates the (most likely "hidden") key pair and associated certificate.
      - these nodes MUST originate in <operational> (origin="system")
      - clients MUST replicate their (potentially encrypted or "permanently-hidden"
        enumerated) content into <running> in order reference the key and/or cert.

2) the client wishes to generate a key (hidden or not) without ever touching the
    private key.
      - presumably this occurs via a "generate-key" action (open to ideas)
      - this key ultimately MUST be in <running> in order to be referenced by config.
      - ideally it shows up in <running> as consequence of invoking the action.
      - less ideal, as in (1), a <get-data>/<edit-data> sequence could be used
        to bring the key into <running>.

3) the client wished to installed a hidden key.
      - note that we don't discuss installing a non-hidden key here, because
        that is exactly what a standard <edit-config> operation does.
      - presumably this occurs via a "install-key" action (open to ideas)
      - this is a weird case because the client is initially okay with touching the
        private key, but thereafter wants it to be protected by the system.
      - again, as with (2), ideally the key shows up in running as consequence
        of the action, but a round-trip could also get it there.


Kent // contributor