Re: [TSP] some considerations about ordering

[tho <thomas.fossati@xxxxxx>]

Denis,

On Thu, Dec 19, 2002 at 09:03:20AM +0100, Denis Pinkas wrote:
> At this stage I would like you to focuss on interoperability testing rather 
> a re-reading of the document.
> 
> Have you started an interoperability test ?
> How many tests have you already done ?

Why this argument shift ?  The subject of this e-mail is ordering in TSP, 
not TSP interoperability, which in fact we agreed it should not be discussed 
in pkix-ml.  If you want to ask about TSP interoperability test progresses
you can drop a line to the TSP interoperability informal group.

> The question you raise has already been addressed. See below.
> 
> > rfc3161 says:
> >  
> > "If the ordering field is present and set to true, every time-stamp
> >  token from the same TSA can always be ordered based on the genTime
> >  field, regardless of the genTime accuracy."
> >  
> > The fact that ordering is only possible through genTime field
> > comparison seems too restrictive and adds complexity to the whole
> > matter; furthermore ordering is a crucial/indispensable property
> > in many application contextes so it should come easy and direct with
> > TSP, not as a misterious option.
> 
> Most applications do not care about the ordering of time-stamps within the 
> same second (genTime accuracy). 

Yes, but many other interesting TSP applications (e.g. on line auction, 
stock exchange, bid offer, etc) indeed care about ordering.

Imho TSP should (and could) address this issue simply and natively.

> The fact that such an ordering is not mandated allows for one TSU to 
> use several crypto-accelerators each one with 
> its own clock. This places less constraints on the implementation.

I disagree:

Having a monotonically increasing seqNumber doesn't prevent the use of
"a number of crypto-accelerators each one with its own clock", it is 
sufficient that they all access a shared counter.  And this doesn't seem 
too limiting to me.


Thomas