Re: [Isms] fingerprint TCs and hash types

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> 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.
 
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.

-- 
Wes Hardaker
Cobham Analytic Solutions