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

Re: [TSP] misc comments



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