Re: [TSP] some considerations about ordering

[Denis Pinkas <[e-mail]>]

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.

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

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