[TSP] some considerations about ordering

tho <thomas.fossati@tin.it> Wed, 18 December 2002 21:04 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18688 for <pkix-archive@lists.ietf.org>; Wed, 18 Dec 2002 16:04:41 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBIKZWq12423 for ietf-pkix-bks; Wed, 18 Dec 2002 12:35:32 -0800 (PST)
Received: from smtp4.cp.tin.it (vsmtp4.tin.it [212.216.176.224]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBIKZTo12415 for <ietf-pkix@imc.org>; Wed, 18 Dec 2002 12:35:30 -0800 (PST)
Received: from congo.homeunix.net (80.181.227.189) by smtp4.cp.tin.it (6.5.029) id 3DF9C96A00205FFF for ietf-pkix@imc.org; Wed, 18 Dec 2002 21:35:19 +0100
Received: from congo.homeunix.net (localhost [127.0.0.1]) by congo.homeunix.net (8.12.3/8.12.3) with ESMTP id gBIKZHt9001589 for <ietf-pkix@imc.org>; Wed, 18 Dec 2002 21:35:18 +0100 (CET) (envelope-from tho@congo.homeunix.net)
Received: (from tho@localhost) by congo.homeunix.net (8.12.3/8.12.3/Submit) id gBIKZFjU001588 for ietf-pkix@imc.org; Wed, 18 Dec 2002 21:35:15 +0100 (CET)
Date: Wed, 18 Dec 2002 21:35:14 +0100
From: tho <thomas.fossati@tin.it>
To: ietf-pkix <ietf-pkix@imc.org>
Subject: [TSP] some considerations about ordering
Message-ID: <20021218213514.A1569@congo.homeunix.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Operating-System: FreeBSD
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

 
 
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