[netmod] x509c2n:cert-to-name problem [WAS: [netconf-wg/https-notif] What is the user-id of the entity sending the notification? (#3)]

[Martin Bjorklund <[e-mail]>]

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 <[e-mail]> 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