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

Martin Bjorklund <mbj@tail-f.com> Wed, 30 October 2019 12:29 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B304120145 for <netmod@ietfa.amsl.com>; Wed, 30 Oct 2019 05:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id0KSDhUQbz1 for <netmod@ietfa.amsl.com>; Wed, 30 Oct 2019 05:29:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36D2E12013D for <netmod@ietf.org>; Wed, 30 Oct 2019 05:29:11 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id DBBCF1AE0388; Wed, 30 Oct 2019 13:29:08 +0100 (CET)
Date: Wed, 30 Oct 2019 13:28:39 +0100 (CET)
Message-Id: <20191030.132839.500650494712032488.mbj@tail-f.com>
To: kent+ietf@watsen.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016e1a0d419b-b221bfcc-d3cd-4386-a016-474e2303fba0-000000@email.amazonses.com>
References: <0100016e18283926-a00d7d13-4539-4ab0-afe8-9b9575659f6c-000000@email.amazonses.com> <20191029.211356.1886721657930464996.mbj@tail-f.com> <0100016e1a0d419b-b221bfcc-d3cd-4386-a016-474e2303fba0-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Kl7BWVTn8Ngr9ctSlN1UrwC13hs>
Subject: Re: [netmod] x509c2n:cert-to-name problem
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 12:29:13 -0000

Kent Watsen <kent+ietf@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
>