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

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Fri, 3 Jul 2009 10:34:49 -0700, "Randy Presuhn" <randy_presuhn at mindspring.com> said:

WH> If this row is deleted it has no effect on the corresponding
WH> row in the tlstmParamsTable.

WH> If the corresponding row in the tlstmParamsTable is deleted
WH> then this row must be automatically removed."

WH> If so, I think the proposed text has a problem.
RP> Most importantly, since tlstmParamsRowStatus is part of
RP> the tlstmParamsTable, the last two sentences of the DESCRIPTION
RP> make no sense.

You're right.    "tlstmParamsTable" in both those paragraphs should be
"targetParamsTable".

RP> The real question is whether there should be any "fate sharing"
RP> between it and the snmpTargetParamsTable.  I'd strongly recommend
RP> that there be *no* coupling whatsoever.  This would simplify
RP> implementation, testing, provisioning, and operational use.  I
RP> see no benefits from "fate sharing", and lots of disadvantages.

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.

(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)

-- 
Wes Hardaker
Cobham Analytic Solutions