Re: [Isms] fingerprint TCs and hash types

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

On Fri, Sep 11, 2009 at 03:51:14PM +0200, Wes Hardaker wrote:
> >>>>> On Fri, 11 Sep 2009 06:51:36 +0200, Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de> 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.

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

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

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