Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] draft-hardaker-isms-dtls-tm-05 submitted - tlstmNotifications



>>>>> On Mon, 14 Sep 2009 16:56:16 -0400, "David Harrington" <ietfdbh at comcast.net> said:

DH> If one were to implement the DTLS-TM using a DTLS toolkit, would the
DH> SNMP side of the API likely know why that the client certificate was
DH> invalid, or would that likely be internal to the toolkit?

1) Yes.  I've seen the openssl code and know that you can determine this
   exact situation.

2) IMHO, it doesn't matter.  It's not up to us to specify how a service
   gets managed.  As an example, many of the interface counters, for
   example, were put into "exporting data" code in the linux kernel
   because SNMP needed access to them.

   There are only two cases:

   A) A (D)TLS implementation can export the situation already today
      within the existing APIs (such as the case for OpenSSL, as
      mentioned above).

   B) A (D)TLS implementation can not export the data and as far as the
      client goes, it's a silent fail with a generic error.  If this is
      the case, then one of three things must happen:

      i) the SSL implementation implements a mechanism through "some
         manner" so that the invalid-certificate notification can be
         sent by the application using the SSL API.  Maybe through a new
         error code, or whatever.

     ii) the SSL implementation implements an internal "I got a problem"
         event and sends through some aspect to anyone listening.  A
         listener (possibly the SNMP agent application) would listen for
         a problem and send a notification when it received that
         internal software event.

    iii) the SSL implementation won't export the details that a problem
         has occurred problem through any method.  This leaves the SNMP
         agent implementation out of luck as it simply can't send the
         notification at all.  If we think this is possible, wouldn't it
         make more sense to put the notification into an optional
         conformance group than to not put it in at all?

         And eventually, hopefully, all iii)s would eventually
         transition to either i) or ii).

-- 
Wes Hardaker
Cobham Analytic Solutions

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.