module ietf-x509-cert-to-name { namespace "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name"; prefix x509c2n; import ietf-yang-types { prefix yang; } organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; contact "WG Web: WG List: WG Chair: Thomas Nadeau WG Chair: Juergen Schoenwaelder Editor: Martin Bjorklund Editor: Juergen Schoenwaelder "; description "This module contains a collection of YANG definitions for extracting a name from a X.509 certificate. The algorithm used to extract a name from a X.509 certificate was first defined in RFC 6353. Copyright (c) 2014 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. reference "RFC6353: Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)"; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2014-05-06 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for SNMP Configuration"; } typedef tls-fingerprint { type yang:hex-string { pattern '([0-9a-fA-F]){2}(:([0-9a-fA-F]){2}){0,254}'; } description "A fingerprint value that can be used to uniquely reference other data of potentially arbitrary length. An tls-fingerprint value is composed of a 1-octet hashing algorithm identifier followed by the fingerprint value. The first octet value identifying the hashing algorithm is taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining octets are filled using the results of the hashing algorithm."; reference "SNMP-TLS-TM-MIB.SnmpTLSFingerprint"; } /* Identities */ identity cert-to-name { description "Base identity for algorithms to derive a name from a certificate."; } identity specified { base cert-to-name; description "Directly specifies the name to be used for the certificate. The value of the leaf 'name' in 'cert-to-name' list is used."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSpecified"; } identity san-rfc822-name { base cert-to-name; description "Maps a subjectAltName's rfc822Name to a name. The local part of the rfc822Name is passed unaltered but the host-part of the name must be passed in lowercase. This mapping results in a 1:1 correspondence between equivalent subjectAltName rfc822Name values and name values except that the host-part of the name MUST be passed in lowercase. For example, the rfc822Name field FooBar@Example.COM is mapped to name FooBar@example.com."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANRFC822Name"; } identity san-dns-name { base cert-to-name; description "Maps a subjectAltName's dNSName to a name after first converting it to all lowercase (RFC 5280 does not specify converting to lowercase so this involves an extra step). This mapping results in a 1:1 correspondence between subjectAltName dNSName values and the name values."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANDNSName"; } identity san-ip-address { base cert-to-name; description "Maps a subjectAltName's iPAddress to a name by transforming the binary encoded address as follows: 1) for IPv4, the value is converted into a decimal-dotted quad address (e.g., '192.0.2.1'). 2) for IPv6 addresses, the value is converted into a 32-character all lowercase hexadecimal string without any colon separators. This mapping results in a 1:1 correspondence between subjectAltName iPAddress values and the name values."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANIpAddress"; } identity san-any { base cert-to-name; description "Maps any of the following fields using the corresponding mapping algorithms: +------------+-----------------+ | Type | Algorithm | |------------+-----------------| | rfc822Name | san-rfc822-name | | dNSName | san-dns-name | | iPAddress | san-ip-address | +------------+-----------------+ The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the name. The mapping algorithm specified in the 'Algorithm' column MUST be used to derive the name. This mapping results in a 1:1 correspondence between subjectAltName values and name values. The three sub-mapping algorithms produced by this combined algorithm cannot produce conflicting results between themselves."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertSANAny"; } identity common-name { base cert-to-name; description "Maps a certificate's CommonName to a name after converting it to a UTF-8 encoding. The usage of CommonNames is deprecated and users are encouraged to use subjectAltName mapping methods instead. This mapping results in a 1:1 correspondence between certificate CommonName values and name values."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertCommonName"; } /* * Groupings */ grouping cert-to-name { description "Defines nodes for mapping certificates to names. Modules that uses this grouping should describe how the resulting name is used."; list cert-to-name { key id; description "This list defines how certificates are mapped to names. The name is derived by considering each cert-to-name list entry in order. 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 as 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 as a successful match. Once a matching cert-to-name list entry has been found, the map-type is used to determine how the name associated with the certificate should be determined. See the map-type leaf's description for details on determining the name value. If it is impossible to determine a name from the cert-to-name list entry's data combined with the data presented in the certificate, then additional cert-to-name list entries MUST be searched looking for another potential match. 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 certificate's subjectAltName to map directly to a name via a 1:1 transformation."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertToTSNEntry"; leaf id { type uint32; description "The id specifies the order in which the entries in the cert-to-name list are searched. Entries with lower numbers are searched first."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertToTSNID"; } leaf fingerprint { type x509c2n:tls-fingerprint; mandatory true; description "Specifies a value with which the fingerprint of the certificate presented by the peer is compared. If the fingerprint of the certificate presented by the peer does not match the fingerprint configured, then the entry is skipped and the search for a match continues."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertToTSNFingerprint"; } leaf map-type { type identityref { base cert-to-name; } mandatory true; description "Specifies the algorithm used to map the certificate presented by the peer to a name. Mappings that need additional configuration objects should use the 'when' statement to make them conditional based on the 'map-type'."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertToTSNMapType"; } leaf name { when "../map-type = 'x509c2n:specified'"; type string; mandatory true; description "Directly specifies the NETCONF username when the 'map-type' is 'specified'."; reference "SNMP-TLS-TM-MIB.snmpTlstmCertToTSNData"; } } } }