Denis,
On Wed, Dec 18, 2002 at 05:00:54PM +0100, Denis Pinkas wrote:
This is a little puzzling: the messageImprint field is mandatory and actually contains what will be (possibly) time-stamped. So I would rephrase it as:
"The messageImprint contains the hash of the datum that SHOULD be time-stamped"
There is no means for the TSU to verify that the hash that is sent does correspond to the hash of the datum to be time-stamped. Hence why a SHOULD has been used.
I take SHOULD as per rfc2119, i.e. RECOMMENDED
If you want to keep the original phrasing you should not use a capitalised
"should", i.e. I think that SHOULD should better be a should :-)
rfc3161 says:
"The reqPolicy field, if included, indicates the TSA policy under which the TimeStampToken SHOULD be provided."
but in a different paragraph it is said - so mixing MUST and SHOULD:
"If a similar field was present in the TimeStampReq, then it MUST have the same value, otherwise an error unacceptedPolicy) MUST be returned"
What happens if the requested policy is not supported ? Hence why in that case a TSU will report an error.
But there is no TimeStampToken provided in case the requested policy is not supported. There is instead a failure with unacceptedPolicy.
"The messageImprint MUST have the same value as the similar field in TimeStampReq, provided that the size of the hash value matches the expected size of the hash algorithm identified in hashAlgorithm."
should be added also that: "the hash algorithm has been recognized by the TSA as acceptable"
We already have text covering that aspect:
"If the TSA does not recognize the hash algorithm or knows that the hash algorithm is weak (a decision left to the discretion of each individual TSA), then the TSA SHOULD refuse to provide the time-stamp token by returning a pkiStatusInfo of 'bad_alg'."
Yes, I know, it was just a suggestion to keep some related requisites closer, making the reading of the document easier
Thomas