[netconf] ietf-crypto-types: read-only nodes to provide fingerprints of public keys and certificates

["[e-mail]" <[e-mail]>]

Hi,



I would like to make a suggestion regarding the groupings for public keys and certificates in draft-ietf-netconf-crypto-types-14:



Especially in case of manual server verification in applications like (Open)SSH or HTTPS (self-signed certs), it is quite common to compare fingerprints of an (remote) identity.

Therefore it might be useful to add operational data ("config false") nodes to those groupings to provide the fingerprints of a public key/certificate.

That would provide easy manual verification, e.g. of a whole certificate chain stored in <running>.



Any feedback on this proposal is much appreciated.



Please find an example of how a generic realization in the crypto-types module could look like below:



Since "x509c2n:tls-fingerprint" is probably not an appropriate namespace to describe a public-key fingerprint, an according datatype could look like that:

  typedef fingerprint {

    type yang:hex-string {

      /* max string range of x509c2n:tls-fingerprint's pattern restriction */

      length "min .. 764";

    }

  }



A new grouping to provide fingerprints depending on the available hashing algorithms:

  grouping fingerprints-grouping {

    description

      "A set of fingerprints of a public key or a certificate.

       Implementations SHOULD NOT provide a list entry for an algorithm
       that is not being listed as supported in iana-hash-algs.";

   container fingerprints {

      description

        "A set of fingerprints of a public key or a certificate.";

      list fingerprint {

        key "algorithm";

        description

          "A fingerprint.";

        leaf algorithm {

          type iha:hash-algorithm-type;

          description

            "The hashing algorithm.";

        }

        leaf hash {

          type fingerprint;

          description

            "The fingerprint value.";

        }

      }

    }

  }



The resulting updated groupings would look like that: (*) indicates the new nodes

  grouping public-key-grouping
    +-- algorithm                 iasa:asymmetric-algorithm-type
 (*)+--ro fingerprints
 (*)|  +--ro fingerprint* [algorithm]
 (*)|     +--ro algorithm             iha:hash-algorithm-type
 (*)|     +--ro hash                  fingerprint
    +-- public-key-format?        identityref
    +-- public-key                binary



  grouping trust-anchor-cert-grouping
    +-- cert?                     trust-anchor-cert-cms
 (*)+--ro fingerprints
 (*)|  +--ro fingerprint* [algorithm]
 (*)|     +--ro algorithm             iha:hash-algorithm-type
 (*)|     +--ro hash                  fingerprint
    +---n certificate-expiration
       +-- expiration-date    yang:date-and-time



  grouping end-entity-cert-grouping
    +-- cert?                     end-entity-cert-cms
 (*)+--ro fingerprints
 (*)|  +--ro fingerprint* [algorithm]
 (*)|     +--ro algorithm             iha:hash-algorithm-type
 (*)|     +--ro hash                  fingerprint
    +---n certificate-expiration
       +-- expiration-date    yang:date-and-time



Please note that leaf-lists as used in "trust-anchor-certs-grouping" or "end-entity-certs-grouping" wouldn't be considered by that approach.



Again, any feedback is appreciated.



Thanks

BR Maurice







With best regards,
Maurice Angermann

Siemens AG
Digital Industries
Process Automation
Software House Khe
DI PA CI R&D 2
Oestliche Rheinbrueckenstr. 50
76187 Karlsruhe, Germany
mailto:[e-mail]
www.siemens.com/ingenuityforlife<http://www.siemens.com/ingenuityforlife>

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322