Subject: [Netconf] ietf-tls/ssh groupings CA certs and peer certs

From: Balázs Kovács <[email-masked]>
Date: Tue, 6 Jun 2017 14:55:22 +0000

Hi,

In the 'server-auth' section TLS/SSH client models and the 'client-auth' section of TLS/SSH server models there is usually a leaf pair defined for configuring both trusted-ca- or trusted-server/client certificates. For instance, in the TLS client grouping:

         leaf trusted-ca-certs {

           type leafref {

             path "/ks:keystore/ks:trusted-certificates/ks:name";

           }

           description

             "A reference to a list of certificate authority (CA)

              certificates used by the TLS client to authenticate

              TLS server certificates.";

         }

         leaf trusted-server-certs {

           type leafref {

             path "/ks:keystore/ks:trusted-certificates/ks:name";

           }

           description

             "A reference to a list of server certificates used by

              the TLS client to authenticate TLS server certificates.

              A server certificate is authenticated if it is an

              exact match to a configured trusted server certificate.";

         }

       }

I attempted to figure out how to enforce the rule "A server certificate is authenticated if it is an exact match to a configured trusted server certificate" and the rule lately added by Kent mentioned in a recent mail "A server certificate is authenticated if it has a valid chain of trust to a configured trusted CA certificate."

Is the TLS/SSH client/server implementation required to check whether the X.509 certificate Basic Constraints field contains CA assertion or not before accepting a certificate set as CA or client/server certs?

https://tools.ietf.org/html/rfc5280#section-4.2.1.9

I guess this could mean that a user of keystore can mix up different type of trusted certificates in keystore within one trusted-certificate list element, which later turns out to be invalid as leafrefs are set to them.

Or is there any other hint how the above requirements shall be enforced? Should maybe the keystore model validate trusted certificate type (based on CA boolean assertion) beforehand?

Br,

Balázs