Subject: Re: TSP interop update

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2002 19:34:13 +0100 (MET)

Hello,

During some messages exchanged in a small group of TSA testers the
following 'problem' had been discovered:

Draft 4 of RFC 3161 had a new requirement for the value of the
policy in the TST: 

"The policy field MUST indicate the TSAs policy under which the response was 
 produced. If a similar field was present in the TimeStampReq, then it MUST 
 have the same value, otherwise an error (badRequest) MUST be returned."

Which finally became:

  "The policy field MUST indicate the TSA's policy under which the
   response was produced.  If a similar field was present in the
   TimeStampReq, then it MUST have the same value, otherwise an error
   (unacceptedPolicy) MUST be returned."

I have not been able to determine why this change in draft 4 had been
made. maybe I have overlooked the archives but as far as I know there
was no summary of changes text from 3->4.

Other parts of the standard that are related to the
policy have not been changed:

  "The reqPolicy field, if included, indicates the TSA policy under
   which the TimeStampToken SHOULD be provided."  

(Note that in version 3 of the draft the SHOULD was 'should')

"The client application SHOULD check the policy field to determine
whether or not the policy under which the token was issued is acceptable
for the application.  The client MAY ignore this field if that is
acceptable for the intended application."

IMO these two statements do not correspond to changed text of 'MUST be
identical'. (cf treatment of nocne and messagedigest)

There are two possible ways: 

- The 'MUST have the same value' is intended (why please??)
  
  Then the SHOULDs in the other two paragraphs should be changed
  to MUST similar to other requirements for example for the
  messagedigest or nonce. 

  example potential text: 

  "The reqPolicy field, if included, indicates the TSA policy under
   which the TimeStampToken MUST be provided."  

"If the client application has provided a policy identifier, it MUST 
 check whether the policy field returned is identical. 
 If not, the client application { SHOULD/MAY ??} check the value
 in order to determine whether or not the policy under which the 
 token was issued is acceptable for the application.  
 The client MAY ignore this field if that is acceptable for the
 intended application."

 What does "MAY ignore mean?"

- The change in 3->4 is not necessary and the two other paragraphs 
  containing 'SHOULD check" etc in RFC 3161 define the intended meaning. 

Peter

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Jan 2002 16:25:40 +0100

Peter,

>    (unacceptedPolicy) MUST be returned."

BadRequest is when the request is malformed. Here the request is well formed
but the policy is not supported (unacceptedPolicy) and thus is not accepted.
This was the reason for that change.
 
>    which the TimeStampToken SHOULD be provided."

If the server does not support the policy, we cannot force the server to
support it, and hence why SHALL cannot be simply substituted. In order 
to be more explicit we could say:

   The reqPolicy field, if included, indicates the TSA policy under 
   which the TimeStampToken SHALL be issued (provided that policy is 
   supported by the server).

Denis