Subject: [TSP] misc comments

From: tho <[email-masked]>
Date: Wed, 18 Dec 2002 13:55:05 +0100

rfc3161 says:
  
"The messageImprint field SHOULD contain the hash of the datum 
 to be time-stamped."
 
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"

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" 

rfc3161 says:

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

Thomas

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Dec 2002 17:00:54 +0100

Thomas,

> "The messageImprint contains the hash of the datum that SHOULD be 

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.

>  MUST have the same value, otherwise an error unacceptedPolicy) 

What happens if the requested policy is not supported ? Hence why in that 
case a TSU will report an error.

> 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'."

Denis

---

From: tho <[email-masked]>
Date: Wed, 18 Dec 2002 17:34:29 +0100

Denis, 

> correspond to the hash of the datum to be time-stamped. Hence why a SHOULD 

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 :-) 

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

>     to provide the time-stamp token by returning a pkiStatusInfo of

Yes, I know, it was just a suggestion to keep some related requisites 
closer, making the reading of the document easier

Thomas

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Dec 2002 09:03:59 +0100

Thomas,

> "should", i.e. I think that SHOULD should better be a should :-) 

OK.

> not supported.  There is instead a failure with unacceptedPolicy.

Please read again the two sentences you quote. They are correct and do not 
need to be changed.

> closer, making the reading of the document easier

No change is necessary.

Denis

---

From: tho <[email-masked]>
Date: Fri, 20 Dec 2002 17:00:31 +0100

Denis,
 
On Thu, Dec 19, 2002 at 09:03:59AM +0100, Denis Pinkas wrote:
> Please read again the two sentences you quote.

done :-)

> They are correct and do not need to be changed.

I disagree:

'SHOULD' in the first sentence is referred to 'TimeStampToken',
so the reader takes it as: it is recommended to produce a TimeStampToken
with policy = reqPolicy.

So since this is only recommended, one could potentially create a 
TimeStampToken with policy != reqPolicy which isn't the case, since the 
second sentence says: there MUST be no TimeStampToken if the supported 
policy != reqPolicy.

Thomas