Subject: Re: TSA Response serialNumber Field

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2000 17:32:38 +0200 (MET DST)

Steve,

Hm, the actual text says:

    'strictly monotonical increasing'. 

At least the example in the text about non-consecutive
number is there. 

What you are asking for is to create consecutive time stamps.

What you indicate is not mentioned in the text at all in the
text, maybe it was intended at some time (the usage of 
'monotonically incrementing' may be an indication).
Maybe the original author's can comment on that.

Your point is an interesting one. This is ONE method, if a TSA
is able and willing to increment by one, they can do that. 

But that doesn't help,  a TSA can replace any stamp
and then claim in 30 years that the key was corrupted.

If you imagine the possibility not to trust the TSA,*
then you might require that the TSA stores all stamps with
a notary, or whatever else third/forth/fifth tp to store
a complete archive of all tokens. 

> 
> >Peter,
> >
> >You are right. The name "serialNumber" in this context is
> >misleading. I forgot to look backwards to find out the additional
> >statements you mention. :-(
> >
> >The serialNumber field serves several purposes, one of them being to
> >be used in conjunction with the DN to uniquely identify a TS token.
> >
> >We have added another constraint, i.e. monotonically increasing,
> >that does not appear in other standards. This was done to save an
> >additional parameter. The main idea was to be able to compare two
> >time stamps issued during the same second.
> 
> I think that is critical and there is another possible reason for 
> wanting the counter to be monotonically increasing.  It helps detect 
> if a TSA tries to insert a late arriving hash into the time stamp 
> stream.  If there are no sequence number gaps, there are no "hole" 
> into which a later arriving hash can be inserted.  I assumed this was 
> another motivation.
> 
> Steve
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 May 2000 12:11:48 -0400

Peter,

>At least the example in the text about non-consecutive

The text I was referring to in the TSP draft states:

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

"Monotonically increasing" means that the counter increments by 
exactly one each time.  If it is not an increment by one, a phrase 
such as "strictly increasing"
would be appropriate.

>What you are asking for is to create consecutive time stamps.

Well, the time value will not be consecutive, which is why I though 
Denis specified that the counter would be.  There can be legitimate 
gaps in the time values.

>is able and willing to increment by one, they can do that.

Yes, it's just one method. I assumed that it might have been 
specified because its cheap to do and not patented, etc.

>a complete archive of all tokens.

Elsewhere the document talks about recovery from a possible key 
compromise and says:

. When the TSA private key has been compromised, then the
         corresponding certificate SHALL be revoked. In this case,
         any token signed by the TSA using that private key cannot
         be trusted anymore.  For this reason, it is imperative that
         the TSA's private key be guarded with proper security and
         controls in order to minimize the possibility of compromise.
         In case the private key does become compromised, an audit
         trail of all tokens generated by the TSA MAY provide a means
         to discriminate between genuine and false backdated tokens.

By sequentially numbering the TSTs, there may be some further 
protection against back dating an audit log, but maybe this is such a 
small added feature that it's not worth pursuing.

Steve

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 12:20:38 -0400 (EDT)

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Peter,
 >> Steve, Hm, the actual text says: 'strictly monotonical
 >> increasing'.  At least the example in the text about
 >> non-consecutive number is there.

 Stephen> The text I was referring to in the TSP draft states:

 Stephen> 3.  to include a monotonically incrementing integer for each
 Stephen> newly generated time stamp token.

 Stephen> "Monotonically increasing" means that the counter increments
 Stephen> by exactly one each time.  If it is not an increment by one,
 Stephen> a phrase such as "strictly increasing" would be appropriate.

Well, it says "monotonically incrementing" not "increasing".

I'm not at all sure this terminology implies consecutive values must
be used.  Then again, I view "monotonically" as a rhetorical flourish,
"increasing" is sufficient.  (Note that "increasing" is not a synonym
for "non-decreasing".)

What possible value would be served by a requirement that the numbers
must be consecutive?  I can see no possible use that anyone could make
of this, given that we live in a datagram world.  That being the case,
there shouldn't be such a requirement.

Better yet, perhaps we need to revisit what requirement prompted the
inclusion of this message component.

If it is to distinguish one timestamp from another, the requirement
stated should be uniqueness, no more.

If it is to distinguish one timestamp from another for the case where
the time values are identical, the requirement should be just that.

If the requirement is to let you order the timestamps that have the
same time value, then the requirement should be that the value is
increasing over that scope.

If the requirement is a total order (regardless of time value) then
the requirement should be "increasing".

Etc...

	paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 May 2000 17:42:08 -0400

Paul,

>inclusion of this message component.\

Agreed.

>stated should be uniqueness, no more.

no, its more than that, I think.

>the time values are identical, the requirement should be just that.

still more.

>increasing over that scope.

I think this is the requirement Denis had in mind, and that others 
did, based on the traffic from some time ago.

>the requirement should be "increasing".

This satisfies the previous requirement, but is more stringent.  it 
is what is required now, but maybe it's overkill, modulo the 
potential benefits I ascribed to a 1-up counter used here.

Steve