Re: [netconf] built-in trust anchors

[Martin Björklund <[e-mail]>]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]> wrote:
> 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.

The current text has this:

   A server MUST reject attempts to modify any aspect of built-in trust
   anchors, both the certificates themselves and the bags that contain
   them.  That these certificates are "configured" in <running> is an
   illusion, as they are strictly a read-only subset of that which must
   already exist in <operational>.

This is really weird special handling of some config in <running>,
which goes against the idea that the client(s) "own" the contents of
<running>.

It is also not clear what happens if the set of built-in trust anchors
are changed during a software upgrade.  Will they be removed from
<running> automatically?  If so, <running> may become invalid with
dangling refrences.  If they are not removed, they will be stuck
there, since a client can't remove them.

I agree that strong references are preferred in most situations, but
in this case I think a weak reference is the best solution.  It has
it's own set of problems that must be solved though, specifically what
happens if the target doesn't exist.

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

I think these lists have some mandatory elements, which means that you
can't just copy the keys.


/martin



> 
> 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/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf