>> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
