Re: [Isms] fingerprint TCs and hash types
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] fingerprint TCs and hash types
On Thu, Sep 10, 2009 at 10:48:55PM +0200, Wes Hardaker wrote:
> After doing research about what other fingerprinting / hash textual
> conventions were out there, I found none. Which surprised me. The end
> result was there was nothing to reuse, so we do need to define our own.
>
> The -00 version of the document defines 2 TCs for "fingerprints"
> (FingerprintType and FingerprintValue). These are worded generically so
> they can be reused elsewhere easily.
I am wondering what the correct term is here: fingerprint versus
(crptographic) hashvalue versus message digest. My understanding is
that FingerprintValue contains simply the output generated by the
hash function identified by FingerprintType, correct?
> The biggest question, as I was defining the TCs, was what type of data
> the FingerprintType should be. Originally in the personal versions of
> the draft, it was an integer. But it's highly likely that many other
> hashing algorithms will be defined in the future, especially with the
> NIST hashing algorithm "contest" going on right now. So we certainly
> need something with agility. In the end, I changed the FingerprintType
> to a OID instead.
>
> Note that in our MIBs at least, it's not being used as an index so we
> don't have issues with the length restrictions it would impose on MIB
> objects. I could easily see other MIBs wanting to put it in an INDEX
> though.
In SNMP-USER-BASED-SM-MIB, we have object identifies for
authentication and encryption protocols and the relevant columns of
the tables use SNMPv2-SMI's AutonomousType. Can we do the same? Is
FingerprintType as a separate TC really needed?
/js
PS: It would be nice if the hash algorithm OBJECT-IDENTITYs would
have REFERENCE clauses.
--
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/>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.