Re: [Netconf] Updates to the ietf-netconf-tls.yang module

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Apr 11, 2012 at 11:36:59AM -0400, Alan Luchuk wrote:

>  typedef tls-fingerprint-type {
>    type binary {
>      length "1..max";
>    }
>    description
>      "A cryptographic signature (fingerprint) value that can be used to 
>       uniquely reference other data of potentially arbitrary length.";
>  }

The binary type means the data is encoded in base64. The tools I am
familiar with that produce hash values seem to generate hexadecimal
representations. 
 
>      container fingerprint {
>        choice algorithm-and-hash {
>          leaf md5 {
>            type tls-fingerprint-type;
>          }
>          leaf sha1 {
>            type tls-fingerprint-type;
>          }
>          leaf sha224 {
>            type tls-fingerprint-type;
>          }
>          leaf sha256 {
>            type tls-fingerprint-type;
>          }
>          leaf sha384 {
>            type tls-fingerprint-type;
>          }
>          leaf sha512 {
>            type tls-fingerprint-type;
>          }
>          description
>            "Specifies the signature algorithm and cryptographic 
>             signature (fingerprint) used to identify an X.509 
>             certificate.
>   
>             Implementations of this YANG module MAY, but are not 
>             required to, implement all of these cryptographic signature
>             algorithms.  Implementations of this YANG module MUST 
>             implement at least one of these cryptographic signature 
>             algorithms.  
>   
>             The available choices may be extended in the future as 
>             stronger cryptographic signature algorithms become 
>             available and are deemed necessary.";
> 
>          reference
>            "RFC 5246: The Transport Layer Security (TLS) Protocol 
>             Version 1.2; Section 7.4.1.4.1,  Signature Algorithms";
>        }  // choice algorithm-and-hash
>      }    // container fingerprint

I think we need to make this reusable, more generic and we need to put
the resulting grouping under IANA control. We need the same construct
for the SNMP configuration data model. So one way forward is that we
draft a reusable grouping and an associated fingerprint type (or hash
value type - whatever the correct term will be) to be placed into an
IANA maintained modules. We can do this here or we do it in NETMOD.  I
personally do not care much as long as we get a consistent and
reusable solution into place.

>      leaf data {
>        type string {
>          length "1..max";
>        }
>        description
>          "Auxiliary data used as optional configuration information for
>          a given mapping specified by the map-type leaf.  Only some
>          mapping systems will make use of this leaf.  When the NETCONF
>          server derives the NETCONF username from the client's presented
>          certificate, the value in this leaf MUST be ignored for any
>          mapping type that does not require data present in this leaf.";
>      }
>    }  // list cert-map
>  }    // container cert-mappings

This follows the MIB model but I am not sure this is the right way of
doing this in YANG. Martin uses a slightly different approach in
draft-bjorklund-netmod-snmp-cfg-02.txt.

>      leaf valid-not-before {
>        type yang:date-and-time;
>        description
>          "This PSK identity is not valid before the given data
>           and time.";
>      }

s/data/date/
 
>      leaf valid-not-after {
>        type yang:date-and-time;
>        description
>          "This PSK identity is not valid before the given data
>           and time.";
>      }

s/data/date/

>      leaf key {
>        type binary;
>        nacm:default-deny-all;
>        description
>          "The key associated with the PSK identity";
>      }

The same question raised above applies here. Is a base64
representation really what people feel comfortable with? Using base64
might be more OK here than above - I do not really know.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>