Re: [Isms] (D)TLS question #2: expecting a server side certificate

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

Hi -

> From: "Wes Hardaker" <wjhns1 at hardakers.net>
> To: <isms at ietf.org>
> Sent: Tuesday, July 07, 2009 10:29 AM
> Subject: [Isms] (D)TLS question #2: expecting a server side certificate
>
> 
> As just discussed, when a client (typically using the SNMP-TARGET-MIB)
> is opening an outgoing connection it needs to select a client-side
> certificate to use when making the connection.
> 
> But, it also has to have an expectation of which remote machine it's
> connecting to as well.  It shouldn't just connect to any old system that
> answers it's call.  It needs to know that the remote system is, in fact,
> the responder it was hoping to reach.
> 
> This can be done a number of ways:
> 
> 1) Add additional rows to the snmpTargetAddrTable that specifies a
>    hash-type/hash-value column pair to refer to a locally held copy of
>    the remote certificate that should be presented.  IE, this requires an
>    additional row in an additional table per target.
> 
> 2) Use one of the more standardized mapping techniques for assuring
>    target certificates are ok based on a trust-anchor CA certificate and
>    accepted mappings of either the CommonName field (which is commonly
>    what web-browsers use, for example) or the subjectAltName field,
>    which is what is currently being recommended within the IETF and the
>    CN field is actually being deprecated.  See the following draft for
>    the current thoughts and details on TLS server side identity checks:
> 
>       draft-saintandre-tls-server-id-check-00.txt
> 
>    We'd then need to specify the allowable bindings.  In particular,
>    we already have the remote entity specified by the
>    snmpTargetAddrTAddress variable which pretty much dictates the type
>    of lookup that needs to happen in the subjectAltName list.
> 
>    The nice advantage of this approach is that it's the one used in
>    industry today for other TLS connection types and requires no
>    configuration (assuming we're going to stay out of CA-trust-anchor
>    configuration because it's out of scope of the charter).
> 
> 3) A combination of #1 and #2 allowing for both 1:1 X.509 hash
>    references to an expected certificate and allowing for 1:1 mapping
>    for those folks that don't have control over the certificate
>    generation process or have such small installations that they don't
>    want to set up anything other than self-signed certificates.
> 
> 
> Personally, I'm leaning toward just #2.
> 
> Note that the current draft doesn't discuss this much and only hints at
> it.  I intend to write up text for #2 unless the WG participants feel
> I'm taking the wrong direction in this approach.
...

I think there is at least one other possibility.

(4) Use additional column(s) in tlstmParamsTable to hold the information.
Though at first glance this might seem problematic, I believe the weirdness
is no worse than with USM.

Randy