Subject: RE: [TSP] misc comments

From: "Aisenberg, Michael" <[email-masked]>
Date: Wed, 18 Dec 2002 11:45:46 -0500

could you guys maybe take this off line ?

Michael Aisenberg
--VeriSign/D.C.--

-----Original Message-----
From: tho [mailto:[email-masked]] 
Sent: Wednesday, December 18, 2002 11:34 AM
To: Denis Pinkas
Cc: ietf-pkix
Subject: 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