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

[Kent Watsen <[e-mail]>]

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




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