Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherName mapping resolution

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Dec 2009 20:32:41 -0500

--On Wednesday, December 02, 2009 05:19:14 PM -0800 Wes Hardaker 
<[email-masked]> wrote:

>     tlstmCertSANAny

I'm not sure what this is supposed to do.  It sounds like "pick any 
arbitrary SAN you see in the certificate, and turn it into a securityName". 
But that leaves unspecified which one to pick if there is more than one, 
and how to turn arbitrary otherName types into an SNMP securityName.

Now, I'm fine with having a mapping type that essentially means the mapping 
is locally defined and not guaranteed to be interoperable.  In fact, I 
argued for having such a thing.  But I'd call it something like 
tlstmCertLocalMapping.

> The *'d fields would then be used to do *any* type of mapping, and the
> 'specified' enum would then be converted to a OBJECT-IDENTITY which
> would say to directly use the data found in the now generic
> tlstmCertToSNMapData column.  The advantage of this would be that any
> other future extensions could have a spare column of data to help
> configure the OBJECT-IDENTITY's behavior.  The downside is that making
> it generic makes it "less straightforward".

This sounds like a good idea, particularly since it provides a nice hole 
for future (or private) mapping types to use for configuration.  You might 
consider ANY DEFINED BY tlstmCertToSNMapType instead of OCTET STRING; I 
don't know how people feel about such constructs in MIB's.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Dec 2009 18:48:22 -0800

>>>>> On Wed, 02 Dec 2009 20:32:41 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> I'm not sure what this is supposed to do.  It sounds like "pick any
JH> arbitrary SAN you see in the certificate, and turn it into a
JH> securityName". But that leaves unspecified which one to pick if there
JH> is more than one, and how to turn arbitrary otherName types into an
JH> SNMP securityName.

You'll find if you read the definition in the MIB/patch I sent as well
that it limits it to one of the other 3 existing types (rfc822, dns,
ipaddress).  And it says you pick the first of them.

JH> Now, I'm fine with having a mapping type that essentially means the
JH> mapping is locally defined and not guaranteed to be interoperable.  In
JH> fact, I argued for having such a thing.  But I'd call it something
JH> like tlstmCertLocalMapping.

Everything I left is completely deterministic.  Locally defined will
require an OID to be defined either in standards space or enterprises
space and will achieve 100% interoperability as well.  We aren't
supporting anything in the included MIB that says "interoperate on your
own" but left it extensible so vendors or future standards can define
new mappings, which I think is the right way to go.  Please do read the
text in the included patch/MIB for details.

JH> You might consider ANY DEFINED BY tlstmCertToSNMapType instead of
JH> OCTET STRING; I don't know how people feel about such constructs in
JH> MIB's.

You can't use them in MIBs.  The best you can do in a MIB for generic is
"OCTET STRING" (actually, there is OPAQUE too but that's a can of worms
you don't want to get near and is in fact even deprecated if I recall).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Dec 2009 21:49:51 -0500

> ipaddress).  And it says you pick the first of them.

Nevermind.

> you don't want to get near and is in fact even deprecated if I recall).

That's fine; I'm quite familiar with the OCTET STRING approach since that's 
what Kerberos does.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 2 Dec 2009 19:21:22 -0800

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Jeffrey Hutzelman" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, December 02, 2009 6:48 PM
> Subject: Re: [Isms] TLSTM Issue #1: proposed text for otherNamemapping resolution
...
> you don't want to get near and is in fact even deprecated if I recall).

Opaque would be the right thing, but almost nobody ever got it right, so
RFC 2578 says:

|7.1.9.  Opaque
|
|   The Opaque type is provided solely for backward-compatibility, and
|   shall not be used for newly-defined object types.

You're stuck with OCTET STRING.

Randy