Re: [netconf] built-in trust anchors

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Yes - adding require-instance false would eliminate the issue about built-in anchors in <running>. But there are useful advantages to keeping require-instance true. I don't have a strong feeling though one way or the other.

But assuming we keep require-instance true then the question still remains of how built-in items get into <running> (and are they deletable, and do we only need keys in running, etc).

Jason

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Tuesday, January 12, 2021 3:00 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: Netconf <[e-mail]>
> Subject: Re: [netconf] built-in trust anchors
> 
> Jason,
> 
> since the leafref typedefs are weak references that do not require
> that the certs/keys exist (there is no 'require-instance true'), it
> may be OK to not have the certs/keys in <running> in terms of validity
> of the <running> datastore.
> 
> Oops, I had to reread RFC 7950 (section 9.9.3): if require-instance is
> not present, it defaults to true, so my review comment about weak
> references is incorrect, these are actually strong references and
> hence there is the need to copy what is referenced. Setting
> require-instance to false may resolve this (but we loose the ability
> to catch references to certs/keys that do not exist).
> 
> /js
> 
> On Tue, Jan 12, 2021 at 07:02:04PM +0000, Sterne, Jason (Nokia - CA/Ottawa)
> wrote:
> > Hi all,
> >
> > I noticed Jurgen's comment about built-in trust anchors in his YANG doctor
> review of trust-anchors-13. I wanted to pull that out into a dedicated
> thread/discussion here.
> >
> > Jurgen:
> >
> >
> > - Section 3 talks about populating <running> with built-in trust
> >
> >   anchors.
> >
> >
> >
> >    In order for the built-in trust anchors to be referenced by
> >
> >    configuration, the referenced certificates MUST first be copied into
> >
> >    <running>.  The certificates SHOULD be copied into <running> using
> >
> >    the same "key" values, so that the server can bind them to the built-
> >
> >    in entries.
> >
> >
> >
> >   Is the idea that this copy operation is an explicit management
> >
> >   operation or can implementations populate <running> with this
> >
> >   data automatically?
> >
> > I suppose a server *could* populate this in running as part of a built-in
> startup datastore in the absence of a startup datastore (i.e. as contents of a
> RFC8808 factory default). But I assume it is desirable to be able to delete the
> running copy of a built-in item. So the system would have to avoid populating
> these unless it is loading the factory default.
> >
> > But even if the system can populate these, we'd also want the client/user
> to be able to explicitly populate them as well (i.e. in case they delete one
> from running, and want to add it back in to reference it).
> >
> > In either case (system population of running, or client population of
> running), do we really need to put the contents of the bag or the cert into
> running?  Or is populating the list key enough since the operational copy
> shows what contents are in use for that list entry?
> >
> > Jason
> 
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>