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.