Subject: [Isms] fingerprint TCs and hash types

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Sep 2009 13:48:55 -0700

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.

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.

Feedback on these resulting TCs is greatly appreciated.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 10 Sep 2009 15:22:36 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> Sent: Thursday, September 10, 2009 1:49 PM
> To: [email-masked]
> Subject: [Isms] fingerprint TCs and hash types
> 
> 
> 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.
> 
> (FingerprintType and FingerprintValue).  These are worded 
> generically so they can be reused elsewhere easily.
> 
>
>
> 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.
> 
[Joe] I haven't had a chance to look at your document yet, but I guess
it depends on what you want specified in FingerprintType.  If you are
just looking for hashes there probably are already OIDs for this defined
for PKIX,PKCS,X509 etc.  In addition for Syslog TLS, RFC 5425, the
fingerprint support references the names for hash functions defined in
IANA registry "Hash Function Textual Names" allocated in RFC4572.  If
you are looking for something that is specifying hash and encoding then
I'm not sure there is anything formally defined.  It would be nice if
things lined up in some useful way with RFC 5425.  

> 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.
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2009 00:29:21 +0200

> 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?
 
> objects.  I could easily see other MIBs wanting to put it in an INDEX

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2009 00:33:20 +0200

On Fri, Sep 11, 2009 at 12:22:36AM +0200, Joseph Salowey (jsalowey) wrote:

> If you are just looking for hashes there probably are already OIDs
> for this defined for PKIX,PKCS,X509 etc.  In addition for Syslog
> TLS, RFC 5425, the fingerprint support references the names for hash
> functions defined in IANA registry "Hash Function Textual Names"
> allocated in RFC4572.

This IANA registry looks great - we can simply MIBify those OID
definitions.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Sep 2009 16:05:34 -0700

>>>>> On Fri, 11 Sep 2009 00:29:21 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> I am wondering what the correct term is here: fingerprint versus
JS> (crptographic) hashvalue versus message digest.

I originally used hash in a lot of places, but in the end because 5280
and 5425 (eg) refer specifically to "fingerprints" I decided that
terminology should be the correct choice and was in fairly wide use in
our other documentation.

JS> My understanding is that FingerprintValue contains simply the output
JS> generated by the hash function identified by FingerprintType,
JS> correct?

Correct.
 
JS> In SNMP-USER-BASED-SM-MIB, we have object identifies for
JS> authentication and encryption protocols and the relevant columns of
JS> the tables use SNMPv2-SMI's AutonomousType. Can we do the same? Is
JS> FingerprintType as a separate TC really needed?

That's a good point.  I wrote the TCs in an effort to more formally
standardize the description of the type, as opposed to being generic.
Otherwise you end up reproducing a lot of DESCRIPTION text everywhere
describing what the column is supposed to refer to.  Kind of like how
TransportDomain is also defining something "common".  Why wasn't a
AutonomousType used for that instead?  IMHO, we're trying to define a
commonality among multiple objects (the MIB in the TLSTM document uses
each one 3 times, for example).  The USM MIB really doesn't.  It uses a
auth and priv algorithm in just one column in just one table.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 10 Sep 2009 16:27:28 -0700

>>>>> On Thu, 10 Sep 2009 15:22:36 -0700, "Joseph Salowey (jsalowey)" <[email-masked]> said:

JS> If you are just looking for hashes there probably are already OIDs
JS> for this defined for PKIX,PKCS,X509 etc.

True, but we need to be able to point to a common list that's agreed
upon for this particular usage.  It wouldn't be hard to create an
"a list of externally defined OIDs" though, you're right.

Many of those other OIDs will fall outside of the standard SNMP OID
tree which I could see confusing some poorly written software, but I'm
not sure that we should worry about them.

JS> If you are looking for something that is specifying hash and
JS> encoding then I'm not sure there is anything formally defined.  It
JS> would be nice if things lined up in some useful way with RFC 5425.

Actually, I think 4.2.2 of RFC 5425 does define a standardized string
for encoding fingerprints and maybe it would be easiest to reduce our 2
object pair (type/value) to a single ascii string that exactly
references that string format.

For those that don't want to pull up 4.2.2 of 5425, I'll reproduce it
below:

  4.2.2.  Certificate Fingerprints

     Both client and server implementations MUST make the certificate
     fingerprints for their certificate available through a management
     interface.  The labels for the algorithms are taken from the textual
     names of the hash functions as defined in the IANA registry "Hash
     Function Textual Names" allocated in [RFC4572].

     The mechanism to generate a fingerprint is to take the hash of the
     DER-encoded certificate using a cryptographically strong algorithm,
     and convert the result into colon-separated, hexadecimal bytes, each
     represented by 2 uppercase ASCII characters.  When a fingerprint
     value is displayed or configured, the fingerprint is prepended with
     an ASCII label identifying the hash function followed by a colon.
     Implementations MUST support SHA-1 as the hash algorithm and use the
     ASCII label "sha-1" to identify the SHA-1 algorithm.  The length of a
     SHA-1 hash is 20 bytes and the length of the corresponding
     fingerprint string is 65 characters.  An example certificate
     fingerprint is:

        sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D

     During validation the hash is extracted from the fingerprint and
     compared against the hash calculated over the received certificate.

If we go this route, it makes the most sense to copy the format but
still allow it to be used generically (IE, not just for certificate
fingerprints).

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2009 06:51:36 +0200

> still allow it to be used generically (IE, not just for certificate

In general, I like this format. The downside of course is its length
compared to an OCTET STRING representation:

sha-1	 20    65
sha-256	 32   103
sha-512	 64   199

The second column shows the length of the hash and the third column
the length of the fingerprint (including the label). With sha-512, we
are still well below the common 255 octet boundary but the overhead is
significant and even the sha-1 fingerprint easily allows to ship an
additional varbind while still saving space.

Note the terminology apparently used in RFC 5425: the hash is the
value generated by the hash function and the fingerprint is the
stringified tagged representation of the hash value. This makes sense
to me and we should try to align with it - so the question really
becomes whether we represent hash values or fingerprints.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Sep 2009 06:51:14 -0700

>>>>> On Fri, 11 Sep 2009 06:51:36 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> In general, I like this format. The downside of course is its length
JS> compared to an OCTET STRING representation:

JS> sha-1	 20    65
JS> sha-256	 32   103
JS> sha-512	 64   199

Yep.  I thought about it.  But the upside of human readability and
string management might outweigh it.  Most management tools do deal with
hex <-> binary conversion fairly well, but this is still probably easier
in the end.

Another win, though, is that the prefixes are already standardized and
we don't need to do anything else.

JS> The second column shows the length of the hash and the third column
JS> the length of the fingerprint (including the label). With sha-512, we
JS> are still well below the common 255 octet boundary but the overhead is
JS> significant and even the sha-1 fingerprint easily allows to ship an
JS> additional varbind while still saving space.

If you're counting bytes in terms of bytes on the wire, you probably
need to include the type encoding as well for the second column that
holds the type which will be 2 OIDs in size length (adding in the length
for the column OID and the value OID).  However, the results will still
be small compared to the ascii encoding.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2009 18:51:48 +0200

> we don't need to do anything else.

There are networks (such as 802.15.4/6LoWPAN) where DTLS might be a
perfect fit since its session nature reduces per message overhead and
the message size constraints are significant here.
 
> be small compared to the ascii encoding.

It does seem inconsistent to be on the one hand happy with an IANA
register for fingerprint names while you want unlimited number space
extensibility with OIDs. I vote for a small integer, if needed
partition the integer number space like we do for say security models.
Or simply ship a string such as "sha-1". (BTW, does the relevant RFC
specify how to create non-standard names, e.g. an "x-" escape?)  But
in general, I think we do not necessarily need to provide more
flexibility than the PKI specs provide.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Sep 2009 11:05:27 -0700

>>>>> On Fri, 11 Sep 2009 18:51:48 +0200, Juergen Schoenwaelder <[email-masked]> said:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2009 20:22:56 +0200

> is!), I'm just trying to make sure we don't have a disconnect in the

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.

> 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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Sep 2009 11:43:00 -0700

>>>>> On Fri, 11 Sep 2009 20:22:56 +0200, Juergen Schoenwaelder <[email-masked]> said:

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

Ahh...  I missed that point.  You want to make sure our objects our
manageable in that environment.  Check.

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

I know of people that use enterprise specific hash functions, so I do
think we need to make room for it one way or another.

Thanks for solidifying your opinion; I understand it clearly now.
-- 
Wes Hardaker
Cobham Analytic Solutions