Re: [netconf] updates to client/server drafts

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Jun 11, 2019 at 08:53:57PM +0000, Kent Watsen wrote:
> Hi Juergen,
> 
> Thanks for broaching the topic, I'm hoping we can suss out such things before the drafts enter Last Call in 2-3 weeks.
> 
> 
> >> 1) in crypto-types, replaced the 'action' statements with 'crypt-hash' like equivalents.  If folks don't like the "verbs", then we can simply remove them, having no solution for asking the device to generate a key or install a hidden key.
> >> 
> > 
> > I am not sure this approach. This just hides the discussion in a
> > special purpose construction:
> > 
> >               Without the optional '-and-hidden' postfix, the generated
> >               key pair is stored in the configuration data store as if
> >               the values had been configured by the client.
> 
> 
> True, this special purpose construction sidesteps us needing to resolve the larger "can actions effect configuration" discussion.  But perhaps that is okay given that the need to have actions effecting configuration is exceedingly rare?   It's clear that you're not thrilled by this approach, but it's unclear if the reason you're not thrilled is because of the approach or because it's sidestepping the larger discussion.    Also, what do you propose we do about it?  Choices:
> 
> a) nix the "verbs", leaving the solution for asking the device to generate a key and install a hidden key to a future update.
> b) resurrect the 'action' based discussion.
> c) cautiously move forward with the "verbs" approach.
> d) something else?

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. That
said, I still think it is desirable to find a solution to support this
that is acceptable to the WG. But replacing an action with 'verbs' and
side effects in config data is for me just obscuring the issue not
solving it.

> > A more general note: I assume that humans configuring systems are
> > mostly familiar with common file formats for X.509 certificates like
> > .pem files or similar. It seems these formats can't be used with the
> > YANG module and that tools are needed to extract the pieces of data
> > and to ship them to the server. Perhaps usability would be higher if
> > the module would support upload/download of X.509 related material in
> > commonly used formats.
> 
> This comment seems to apply to the entire client/server suite of drafts.  I believe that your statement regards the somewhat heavy use of CMS structures for conveyed certificate chains, rather than the non-standard though nearly ubiquitous concatenation of PEM-encoded certificates.

Right.
 
> I believe that bi-directional `openssl` based one-liners exist for converting between CMS and concatenated-PEMs.  Would it help if the crypto-types draft included an Appendix section to supply the `openssl` commands for just the 'trust-anchor-cert-cms' and 'end-entity-cert-cms' typedefs?  [FWIW, constructing said CMS structures in Python is trivial.]

Yes, there are a number of these -cms types and I suspect that not all
people will not know how to generate the proper CMS / DER-encoded
binary (and then base64 encoded XML/JSON) values that are required by
the YANG model. I am much more used to PEM formats but perhaps this is
just my ignorance.

/js

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