Subject: RE: TSA Response serialNumber Field

From: Peter Sylvester <[email-masked]>
Date: Wed, 24 May 2000 18:48:28 +0200 (MET DST)

Strictly increasing does not mean that you cannot have holes. 

> The approach I suggested does allow for unique determination of a time
> stamp, but to do so the validator must also have the certificate for the TSA
> signature key.  I don't think this is unreasonable since proper verification
> should include this information.
In 30 years the certificate used may have no value anymore. A validation
of the signature of the time stamp is only one method to validate it. 

The TSA has or should have to create logs of all time stamps, and it
or someone else may provide a service to validate a time stamp by
looking at the archive, in order to have at least two independant ways
of validation. 

Well, that's not the point. You may need then to define a mechanism that
compares two time stamps of *the same* authority with different
keys. It may also happen that two key/certs are used in a roll-over
situation with several servers in parallel. 

> 
> The issue I am attempting to address is the requirement for a monotonically
> increasing serial number for all time.  The draft does not address how to
> recover from a situation where the serial number is lost due to equipment
> failure.  Such a failure is likely to occur at least once over all time :-).
> The approach I suggest above does allow graceful recovery, since one could
> generate a new TSA signature key and certificate and start again with a
> reset counter.
> 
> I strongly suggest that we consider the ramifications of trying to assure
> seamless operation for all time.  I don't think it is practical and we
> should not design a standard requiring such.  I am open to other solutions
> if the above suggestion is perceived as too burdensome.

You can still do this if you include a time value in the number.

---

From: "William Lattin" <[email-masked]>
Date: Wed, 24 May 2000 20:57:03 -0700

> Strictly increasing does not mean that you cannot have holes.

Agreed, but as written, one will have to pay carefull attention to ensure,
in the event of a failure, a sufficiently large jump ahead is made to ensure
a strictly increasing serial number.  My suspicion is this will require a
significant amount of work by humans.
> situation with several servers in parallel.

There may be a variety of mechanisms to validate a time stamp. Your scenario
in which the certificate has no value and one must trust a list created by a
TSA is not a trust model to which I would subscribe.  This is an
implementation detail, however, so we don't need to resolve this here.  Key
transitions in server farms are also implementation details.  Neither
outright precludes the ability to use my suggested approach.

> You can still do this if you include a time value in the number.
  True enough.

At the end of the day, both techniques will work.  IMHO, the approach I've
suggested would seem to provide a cleaner and more complete audit trail of
TSA time stamps.  The validation step does not require verification that the
strictly increasing hole was indeed that.

I rest here.  If others don't really view this as an issue then let the
current text stand.

Cheers,

Bill