Subject: RE: TSA Response serialNumber Field

From: Michael Zolotarev <[email-masked]>
Date: Fri, 26 May 2000 15:40:03 +1000

Folks,

As I can recall, the original idea behind the SerialNumber was simple: to
preserve the ordering, and to arbitrate between timestamps which happen to
have the same time value. It itself enforces that each timestamp is now
unique (time+SerialNumber_within_time_interval is a unique combination),
though the global uniqueness of the stamps was not the initial intent.

Considering that the original intention for the field is still there, let me
put a few short points together, to straighten things up a bit:

Point 1: "SerialNumber" in TSA is not the same thing as the 2459's serial
number. 

Point 2: a hash can NOT be used as a serialNumber - we need some sort of
*integer sequentual etc numbering*.

Point 3: Within the same time value interval, the numbering can be "strictly
monotonically incremental by one" (1,2,3,4) or more relaxed "strictly
monotonically increasing" (1,34,111,112,654). Both choices are perfectly
suitable for the purpose. But the latter is a superset of the former, so we
can use just "scrictly monotonically increasing".

Point 4: The numbering counter can be "ever going", or start over with every
new time interval. Both choices are perfectly suitable for the purpose. So
that the draft should NOT dictate which one to be used. 

Point 5: Depending on which numbering scheme is used by the TSA, a
SerialNumber can reach a big value. Therefore the recepient should be
prepared to handle 4+ bytes integer.

Point 6: A TSA can switch from one numbering scheme to another, or reset the
counter at its will, provided that the order (uniqueness) of timestamps with
the same time interval is preserved (not violated). This is the only comment
the draft should probably bear. 

Point 7: A unique Time+SerialNumber_within_that_interval combination should
be sufficient for audits.

To summarize all above, the [slightly modified] statement about the
SerialNumber could be: 
***
The serialNumber field shall include a strictly monotonically increasing
integer (e.g. 45, 236, 245, 1023, ...), across all time stamps or at least
across all tokens bearing the same time value. This guarantees that each
token is unique and 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.
This field also provides the way to build a unique identifier to reference
the token. It should be noticed that the ordering is defined by the
combination of the time value and the SerialNumber of the tokens. The
ordering MUST be maintained even after a possible interruption (e.g. crash)
of the service. A recepient of a token MUST be able to handle serial numbers
that are greater than 4-bytes integers.
***

Regards
Michael

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 May 2000 15:38:26 +0200

Michael,

Thank you for this good analysis of the issue.

The problem we have is that, currently, the serialNumber is used 
for two different purposes in order to address two different 
requirements, hence why we have some difficulties.
These requirements are the following:

1) Uniquely designate a TS token using a combination of the TSA's
name and the serialNumber. This is how serialNumber is used in RFC
2459 for both Public Key Certificates and CRLs, as well as how it is
used for Attributes Certificates, at least at the time being as
defined by ISO (and I suppose we are not going to change this). :-)

2) Distinguish betwen two time-stamps issued with the same time
(e.g. the same second).

I would propose a simple (and new) way to solve this issue: use one
parameter for one purpose only.

1) for the first requirement, stick to the use of this parameter as
required for PKCs, CRLs in RFC 2459 and for ACs. This means only 
require uniqueness and nothing else. We may then keep the name 
"serialNumber".

2) for the second requirement, let us first look at it slightly
differently. 

Today we implicitly MANDATE TSAs to be able to indicate which one of
two time stamps (e.g. issued within the same second) was first. We
could simply ALLOW TSAs to be able to indicate which one of two time
stamps (e.g. issued within the same second) was first. In many
cases, the ordering of the token will be artificial and even wrong,
in particular when the TSA is handling multiple crypto-engines in
parallel. It may be indesirable or pretty hard to try to distinguish
between who came first in a waiting queue for a given crypto-engine
and who came out first from a waiting queue for another given
crypto-engine from the same TSA. In some designs shall parallel
crypto-engines use the same clock or can they use their own clock ?
If the clock is different, how is it possible to still guarantee the
ordering ? I would not like to answer to these questions and hence
mandate designs where all TSAs MUST always guarantee the ordering.
This would prevent some implentation designs. I would rather prefer
to ALLOW TSAs to guarantee the ordering, if they wish to do so. This
is more flexible and also recognizes the fact that mandating this
requirement in some environments is not at all needed.

Now let us look how to achieve these goals:

genTime is defined as the time at which the timestamp has been
created by the TSA. It can include any *precision*. However the
accuraccy (i.e. the time difference with UTC - not the precision) is
indicated in another parameter called accuracy which represents the
time deviation around the UTC time contained in GeneralizedTime.

If a TSA wants to ALLOW users to make the difference, it may then
use a precision much better than the second (and, for example, 
still have an accuracy of one second). Otherwise it does what 
it wants.

To this end the following changes are proposed:

Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a unique integer for each newly 
       generated time stamp token.

In section 2.4.2. Page 8. The serialNumber is an integer assigned by
the TSA to each Time Stamp token. It MUST be unique for each Time
Stamp token issued by a given TSA (i.e., the TSA name and
serialNumber identify a unique Time Stamp token).

On page 8, just after the sentence: " However, when there is no need
to have a precision better than the second, then GeneralizedTime
with a precision limited to one second should be used (as in 
[RFC 2459]).", add the following:

"When there is a need to sequence the time stamps issued from the
same TSA at a granularity better than the second, then a greater
precision must be used and be commensurate with the number of time
stamps that can be generated by that TSA within the same second."
  
There is however one major drawback with this. How can a TS user
know if the TS token issued by a given TSA are garanteed or not to
be ordered ? Simply looking at genTime and accuracy does not allow
to always make the difference. So we would need another parameter
(e.g. a BOOLEAN) :-( or use the security policy which is not
directly machine processable. :-(

The BOOLEAN would be "better", simple to understand, and allow more
more flexibility than we have today. It is quite late to introduce
another parameter at this stage, :-(  but if it is not now, it will
never be. :-). 

If we do so, it could be after:

      policy      PolicyInformation,

add:

     ordering     BOOLEAN DEFAULT FALSE,

with the following explanations:

" If the ordering field is present and set to true, Time Stamps
tokens
can always be ordered by looking only at the genTime parameter,
whatever their accuracy is.

If the ordering field is missing, or if the ordering field is
present and set to false, then the genTime field only indicates the
time at which the timestamp has been created by the TSA. In such 
a case, the ordering of Time Stamps issued by the same TSA is 
only possible when the difference between their genTime is greater 
than the accuracy of the first Time Stamp token plus the accuracy 
of the second Time Stamp token."

Now, an alternative to this proposal would be to MANDATE Time stamps
ordering (which does not appear to be a good requirement as
explained earlier). If so we should rename the current parameter
differently (in order to avoid confusion), like:

         increasingNumber                 INTEGER,

and have the following changes:
 
Section 2.1. Requirements of the TSA

The TSA is REQUIRED:

(snip)

   3.  to include a strictly incrementing integer for 
       each newly generated time stamp token.

In section 2.4.2. Page 8. The increasingNumber field shall include a
strictly increasing integer from one TimeStampToken to the next
(e.g. 45, 236, 245, 1023, ...). This guarantees two properties: (1)
When used in combination with the TSA's name the increasing number
identifies a unique Time Stamp token. (2) It is always possible to
compare the ordering of two time stamps from the same TSA by looking
only at that field. This may be useful in particular when two time
stamps from the same TSA bear the same time. It should be noticed
that the stricly increasing numbering property must remain valid
even after a possible interruption (e.g. crash) of the service. A
recipient of a Time Stamp token MUST be able to handle increasing
numbers that are up to 16-bytes.

As a conclusion, at the time being, there are thus two choices.

Denis

---

From: Juergen Brauckmann <[email-masked]>
Date: Fri, 26 May 2000 15:52:01 +0200

>require uniqueness and nothing else. We may then keep the name 

Just a short remark: CRL serialnumbers (=the cRLNumber extension) are
required to be monotonically increasing. 
"5.2.3  CRL Number
   The CRL number is a non-critical CRL extension which conveys a
   monotonically increasing sequence number for each CRL issued by a CA.
"

Regards
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 8080 26 311
TC TrustCenter GmbH            Fax.:  040 / 8080 26 126
Sonninstraße 24-28   	    mailto:[email-masked]
20097 Hamburg 		    http://www.trustcenter.de

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 May 2000 16:16:24 +0200

Juergen,

Good remark. However, the parameter is called cRLNumber, not
serialNumber, hence no confusion. :-)

Denis

---

From: "William Lattin" <[email-masked]>
Date: Fri, 26 May 2000 14:15:33 -0700

Denis,

Looks like we're converging on a better solution.

Bill

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, May 26, 2000 06:38
> To: Michael Zolotarev
> Cc: [email-masked]
> Subject: Re: TSA Response serialNumber Field
>
>
> Michael,
>