Time-stamp server. TimePrecision info

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxxxxx>]

We are proposing to add an extra optional field to the TSTTime structure:

It is reasonable to except a TSA to maintain a set of more then one source 
of timing data. Typically, a TSA might derive its time from a high-accuracy 
source (such as a GPS clock), but may fall back to a lower accuracy one 
(such as an NTP server), if its primary time source is temporarily 
unavailable (e.g. due to hardware failure).
Currently, the policy information is the only place where accuracy of time 
may be returned by the time-stamp server -
for example, the policy might state: "The time returned will be accurate to 
within 100ms, and if the time-stamp server cannot
provide this level of accuracy, it will not issue a time-stamp."

However, it seems reasonable to anticipate business cases where a more 
flexible approach is necessary - a loss of
quality might be acceptable so long as a time-stamp is issued. The policy 
in this case might state something like:
"The time returned will be accurate to within 100ms over 99% of the time. 
 The actual time quality is given in the field
timePrecision in the TSTTime."
The timePrecision would depend on the characteristics of the time data 
sources used by the TSA.

In this case, an additional parameter would be required in the TSTTime 
structure:

TSTTime ::= SEQUENCE {
	genTime	GenerilizedTime,
	milliseconds	[0] IMPLICIT INTEGER OPTIONAL
	timePrecision	[1] IMPLICIT INTEGER OPTIONAL
		-- Precision in milliseconds.
}

the precision field, if present, should be interpreted as 'the exact time 
lies within the [ TSTTime-timePrecision/2
-- TSTTime+timePrecision/2 ] interval'.

If the TSA policy contains the 'quality of the time'  statement, most 
likely it will be a pessimistic one.
Consequently, the timePrecision field will be useful not only in a 
situation when the quality of the time in the time stamp
is below the limit, but also when it is well above the bottom mark.