SNMP-TLS-TM-MIB Table View

This table is used by a (D)TLS server to map the (D)TLS
client's presented X.509 certificate to a tmSecurityName.
          
On an incoming (D)TLS/SNMP connection, the client's presented
certificate must either be validated based on an established
trust anchor, or it must directly match a fingerprint in this
table.  This table does not provide any mechanisms for
configuring the trust anchors; the transfer of any needed
trusted certificates for path validation is expected to occur
through an out-of-band transfer.
          
Once the certificate has been found acceptable (either by path
validation or directly matching a fingerprint in this table),
this table is consulted to determine the appropriate
tmSecurityName to identify with the remote connection.  This
is done by considering each active row from this table in
prioritized order according to its snmpTlstmCertToTSNID value.
Each row's snmpTlstmCertToTSNFingerprint value determines
whether the row is a match for the incoming connection:
          
    1) If the row's snmpTlstmCertToTSNFingerprint value
       identifies the presented certificate, then consider the
       row as a successful match.
          
    2) If the row's snmpTlstmCertToTSNFingerprint value
       identifies a locally held copy of a trusted CA
       certificate and that CA certificate was used to
       validate the path to the presented certificate, then
       consider the row as a successful match.
          
Once a matching row has been found, the
snmpTlstmCertToTSNMapType value can be used to determine how
the tmSecurityName to associate with the session should be
determined.  See the snmpTlstmCertToTSNMapType column's
DESCRIPTION for details on determining the tmSecurityName
value.  If it is impossible to determine a tmSecurityName from
the row's data combined with the data presented in the
          
certificate, then additional rows MUST be searched looking for
another potential match.  If a resulting tmSecurityName mapped
from a given row is not compatible with the needed
requirements of a tmSecurityName (e.g., VACM imposes a
32-octet-maximum length and the certificate derived
securityName could be longer), then it must be considered an
invalid match and additional rows MUST be searched looking for
another potential match.
          
If no matching and valid row can be found, the connection MUST
be closed and SNMP messages MUST NOT be accepted over it.
          
Missing values of snmpTlstmCertToTSNID are acceptable and
implementations should continue to the next highest numbered
row.  It is recommended that administrators skip index values
to leave room for the insertion of future rows (for example,
use values of 10 and 20 when creating initial rows).
          
Users are encouraged to make use of certificates with
subjectAltName fields that can be used as tmSecurityNames so
that a single root CA certificate can allow all child
certificate's subjectAltName to map directly to a
tmSecurityName via a 1:1 transformation.  However, this table
is flexible to allow for situations where existing deployed
certificate infrastructures do not provide adequate
subjectAltName values for use as tmSecurityNames.
Certificates may also be mapped to tmSecurityNames using the
CommonName portion of the Subject field.  However, the usage
of the CommonName field is deprecated and thus this usage is
NOT RECOMMENDED.  Direct mapping from each individual
certificate fingerprint to a tmSecurityName is also possible
but requires one entry in the table per tmSecurityName and
requires more management operations to completely configure a
device.

This table is used by a (D)TLS client when a (D)TLS
connection is being set up using an entry in the
SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
snmpTargetParamsTable with a fingerprint of a certificate to
use when establishing such a (D)TLS connection.

This table is used by a (D)TLS client when a (D)TLS
connection is being set up using an entry in the
SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
          
snmpTargetAddrTable so that the client can verify that the
correct server has been reached.  This verification can use
either a certificate fingerprint, or an identity
authenticated via certification path validation.
          
If there is an active row in this table corresponding to the
entry in the SNMP-TARGET-MIB that was used to establish the
connection, and the row's snmpTlstmAddrServerFingerprint
column has non-empty value, then the server's presented
certificate is compared with the
snmpTlstmAddrServerFingerprint value (and the
snmpTlstmAddrServerIdentity column is ignored).  If the
fingerprint matches, the verification has succeeded.  If the
fingerprint does not match, then the connection MUST be
closed.
          
If the server's presented certificate has passed
certification path validation [RFC5280] to a configured
trust anchor, and an active row exists with a zero-length
snmpTlstmAddrServerFingerprint value, then the
snmpTlstmAddrServerIdentity column contains the expected
host name.  This expected host name is then compared against
the server's certificate as follows:
          
  - Implementations MUST support matching the expected host
  name against a dNSName in the subjectAltName extension
  field and MAY support checking the name against the
  CommonName portion of the subject distinguished name.
          
  - The '*' (ASCII 0x2a) wildcard character is allowed in the
  dNSName of the subjectAltName extension (and in common
  name, if used to store the host name), but only as the
  left-most (least significant) DNS label in that value.
  This wildcard matches any left-most DNS label in the
  server name.  That is, the subject *.example.com matches
  the server names a.example.com and b.example.com, but does
  not match example.com or a.b.example.com.  Implementations
  MUST support wildcards in certificates as specified above,
  but MAY provide a configuration option to disable them.
          
  - If the locally configured name is an internationalized
  domain name, conforming implementations MUST convert it to
  the ASCII Compatible Encoding (ACE) format for performing
  comparisons, as specified in Section 7 of [RFC5280].
          
If the expected host name fails these conditions then the
connection MUST be closed.
          
If there is no row in this table corresponding to the entry
in the SNMP-TARGET-MIB and the server can be authorized by
another, implementation-dependent means, then the connection
MAY still proceed.