Re: [netmod] x509c2n:cert-to-name problem

[Kent Watsen]

> Ok.  To me this sounds like you need a more complex^wsophisticated
> client identification mechansim than what a plain cert-to-name gives
> you.

I wouldn't characterize it as such.   It's not complex.  It's a simple thing,
optimizing the trivial case for improved usability.  I'm unfamiliar with how
all other models might use cert-to-name, though one use is here [1], but
I imagine all uses that are associated with a TLS connection also wishing
for this optimization (this includes [1]).  For models that are not associated
with a TLS connection, the current cert-to-name 'mandatory true' is just
fine.

[1] https://tools.ietf.org/html/rfc7407#section-2.12 



> I don't think there is anything wrong with the current
> cert-to-name grouping.  

See above.


> So let's continue this discussion in the
> netconf ML, where this model is being developed.

I'll fork this part of the conversation there.


Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Jernej Tuljak]

On 30/10/2019 15:39, Robert Varga wrote:

On 10/10/2019 10:36, Jernej Tuljak wrote:

Is this correct? Or are XPath functions expected to be resolved
statically, like types?

My understanding of https://tools.ietf.org/html/rfc7950#section-6.4.1 is
that functions are bound the same way namespace prefixes are bound, i.e.
"in the module where the XPath expression is specified".


We ended up adopting this interpretation.

Jernej



Regards,
Robert



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG 1.0 module uses a grouping from a 1.1 module and the grouping contains 1.1 XPath functions?

[Robert Varga]

On 10/10/2019 10:36, Jernej Tuljak wrote:
> Is this correct? Or are XPath functions expected to be resolved
> statically, like types?

My understanding of https://tools.ietf.org/html/rfc7950#section-6.4.1 is
that functions are bound the same way namespace prefixes are bound, i.e.
"in the module where the XPath expression is specified".

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Yangdoctors last call review of draft-ietf-netmod-yang-instance-file-format-04

[Acee Lindem via Datatracker]

Reviewer: Acee Lindem
Review result: Ready with Issues

Document: draft-ietf-netmod-yang-instance-file-format-04.txt
Reviewer: Acee Lindem
Review Date: Oct 30st, 2019
Review Type: Working Group Last Call
Intended Status: Standards Track
Summary: Ready with Issues

Modules: "ietf-yang-instance-d...@2019-07-04.yang"

Tech Summary: The model describes mechanisms and statically specifying
  instance data (XML or JSON) for YANG models. Use cases are
  also discussed although not in normative text. The document
  is relatively straight forward but could benefit from some
  editorial cleanup. 

Major Comments:

 None


Minor Comments: 

 1. The "Security Considerations" in section 8 do not conform to the
recommended template in https://trac.ietf.org/trac/ops/wiki/yang-security-
guidelines>. The considerations may be completely dependent on the included
instance Data Set or some of the information in the model may also be
sensitive. However, it needs to be better described.

 2. I feel it would be helpful to explicitly state that the both read-only
and read-write instance data may be included in the instance data set.

 3. The document could requires some editorial cleanup. For example, use
complete sentenses for principles in section 2.1 and punctuate. Do not
begin sentenses with "E.g. ...". 


Nits: 

See diff below.

*** draft-ietf-netmod-yang-instance-file-format-04.txt.orig 2019-10-29 
16:36:22.0 -0400
--- draft-ietf-netmod-yang-instance-file-format-04.txt  2019-10-29 
21:40:06.0 -0400
***
*** 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and decorates it with metadata.
  
  Status of This Memo
  
--- 20,26 
 running server available.  This document specifies a standard file
 format for YANG instance data (which follows the syntax and semantic
 from existing YANG models, re-using the same format as the reply to a
! operation/request) and annotates it with metadata.
  
  Status of This Memo
  
***
*** 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items decorated with metadata
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision,suupported
!features and deviations for which the instance data set contains
 instance data
  
 Content defining Yang module(s): YANG module(s) that make up the
--- 114,127 
  Internet-Draft YANG Instance DataAugust 2019
  
  
!Instance Data Set: A named set of data items annotated with metadata
 that can be used as instance data in a YANG data tree.
  
 Instance Data File: A file containing an instance data set formatted
 according to the rules described in this document.
  
!Content-schema: A set of YANG modules with their revision, supported
!features, and deviations for which the instance data set contains
 instance data
  
 Content defining Yang module(s): YANG module(s) that make up the
***
*** 138,145 
 There is a need to document data defined in YANG models when a live
 server is not available.  Data is often needed already at design or
 implementation time or needed by groups that do not have a live
!running server available.  To facilitate this off-line delivery of
!data this document specifies a standard format for YANG instance data
 sets and YANG instance data files.
  
 The following is a list of already implemented and potential use
--- 138,145 
 There is a need to document data defined in YANG models when a live
 server is not available.  Data is often needed already at design or
 implementation time or needed by groups that do not have a live
!running server available.  To facilitate this offline delivery of
!data, this document specifies a standard format for YANG instance data
 sets and YANG instance data files.
  
 The following is a list of already implemented and potential use
***
*** 153,159 
  
 UC4  Instance data used as backup
  
!UC5  Storing the configuration of a device, e.g. for archive or audit
  purposes
  
 UC6  Storing diagnostics data
--- 153,159 
  
 UC4  Instance data used as backup
  
!UC5  Storing the configuration of a device, e.g., for archive or audit
  purposes
  
 UC6  Storing diagnostics data
***
*** 186,201 
 The following is a list of the basic principles of the instan

Re: [netmod] x509c2n:cert-to-name problem

[Martin Bjorklund]

Kent Watsen  wrote:
> 
> >> First, let me demote (2) from a SHOULD to a MAY, since there is a
> >> workaround.
> >> 
> >> The thinking is that it may be common for deployments to use the same
> >> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
> >> hence there is no need to specify a "fingerprint" in order to lookup
> >> what strategy to use.  For these cases, it would be better to not
> >> specify a fingerprint at all.  If this remains "mandatory true", the
> >> best fallback would be to specify the fingerprint for the *root* CA
> >> certs spanning the end-entity certs connecting to that endpoint.
> > 
> > Are we still talking about the usage of cert-to-name in
> > ietf-netconf-server?  
> 
> ...and ietf-restconf-server, yes.
> 
> 
> 
> > If so we have (as one example):
> > 
> >  +--rw netconf-server
> > +--rw listen! {ssh-listen or tls-listen}?
> >...
> >+--rw endpoint* [name]
> >   ...
> >   +--rw (transport)
> >  ...
> >  +--:(tls) {tls-listen}?
> > +--rw tls
> >...
> >+--rw netconf-server-parameters
> >   +--rw client-identification
> >  +--rw cert-maps
> > +--rw cert-to-name* [id]
> >+--rw id   uint32
> >+--rw fingerprint  x509c2n:tls-fingerprint
> >+--rw map-type identityref
> >+--rw name string
> > 
> > [we can discuss if this is the best structure, but that's another
> > thread]
> > 
> > What would a "cert-to-name" entry mean if the fingerprint isn't
> > present?
> 
> 
> Your snippet excludes "tis-server-perameters".  Here is a more
> complete view:
> 
>   +--rw restconf-server
>  +--rw listen! {http-listen or https-listen}?
> +--rw endpoint* [name]
>+--rw name   string
>+--rw (transport)
>   +--:(http)
>   |  +--rw http
>   | ...
>   +--:(https)
>  +--rw https
> +--rw tcp-server-parameters
> |  ...
> +--rw tls-server-parameters
> |  +--rw server-identity
> |  |  ...
> |  +--rw client-authentication!
> |  |  +--rw (required-or-optional)
> |  |  |  ...
> |  |  +--rw (local-or-external)
> |  | +--:(local)
> |  | |  +--rw ca-certs!  
> |  | |  |  ...
> |  | |  +--rw client-certs!
> |  | | ...
> |  | +--:(external)
> |  |...
> |  +--rw hello-params
> |  |  ...
> +--rw http-server-parameters
> |  +--rw server-name? string
> |  +--rw protocol-versions
> |  |  +--rw protocol-version*   enumeration
> |  +--rw client-authentication!
> | ...
> +--rw restconf-server-parameters
>+--rw client-identification
>   +--rw cert-maps
>  +--rw cert-to-name* [id]
> +--rw id uint32
> +--rw fingerprint
> |   x509c2n:tls-fingerprint
> +--rw map-type   identityref
> +--rw name   string
> 
> 
> The "tls-server-parameters" container defines the certificates used to
> authenticate the client's cert.  In many deployments, regardless how
> the client cert is authenticated, the "client-identification" section
> only needs to explain extract the "name" from the cert, a fingerprint
> isn't needed to identify either the client's end-entity or some
> intermediate cert.

Ok.  To me this sounds like you need a more complex^wsophisticated
client identification mechansim than what a plain cert-to-name gives
you.  I don't think there is anything wrong with the current
cert-to-name grouping.  So let's continue this discussion in the
netconf ML, where this model is being developed.


/martin




> 
> 
> 
> 
> > 
> >> New issue.  Why isn't "list cert-to-name" order-by user given:
> >> 
> >>  "The id specifies the order in which the entries in the
> >>   cert-to-name list are searched.  Entries with lower
> >>   numbers are searched first.";
> >> 
> >> I suspect that this is for SNMP compatibility, but then your earlier
> >> response on this thread said regarding "mandatory true" and empty
> >> fingerprint values suggested that more appropriate YANG-isms sho