Hi, Since this is a problem with ietf-x509-cert-to-name I reply to this question here, rather than buried in a reply to another issue for another document ;-)
Kent Watsen <[email protected]> wrote: > Separately, I just noticed an issue with the > `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name. > > ``` > leaf fingerprint { > type x509c2n:tls-fingerprint; > mandatory true; > description > "Specifies a value with which the fingerprint of the > full certificate presented by the peer is compared. If > the fingerprint of the full certificate presented by the > peer does not match the fingerprint configured, then the > entry is skipped, and the search for a match continues."; > ``` > > This definition seems to exclude authenticating client certificates > via a trust anchor certificate as, if one can configure a fingerprint, > then one could also configure the whole certificate (e.g., > `tls-server-parameters/client-authentication/client-certs`), thus > obviating the need for > `tls-server-parameters/client-authentication/ca-certs`. [...] > A better definition (I think) would've been: > > ``` > OLD: full certificate presented by the peer > NEW: full certificate of the certificate used to authenticate the > certificate presented by the peer, which MAY be the peer's end-entity > certificate. > ``` Hmm, I think you found an inconsisteny in this module. Note that the description of the list itself has: The cert-to-name entry's fingerprint determines whether the list entry is a match: 1) If the cert-to-name list entry's fingerprint value matches that of the presented certificate, then consider the list entry a successful match. 2) If the cert-to-name list entry's fingerprint value matches that of a locally held copy of a trusted CA certificate, and that CA certificate was part of the CA certificate chain to the presented certificate, then consider the list entry a successful match. Also note: Security administrators are encouraged to make use of certificates with subjectAltName fields that can be mapped to names so that a single root CA certificate can allow all child certificates' subjectAltName fields to map directly to a name via a 1:1 transformation. So I think this is a bug in the description of "leaf fingerprint". > I note that `fingerprint` may be 0 characters in length, which is what > netconf/restconf servers wanting to support authenticating clients via > a trust anchor will need to do in their configurations. I'll update > the examples in those drafts to include an empty `fingerprint` node. But 0-length fingerprint won't match anything, which means you won't get a user name and the client can't be authenticated, and the session dropped. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
