Subject: [TSP] some considerations about ordering

From: tho <[email-masked]>
Date: Wed, 18 Dec 2002 21:35:14 +0100

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.
 
The simple and straight solution, which for some unknown - at least to me -
reason we forgot when moving from draft version 7 to 8) is to stick a
monotonically increasing number to each produced token, either restoring
the serialNumber field semantics as until draft-ietf-pkix-time-stamp-07
(so making the ordering field useless), or alternatively through an
equivalent extension field , e.g.
 
id-te-seqNumber OBJECT IDENTIFIER ::=  { <<TBD>> }
seqNumber ::= INTEGER
 
[revamped draft v.7 text]
-- The seqNumber field shall include a strictly monotonically increasing
-- integer from one TimeStampToken to the next (e.g. 45, 236, 245, 1023, ...).
-- This allows to compare the ordering of two time stamps from the same TSA.
-- This is useful in particular when two time stamps from the same TSA bear the
-- same time. The monotonic property must remain valid even after a possible
-- interruption (e.g. crash) of the service.
 
in the latter case the ordering field is still meaningful, but in a different
and broader sense than in rfc3161, i.e. (example replacement text):

  "If the ordering field is missing, or if the ordering field is present
   and set to false, then two time-stamp tokens issued by the same TSA can be
   ordered iff the two genTime differ, provided that the TSA accesses one only
   reference clock.  Instead, the ordering of time-stamp tokens from different
   TSAs is only possible when the difference between the genTime of the first
   time-stamp token and the genTime of the second time-stamp token is greater
   than the sum of the accuracies of the genTime for each time-stamp token.

   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, and/or the seqNumber extension value, regardless of the genTime
   accuracy."

Thomas

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Dec 2002 09:03:20 +0100

Thomas,

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 ?

The question you raise has already been addressed. See below.

> TSP, not as a misterious option.

Most applications do not care about the ordering of time-stamps within the 
same second (genTime accuracy). 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.

Denis

---

From: tho <[email-masked]>
Date: Thu, 19 Dec 2002 11:55:47 +0100

Denis,

> 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.

> 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 

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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 19 Dec 2002 12:49:27 +0100

tho a dit :

>ordering is a crucial/indispensable property in many application contextes
>
Which one ?
In which context has it a meaning below the accuracy level that will 
stand in a litigation ?
Where can we insure everybody that can raise a claim will hold a 
time-stamp from the very same TSA so that ordering can be compared below 
the accuracy level ?

There's nothing technically very difficult in raising the resolution of 
the time-stamp quite below 1 second, but then propagation/treatment 
delays will not garantee a fair treatment to everybody, it's very 
possible then that you send your request first, but that it looses time 
in a queue and it gets time-stamped later.

Your "many application contextes" are in fact a very closed world, if 
none of these matters.

In truth, this application is not time-stamping, but attribution of a 
numbered queue ticket.
Is TSP the most adequate protocol then ?
Should TSP aim to cover queue ticket distribution ?

---

From: tho <[email-masked]>
Date: Thu, 19 Dec 2002 14:33:37 +0100

Jean-Marc,

> Should TSP aim to cover queue ticket distribution ?

These "many application contextes" arise everywhere there is a race 
between contending parties, e.g.:
- on line auction
- stock exchange 
- bid offer
- call for tenders
in which not only is important who's first in queue but also what 
he/she has declared <- that's where time-stamp is preferable over a 
queue ticket distribution protocol.

Thomas

---

From: Scott Mustard <[email-masked]>
Date: 19 Dec 2002 12:36:52 -0500

Does anyone have a current list of addresses for TSA's and the TSP
transports they support?  We would like to run some
client tests and compare the results to some results we have compiled of
our StampServer.  Our StampServer is available at 205.162.170.85 (TCP
and HTTP) and tssdemo2.datum.com (TCP only).  If you are sending your
request via HTTP you will need to set the charset to binary and the
content type to application/timestamp-query.  

Happy Holidays,

Scott

---

From: Scott Mustard <[email-masked]>
Date: 19 Dec 2002 13:35:47 -0500

Happy Holidays,

Scott