Subject: TSP: New TSTTime definition

From: Denis Pinkas <[email-masked]>
Date: Tue, 03 Aug 1999 09:30:37 +0200

At the last WG meeting in Oslo, we discussed the format
of the TSTTime.

In order to accommodate the need for PKIX applications to use
a time resolution up to the second and other applications wishing
to get a signed time below the second, here is a new proposal.

There are many ways to address this issue. The format of
GeneralizedTime below the second has not been the chosen solution
in order to use the same time format as used in CRLs and certificates.
Optional fields allow to go below the second when this is really needed.

The proposal also attempts to prevent a competition between TSAs
taking only argument of their better time accuracy. In others words,
an accuracy around the second is fairly sufficient for PKIX applications

Before incorporating the new text in the next version, I would like
to get the WG opinion whether this proposal is acceptable.

The current definition of TSTTime is as follows:

TSTTime ::= SEQUENCE  {
    genTime                       GeneralizedTime,
    fractionOfSecond              BIT STRING,
    precisionFactor               INTEGER
}

Here is a proposal for a new structure and the text that applies to it:

TSTTime ::= SEQUENCE  {
    genTime                       GeneralizedTime,
    serialNumber                  INTEGER,
    precisionFactor               INTEGER       OPTIONAL,
    fractionOfSecond              BIT STRING    OPTIONAL
}

GeneralizedTime shall be used as described in [RFC2459] Section
4.1.2.5.2.  GeneralizedTime only represents time with one second
granularity.

The integer used for the serial number shall be a strictly
monotonically increasing integer that will guarantee that each token
is unique. It carries to functions:

1) when associated with the name of the TSA and the genTime it may
be used to unambiguously reference a Time Stamp token for auditing
purposes. In order to allow anyone to easily reference any token
from any TSA, this field is mandatory.

2) it allows to discriminate between the ordering of multiple time
stamps issued within the same second. When comparing two time stamps
issued by the same TSA within the same second, the one which contains
the smaller integer shall be assumed to have been generated first.

The precision of the time indicated in genTime may be obtained through
the security policy. Alternatively, the precisionFactor may be used if:

1) the precision of the time is variable with the time,
2) a precision better than the second is desirable. In such a case,
the precisionFactor shall be used in conjunction with the
fractionOfSecond field.

It should be noticed that in many cases the precision of
the clock is lost by the time of transit inherent to the transport
protocol.

Conforming TSAs do not need to support the precisionFactor and the
fractionOfSecond fields.

When the service is offered locally on the same machine,
a precision below the second can make sense. In that case,
the fractionOfSecond field is used in conjunction with
the precisionFactor field to indicate the sub-seconds.

The precisionFactor field is an optional field. It is a signed
integer giving an upper bound on the difference between the timestamp
and UTC when the timestamp was issued. The actual precision of the
clock is calculated as power (2, precisionFactor).

Note that this method defines a precision of a clock as 'being around
the value', not as an exact figure.  The actual method and frequency
of synchronising the clock with UTC time, as well as the
characteristics of the clock itself, define the deviation from UTC.

A negative precisionFactor value indicates a precision as a fraction
of a second. This may be useful when the service is local on the same
machine. In that case the fractionOfSecond field is used in
conjunction with it to indicate the sub-seconds.

For instance, precisionFactor=-5 would yield 2^(-5) = 0.03125 sec
(31 ms). This precisionFactor would account for the 50-Hz (20 ms) or
60-Hz (16.67 ms) power-frequency clock that is closely synchronized
with UTC, for example.

A positive precisionFactor value indicates a precision above the second.

The fractionOfSecond field is an optional field which shall be used
only when the precisionFactor field is present. It is an unsigned
integer indicating the fraction of second; i.e. with the most
significant bit indicating 500 ms, the second 250 ms, and so on.

-----

Denis

---

From: Raffaello Galli <[email-masked]>
Date: Tue, 03 Aug 1999 10:45:27 +0200

>>> the smaller integer shall be assumed to have been generated first.

Hi Denis,
first I would like to answer to your second point.
2)
According to me the proposal for the new structure of TSTTime is fine but
I suggest to add an "OPTIONAL" flag to the "serialNumber" field as follow.

TSTTime ::= SEQUENCE  {
    genTime                         GeneralizedTime,
    serialNumber                  INTEGER   OPTIONAL,
       --MUST be present if  fractionOfSecond  is not present
    precisionFactor               INTEGER   OPTIONAL,
    fractionOfSecond            BIT STRING    OPTIONAL
}

A TSA filling in this new structure can decide to use the fractionOfSecond
field
and/or the serialNumber field if  doesn't  support the precisionFactor and
the
fractionOfSecond fields.

Now let's go back to the first.
1)
I will remind you that the serilaNumber field is cointained into the TSTInfo
structure anyway.
So I think there are only two solutions:
   A) the serialNumber field inside the TSTInfo structure should be changed
from
        OPTIONAL to MANDATORY without adding any serialNumber field inside
        the TSTTime structure and using it for discriminating between the
ordering of multiple
        time stamps issued within the same second.
    B) the serialNumber field inside the TSTInfo structure should be
deleted.

So after all this word I think that the best solution is to change OPTIONAL
to MANDATORY
the serialNuber field in the TSTInfo structure and delete the serialNumber
field from the
TSTTime structure.
In this way TSA that doesn't support the precisionFactor and the
fractionOfSecond fields will
use the serialNumber field in the TSTInfo structure to order  multiple time
stamps issued within
the same second, and the same field can be used  for auditing purposes.

Ciao
Raffaello

---

From: "Nick Pope" <[email-masked]>
Date: Tue, 3 Aug 1999 10:47:10 +0100

Denis,

I considered the BIT STRING encoding of fractionOfSecond to be difficult to
process.  The precision will depend on the number of bits and it cannot be
handled as a simple integer as the text suggests.  After a 3 bits the
precision will be in fractions of milleseconds (62.5 ms, 31.25 ms etc).  I
would suggest that a simple integer value giving 1/100 ths of second would
be sufficient.  Any greater precision seems pointless.

Nick

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: 03 August 1999 08:31
> To: IETF-PXIX
> Subject: TSP: New TSTTime definition
>
>

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 03 Aug 1999 12:04:24 +0200

Raffaello,

Thanks for your very fast answer.

The serialNumber is made mandatory so that TSAs are not required to
support below of second information, in particular when that
information is not meaningful because of a lack of accuracy.

It also serves, as indicated, as a pointer that can be used by any
one to retrieve or point to an old time stamp.

The serial number in TSTInfo is not mandatory. It is an ABSOLUTE
number (starting from the beginning of the life of the TSA and
ending only when the TSA ceases activity or changes its name). There
has been a thread on that topic. One of the reasons is that
maintaining this number after a crash of the TSAn might be a
problem. Another reason is the possibility to spy the number of Time
Stamps being done by a given TSA and hence measuring its activity.

Regards,
 
Denis

>   --------------------------------------------------------------------
> 
>   Responsabile Tecnologie
>   C & A Improve Your Security
> 
>   Responsabile Tecnologie                                                                                                                                     <[email-masked]>
>   C & A Improve Your Security
>   Viale Fulvio testi 126                                                                                                                                      Télécopie: ++.39.2.24791826
>   Cinisello Balsamo (MI)                                                                                                                                      Domicile: Please call me at work.
>   ITALY                                                                                                                                                       Bureau: ++.39.2.24791823
>   20092                                                                                                                                                       Adresse Netscape Conference
>   ITALY
>   ------------------------- Improving Your Security ------------------------- Certification Authority - X509 V3 - RSA Strong Web Server SSL3 Strong - Proxy SSL Crypto Smart Card - PKCS#11 Key Manager - Time Manager Time Stamping Authority - Corba (IIOP over SSL) ------------------------- Improving Your Security -------------------------
>   Informations supplémentaires:
>   le nom       Galli
>   Prénom       Raffaello
>   Version      2.1

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 03 Aug 1999 12:06:49 +0200

Denis,

I agree to the previous comments regarding serialNumber in TSTTime.
This serialNumber is no time information and should not be present here.

I believe it would be much more clean to use the serialNumber in the
TSTInfo to determine sequences and provide uniqueness in timestamps.

I also believe that serialNumber should be optional. Far from all
applications are concerned with sequence determination or need serialNumber
to resist replay attacks.

/Stefan 

>significant bit indicating 500 ms, the second 250 ms, and so on.

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 03 Aug 1999 12:13:55 +0200

Nick,

The format for fractionOfSecond is not "new" and was already present
in the current draft. The current definition is directly extracted
from NTP where the format of subseconds is defined this way (in 32
bits words instead of ASN1). I would like to hear about more people
carring about the sub-second information before making a decision.

I have personally no problem with your suggestion.

Regards,

Denis

---

From: Raffaello Galli <[email-masked]>
Date: Tue, 03 Aug 1999 13:10:51 +0200

> information is not meaningful because of a lack of accuracy.

I understand your point, but I still believe that the serialNumber field
can be OPTIONAL with the following constraint:
      --MUST be present if  fractionOfSecond  is not present
as indicated below.

TSTTime ::= SEQUENCE  {
  genTime                         GeneralizedTime,

have a good lunch
Raffaello

---

From: "tog" <[email-masked]>
Date: Tue, 3 Aug 1999 08:41:16 -0700

Denis to using your words - Creating yet another representation of time in a
PKIX tool also 'seems pointless'.

Lets think of standardizing the representation of time to a format that will
interoperate across the greatest number of PKIX applications. I suggest that
the UTC 96 representation format from the BERT draft be adopted as the use
standard. (McNeil - You want to jump in here?)

And Denis -  partner - as to what "you" personally think is the greatest
resolution of time necessary, I look to that great Tommy Lee Jones line from
MiB (Men In Black)  that went something like: "1500 years ago mankind
thought that the Earth was the center of the Universe. 500 years ago mankind
new the earth was flat. 15 minutes you knew you man was alone here on
earth....think what you'll know tomorrow".

My point is that we don't know all the uses yet - and if we limit ourselves
to representing time at the same level of granularity that the OS designers
thought was relevant - Ahahahahahahah - Well it just seemed a bit funny
since we already know that it is not clean enough. If you don't believe me
call the stock exchanges and find out what and how they use
timedata/timesources for.

I have, and was surprised to find out that most of them have local Atomic
Clocks that they reset daily or more often to NIST prime. These systems are
good to 1*10e-12 Sec/Year which is clearly cleaner and finer that what we
are proposing.  They have the most furious use of timestamping yet today and
to them milliseconds are critically important. Especially in Digital Agent
Models, where a number of agents are competing for common services in a
control or market pool. The bottom line is that very fine granularity is
absolutely necessary, if for no other reason than that the OS vendors
choked.

So what are the real issues here ? - It seems that we are going to choose a
limiting criteria based on the fact that there is
    o-    currently substantial propagation delay in a Open Networking
Models (dependant on the topology of course) and this sets the baseline for
the precision in remote-timestamping model's "credibility envelope".
    o-    and that the OS is only capable of 1 Sec resolution in most cases
    o-    and in almost all cases, the TOD services that create this
granularity are based in some cheap Clock Chip that the BIOS or otherwise
sub-OS services provide
    o-    and most importantly, that there is really no real way to resynch
the clocks properly in the field. [which simply isn't true BTW]

What this entire thread seems to overlook or negate is that:
    o-    even in SW only systems,  that sub-millisecond precision time is
easily distributed in networking models. IRIG-B timecode and NTP have been
doing this *for decades* already.
    o-    Also that timestamping is often going to be done differently that
the TS draft suggests, that is to say commercially I believe that the TS
services will commercially live on the same platform that uses them, per
say, rather than some Trusted-Third Party external third system. They may
have a secondary proofing-stamp process happen at the "Archive Server" for
the TST's, but that in reality that the system has to work not only embedded
as we have proposed, but externally as you have proposed as well.

To my mind, what this means is that the issue of network delay is not always
applicable in the timestamping models, and this should be addressed by a
uniform model that supports *all* use cases. Also that anyone can add a Time
Board to a system if they need better grades of local time that can survive
a reboot. Even the people that commercially depend on GPS for time (poor
fools), get better time than the OS's can track in most all instances.

My point is that there needs to both be interoperability in timestamping, as
in all PKI, and in particular in the representation of the other cornerstone
trust element, like the "Time" that an event is supposed to happened...and
that the granularity is really needed in the submillisecond range.

Also what is the real overhead for adding these features to the process?
What is it really.?

Todd

---

From: Michael McNeil <[email-masked]>
Date: Wed, 04 Aug 1999 10:27:03 -0700

Stefan Santesson wrote:
>I believe it would be much more clean to use the serialNumber
>in the TSTInfo to determine sequences and provide uniqueness in
>timestamps.
>
>applications are concerned with sequence determination or need
>serialNumber to resist replay attacks.

There should be some random client bits included in the signed
timestamp which identifies the timestamp as in response to a
particular client request.  This is much better than using
a serial number as a method of resisting replay attacks.

(I'm not saying don't have include serial number, mind you.)

Michael McNeil

---

From: Michael McNeil <[email-masked]>
Date: Wed, 04 Aug 1999 10:52:32 -0700

Denis, thanks for your work here.  My comments are below.

Denis Pinkas wrote:
>GeneralizedTime below the second has not been the chosen
>solution in order to use the same time format as used in CRLs
>and certificates. Optional fields allow to go below the second
>when this is really needed.
>
>taking only argument of their better time accuracy. In others
>words, an accuracy around the second is fairly sufficient for
>PKIX applications
>
>Before incorporating the new text in the next version, I would
>like to get the WG opinion whether this proposal is acceptable.
>
>monotonically increasing integer that will guarantee that
>each token is unique. It carries to functions:
>
>1) when associated with the name of the TSA and the genTime it
>may be used to unambiguously reference a Time Stamp token for
>auditing purposes. In order to allow anyone to easily reference
>any token from any TSA, this field is mandatory.
>
>2) it allows to discriminate between the ordering of multiple
>time stamps issued within the same second. When comparing two
>time stamps issued by the same TSA within the same second, the
>one which contains the smaller integer shall be assumed to have
>been generated first.
>
>The precision of the time indicated in genTime may be obtained
>through the security policy. Alternatively, the precisionFactor
>may be used if:
>
>2) a precision better than the second is desirable. In such a
>case, the precisionFactor shall be used in conjunction with the
>fractionOfSecond field.
>
>the clock is lost by the time of transit inherent to the
>transport protocol.

Very true.  The time shown should be the time at the TSA.

>Conforming TSAs do not need to support the precisionFactor and
>the fractionOfSecond fields.
>
>integer giving an upper bound on the difference between the
>timestamp and UTC when the timestamp was issued. The actual
>precision of the clock is calculated as power (2, precisionFactor).
>
>Note that this method defines a precision of a clock as 'being
>around the value', not as an exact figure.  The actual method and
>frequency of synchronising the clock with UTC time, as well as the

And this is then reflected in the precision shown....

>A negative precisionFactor value indicates a precision as a
>fraction of a second. This may be useful when the service is local
>on the same machine. In that case the fractionOfSecond field is
>used in conjunction with it to indicate the sub-seconds.

If one is going to do this, why limit resolution to milliseconds?
(I'm afraid the concept of "dumbing down" the time format so TSAs
can't advertise imaginary resolutions doesn't appeal to me.  In my
view, simply require that only realistic resolutions be claimed.)

>(31 ms). This precisionFactor would account for the 50-Hz (20 ms)
>or 60-Hz (16.67 ms) power-frequency clock that is closely
>synchronized with UTC, for example.
>
>The fractionOfSecond field is an optional field which shall be
>used only when the precisionFactor field is present. It is an
>unsigned integer indicating the fraction of second; i.e. with
>the most significant bit indicating 500 ms, the second 250 ms,
>and so on.

Now this is peculiar.  You say elsewhere, Denis, that this was
copied from the way that NTP does things.  It's true that NTP's
fractional seconds are represented as each bit being one half
of the predecessor's value.  However, NTP accomplishes this using
a base [i.e., 2^^(-32)] which is a power of two; thus each digit
stands for a whole number.  In the system described above, the
"and so on" a few bits later encounters 62.5 ms, 31.25 ms, and
so on.  Do we really want to encode a system which allows (only)
milliseconds as the fractional-seconds representation -- but
whose representation takes on _fractional_ millisecond values?

Regards,
Michael McNeil