Re: [Isms] (D)TLS question (#1): selecting a client certificate touse

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Wes Hardaker" <wjhns1 at hardakers.net>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: <isms at ietf.org>
> Sent: Friday, July 03, 2009 11:37 AM
> Subject: Re: (D)TLS question (#1): selecting a client certificate touse
...
> Thanks for the opinion.  I do see advantages to having the row in the
> tlstmParamsTable be removed when the snmpTargetParamsTable is removed,
> because I think it's cleaner to do complete removal when the base config
> for anything is destroyed.
> 
> But, I'm not going to take a hard stand on it either way.  I think it'd
> work either way.  And I don't think there is a security concern with
> leaving a reference to the client side key to use around even if the
> parent row gets replaced again.

Look at it from the perspective of a management application which
provisions / performs updates to snmpTargetParamsTable.
Depending on who wrote the code and the underlying support
libraries, applications can make updates by incrementally
updating individual variables, by setting several at once, or
by deleting a row and then creating its replacement.  That
application may well be ignorant of tlstmParamsTable.

If there is no fate sharing, then none of the possible implementation
strategies could have bad side-effects.  If there is fate sharing,
then any management applications that use the delete-and-create-afresh
strategy would have the unintended side-effect of trashing entries
in the tlstmParamsTable.  I think we should avoid situations where
adding a new capability to a system requires changing the behaviour
of software that doesn't know (or care) about that capability.

> (A reference to the expected server side key, however, I'm more
> concerned with and was a future topic I was going to bring up but didn't
> want muddy the waters with more than one topic at a time)

When an application decides to stash sensitive bits here and there
in the network, it needs to take responsibility for issuing the
instructions to wipe that information when the time comes.
Anything beyond that starts entering the realm of tamper-proof
self-destruct memories.  I don't think this is substantially different
from shared keys for notifications in USM.

Randy