Re: [netconf] ietf crypto types - permanently hidden

[Juergen Schoenwaelder <[e-mail]>]

On Tue, May 07, 2019 at 09:13:44PM +0000, Kent Watsen wrote:
> 
> 
> 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.

The question is what or how much needs replication. We refer to
hardware interfaces created by the manufacturer (and identified during
system startup - or during hotplug procedures) by having a name
binding of config in <running> to operational state in <operational>.
If you configure eth0, then this config binds to an <operational>
interface with the same name. So if there is a key pair created by the
vendor, perhaps all we need is a kind of a name that can be used to
bind the config to the key.
 
> 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.

Perhaps the question is whether this is 'the key' or 'the name of the
key'.

>       - 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>.

Would it help if "generate-key" simply returns a name for the new key?

> 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>