Re: [Isms] fingerprint TCs and hash types

[Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>]

On Fri, Sep 11, 2009 at 08:05:27PM +0200, Wes Hardaker wrote:
> >>>>> On Fri, 11 Sep 2009 18:51:48 +0200, Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de> said:
> 
> >> Another win, though, is that the prefixes are already standardized and
> >> we don't need to do anything else.
> 
> JS> There are networks (such as 802.15.4/6LoWPAN) where DTLS might be a
> JS> perfect fit since its session nature reduces per message overhead and
> JS> the message size constraints are significant here.
> 
> True, but sort of off topic for the thread I think since it was about a
> MIB object's contents?  I'm not saying it's not an interesting point (it
> is!), I'm just trying to make sure we don't have a disconnect in the
> conversation.

I thought the MIB objects are there to support SNMP over DTLS so I
consider them relevant for a 6LoWPAN environment. (The message size in
those environments is really small - 127 octets excluding frame
header) and fragmentation is pretty bad and buffer sizes are limited
as well. So from this perspective, it prefer a binary OCTET STRING for
the hash value.

> JS> It does seem inconsistent to be on the one hand happy with an IANA
> JS> register for fingerprint names while you want unlimited number space
> JS> extensibility with OIDs. I vote for a small integer, if needed
> JS> partition the integer number space like we do for say security models.
> JS> Or simply ship a string such as "sha-1". (BTW, does the relevant RFC
> JS> specify how to create non-standard names, e.g. an "x-" escape?)  But
> JS> in general, I think we do not necessarily need to provide more
> JS> flexibility than the PKI specs provide.
> 
> I'm now a bit confused about where your technical opinion lies, since
> you've been professing the positive and negative attributes of all the
> possibilities.
> 
> Would you prefer:
> 
> 1) a single ascii encoding with type prefix that matches the other PKIX RFC(s)
> 2) an integer (possibly partitioned) and a binary encoded value
> 3) an OID and a binary encoded value
> 
> I think all the points you've brought up are good ones.  I'm not sure
> what side of the fence you ended up on.

I prefer a binary OCTET STRING encoding together with a 1x:
DISPLAY-HINT. I have the feeling that an OID is overkill and I prefer
a compact IANA maintained INTEGER TC. Depending on the IANA rules and
if people seriously see a need for enterprise specific hash functions,
I suggest to partition the INTEGER space following the Snmp*Model
textual conventions.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>