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