Subject: Re: TSP interop update

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 11:37:32 +0100 (MET)

> 
> Peter,
> 
> > >It is simmple: if a client requests a policy and if the server supports that
> > >policy, why should the server choose a different policy ? Just to annoy the
> > >client ?
> > 
> > What if the client prefers policy X, but will accept anything if that's not
> > available?  

Cl:      want something to eat but I am not very hungry.
service: in this case we propose You our small sandwich.
 
> Simple.
>  
> First exchange:  he asks for a given policy and does not get it.
> Second exchange: he does not use the optional field reqPolicy and 
>                  thus gets what the server has.

This doesn't work if the TSA supports more than one incompatible
policies. 

> 
> Denis 
> 
> > This is standard procedure for restaurants, libraries, ...
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "Duck's off, sorry".
> > Twitchen: "We'll have the trifle then".
> > 
> > TSP however requires:
> > 
> > Twitchen: "We'll have the duck".
> > Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
> >          trying to run a TSA here. Have you any idea how much there is to do?
> >          Go away".
> > 
> > Ah, we have an RFC which standardises Fawlty Towers.
> > 
> > Peter.
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 16:16:28 +0100 (MET)

> Denis:
> >
> > IF, I did say "IF", we go into that direction, then it would
> > mean changing
> > the reqPolicy field in TimeStampReq by allowing a sequence of
> > TSA policies
> > instead of a single policy.
> >
> 
> why not to introduce in the request message an extension to express the
> ordered list containing the preferred policies?
> 
> This way, expressing which policy is preferred or requested could be a
> little more tricky, but it could achieve the task to preserve backward
> compatibility.
> 
> Gianluca
I support in pronciple Gianluca's approach, see below. But this
seems another discussion: 

Are we sure that we understand the meaning of SHOULD?

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

It seems that on one side we have people that say that the
policy used by the service MUST be identical. 

Just allowing 'SHOULD' does not mean that any particular 
interpretation is attempted, any kind of conspiracy
between clients and TSA about a particular way to request a policy,
could be possible. 

The current spec forces the TSA to return unacceptablepolicy.
in this case a client implementation needs procedure to recover 
from this problem.  

Returning a timestamp with another policy does not mean that
the client MUST accept it. It can locally simply implement
logic to throw away the time stamp because it doesn't like it
and simulate that error. The behaviour for the rest of the
application would be identical. I don't see that this means
an enormous additional complexity for the client implementation. 

Well, yes, if the nasty TSA makes You pay for something that
You haven't requested, and then claims that the standard says
that are not required to return the exact policy, so You have
to pay .... :-) 

-----

I am not in favour to change any ASN1 syntax or add
an extension to start some sort of policy negotiation. As
indicated by Gianluca, extensions seem a better way:

Just proposing a list of OIDs doesn't seem sufficient to me, it
would be a first small hack. If at some time one would be
able to formalise policies as a combination of smaller
elements, then one might end up asking that:
Please use a policy that has feature A + feature B or
fetaure A + C + D etc. 

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 18:11:07 +0100 (MET)

> Peter Gutmann wrote:
> > available?  This is standard procedure for restaurants, libraries, ...
> > 
> The client doesn't request some specific policy just for the kicks. He
> needs the time stamp for proving something to someone. This someone will
> most likely have rules according which he verifies time stamps ("I
> expect time stamps to be signed by TSA X and issued under policy Y").
> Therefore, receiving time stamp with policy which may or may not be
> equal or similar to the one requested, is of little value to the
> time-stamping client. In addition, this makes the protocol more complex
> as the client must implement procedures for dealing with time stamps
> with funny and unexpected policy identifiers.

Nothing in the protocol forbids that the TSA changes a policy.
Thus, a client must be prepared to handle unacceptedPolicy.

If in this situation, the TSA would return a time stamp with
another policy, the client or the application can still throw 
it away as part of a default implementation and simulate an
unacceptedpolicy answer. I wouldn't call this is a very complex
procedure. 

Right now, a TSA is always forced to return unacceptedPolicy. 

I am not describing any particular case for which
the TSA would return another OID as part of a standard
behaviour of whatever kind of desirable or undesirable
negotiation protcol. 

> Margus