Kent Watsen <kent+i...@watsen.net> 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod