Re: [netconf] updates to client/server drafts

[Kent Watsen <[e-mail]>]

>>> I am strictly against hiding actions by encoding 'verbs' in an ad-hoc
>>> data format. I rather not support creation of keys on the device.
>> 
>> Remember we had this cases:
>> 
>> 1.  upload of keys
>> 2a. generation of keys on the box that will go into hardware protected
>>    storage (and never be accessible)
>> 2b. generation of keys on the box that will be stored on disk
>>    (and never be accessible over the mgmt interface)
>> 3.  generation of keys on the box that become (protected) configuration

This list is missing cases #1 and #3 described here: https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc <https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc>.  Also, we currently make no distinction between (2a) and (2b) - hidden is hidden, however it's implemented.



>> I think the previous version of the draft (with YANG actions) handles
>> 1 and 2 (a and b with trivial updates).
>> 
>> It is only (3) that we don't have a solution for that everybody
>> accepts.
>> 
>> So perhaps we should solve 1 and 2a and 2b, and publish that, and
>> leave 3 for the future?
> 
> This may be a way to move forward. In 2a and 2b, will there be a way
> to remove a generated key via the mgmt interface or do I have to take
> a bigger hammer to accomplish this?

I object to reverting to the approach that doesn't have the key's 3-tuple (algorithm, public key, private key) marked as mandatory true, our doing that before was unhelpful.   I was hoping that the "verbs" approach could leap over the impasse but, if Juergen is strictly against it, then we should go back to the approach described here: https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJusY>, for which a draft was never published.

In the previous link, search for "Now let's discuss what this action does" and note the two options: (1) is more user-friendly, but one that Martin appears to be strictly against, and so perhaps (2) is all we can agree on, and yes, there would need to be a third (not mentioned) action to delete the key from <operational> (presumably after having deleted the same from <running>).   Yes, it is less friendly, if you want more friendly, then let's do (1).  I'll update the draft shortly based on the less-friendly approach (2).

That said, I'm also okay with giving up (for now) trying to enable a client request the server to generate a key (hidden or not) or request the server to install a hidden key [note: these are #2 and #3 in my first link above].  I would support this less complete solution because it still supports basic configuration (#0) and manufacturer-generated keys for, e.g., IDevID certificates (#1), and thus a passable go-to-market solution.  If folks don't like the update per the previous paragraph, then this looks like a good fallback.

Kent // contributor