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

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> 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 should be
> >> used, in general.  "ordered-by user" vs "ordered by id" seems like
> >> such a case.
> > 
> > Yes I agree.  I don't recall but I also suspect the motivation was
> > simple mapping to the MIB.  (mapping a zero-length string to/from an
> > optional leaf is straightforward).
> 
> Is it too late to fix?  No reason to hold onto SNMP compatibility,
> given SNMP is now deprecated...
> 
> 
> Kent // contributor
>