[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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

I agree (expecting a public outcry here :). I always felt pretty
uncomfortable with the TSA having to recognise the hash OID and checking the
length. And on top of if, this would now allow a client tp send a NO-HASH
imprint, a clear text, if they want to.

Michael
>