Re: [Isms] fingerprint TCs and hash types

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

On Fri, Sep 11, 2009 at 01:27:28AM +0200, Wes Hardaker wrote:
 
> 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).

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

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