RE: I-D ACTION:draft-ietf-pkix-time-stamp-08.txt. HASH

[Paul Koning <pkoning@xxxxxxxxx>]

>>>>> "Michael" == Michael Zolotarev <mzolotarev@baltimore.com> writes:

 Michael> Folks, Haven't we already had a discussion about hash
 Michael> algorithm for messageImprint?


 Michael> I believe that the consensus was (and it is 100% reflected
 Michael> in the current draft) to allow a user to use whatever digest
 Michael> he/she wants. It is NOT a TSA concern if a user used 'weak'
 Michael> hash. The TSA does not inspect, modify, store or analyse the
 Michael> content of messageImprint - it only checks that the length
 Michael> of the hash corresponds to the hash algorithm. If so, then
 Michael> why should the draft imply any limitations on type of digest
 Michael> algorithms, except saying that they must be known?

 Michael> The position of the draft is, if I interpret it correctly:
 Michael> 1) The TSA does not care about hash algorithm used in
 Michael> messageImprint. But the algorithm must be known, to allow
 Michael> TSA to sanity-check the length of digested data.  2) The
 Michael> user is ADVICED to use strong hash, such as SHA-1 or MD5.

 Michael> This position of the draft with regards to hash is general,
 Michael> and provides enough space to grow, instead of being
 Michael> unnecessary restrictive. Can we leave it in peace :)?

Can we remove this unnecessary restrictions instead?

A rule of thumb of protocol design is that requirements are put in
because they are necessary for interoperability.  In the case we have
here, that rule of thumb doesn't apply.

If I were to generate my imprint with hash algorithm FRED that has a
37 byte digest, does it matter to the TSA?  No, it does not.  So why
are we saying that the TSA needs to know the OID for FRED, and the
associated digest length?

The spec says that it's done to consistency-check the length of the
imprint.  Sure, but to what end?  If I send a digest generated by FRED
but truncate it to 31 bytes, what purpose is served by the TSA saying
"naughty boy you threw away 6 bytes"?  I may in fact have a legitimate
reason for doing this -- just as IPsec has a legitimate reason for
throwing away some of the hash bytes in the HMAC construct.  If it
actually mattered to the TSA algorithms, that would be one thing.  But
since the only purpose of the check is to do the check, let's get rid
of it, simplify the spec, make the TSA implementations more reliable,
and eliminate the need to ECO the spec every time a new hash appears.

	  paul