Subject: Re: The need for two grades of time data.

From: Peter Sylvester <[email-masked]>
Date: Fri, 15 Sep 2000 12:10:56 +0200 (MET DST)

> I want everyone to understand that I am not trying to be a jerk here, I
> probably should have used more benign language - I just think that with the
> sheer number of NTP Servers out there already, that NTP as a common
> timestamping system may actually make a lot of sense and PKIX might not be
> able to stop its use to focus favor on the TSP. That's all.
> 
> T.

Are we getting back to an example of the encoding wars? 
 
I don't think that PKIX regards NTP as a time 'stamping' system.
the NTP network can be a provider of time, and a client may also use
it in order to determine the validity of a time stamp. 

NTP times are used to synchronize clocks, not necessarily to show them
in a court. Once you've set the clock, you're done, or are you
keeping it for saying, I have receive that stamp to set my clock.
Well, when did you set your clock, and to what value. Where's the proof
or evidence? Who cares and when? 

I might be wrong, but when I make an abstract form of what is provided
in BERT, the only difference concerning the time value (besides that
it is in NTP form) is that there is an indication of what source
it came from. If someone believes that this is important, please
make a specification of how to encode such data. I don't think that
the TSA often changes a provider, thus it might be sufficient to
add this to a policy for the moment. 

Transforming an NTP value into a GENERALIZEDTIME doesn't seem to me a
totally impossible task, or if ncessary, one might consider to
just add an OCTETSTRING with an encoded NTP time in there. 

The rest in BERT could be regarded as nih symdrome provoked Sinatra
solution to encode names, certificates, signature values etc. of
information that can be probably already be assembled in other proposed
or existing secured token formats. Sorry for the flame, I'd be glad
to be corrected if my assumption isn't true. 

Peter Sylvester

---

From: "todd glassey" <[email-masked]>
Date: Fri, 15 Sep 2000 10:55:12 -0700

----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 15, 2000 3:10 AM
Subject: Re: The need for two grades of time data.

> Are we getting back to an example of the encoding wars?

Possibly but as more and more of the types of functionality that we need in
Commercial Audit process becoems autonomic this will happen.

> I don't think that PKIX regards NTP as a time 'stamping' system.

I do understand that, but the fact remains that NTP is easily used as a TS
transport and with AutoKey will do most of what the TSP protocol was
architected to do and that there are already tens of millions of NTP systems
out there.

I  am just brining up the point that it might not matter collectively here
what we think. It may be moot that applications providers and users just
code up TS processes that work for thier exising apps by simply using the
already in place NTP system.

> it in order to determine the validity of a time stamp.

NTP surveying is alo a good one to add. That and the concept of Clock
Steering.

> in a court.

No and this is the subtle discinction here. The NTP protocol is used to
transport time data and hashes for timestamping. becuase of the NTP packet
and the process of how NTP Clients talke to their NTP Servers they also
include their own timesense in the timing request. The addition of the
payload was there to allow endpoint authentication but if that also includes
a hash of the blob to be stamped so be it, there it is. The NTP response
packet will be the TST stream itself.

> Once you've set the clock, you're done, or are you

Your talking about two processes, one that uses the time data as content,
that being the Time Stamp, and the other that uses that content as control
and policy information, thats the NTP TOD Timesetting Process - remember
that the mechanical management of the clock is based in the "what the client
application does" and not in the NTP protocol itself.

> or evidence? Who cares and when?

yes, that's the idea.

> it came from.

the BERT 1 Token was originally only designed for indicating a Time and
Location for a minimal payload. The second generation of BERT uses a more
modular approach to allow any number of event types and contains a fixed
location Token Header for processing that defines the rules or engagement
and the trust level of the token.

>If someone believes that this is important, please

The issue becomes 'what do I do to manage the TST after the TSA is gone?'

> to be corrected if my assumption isn't true.

Its not, but the Sinatra commentary is amusing, and  Peter - I have been
bashed so many times already for this here and on other lists - its no
problem partner.

As to NIH being at play, what the intent behind the BERT is is that there
needs to be a set of stamping data structures that are all 'standardized"
that is agreed upon by the vendors such that their systems can all
inter-relate with  eachother over these evidentiary interplay tranports.

Thats a 50,000 foot concept but the idea behind the BERT was that
evidentiary services have to work with existing systems and these are all
predominently based in DB environments. That means that the TST needs to be
manageable from within the DB context and that is not happeneing here yet
that I can tell .

Todd

---

From: Tim Polk <[email-masked]>
Date: Fri, 15 Sep 2000 15:24:58 -0400

Yikes!  I'm out of the office three days (sorry Steve!), and I'm billyuns 
and billyuns of messages behind.  I printed this thread to save my eyes - 
and wiped out a small forest in the process.

After reading this thread and rereading the TSP document, I have a few 
opinions of my own:

(1) The TSP document defines a protocol.  A client system can use this 
protocol to obtain a time stamp token from a time stamp server.  The token 
can be used to demonstrate that a datum existed at a particular point in time.

(2) Different time stamp servers may deliver different "grades" of time 
data.  The grade of time data is a function of the hardware, software, and 
procedures [including time source] used to implement the time stamp 
server.  The grade of time data is *not* a function of the protocol.

(3) The time data includes a policy field, which includes an object 
identifier and an optional qualifier.  When a CA wishes to indicate the 
"grade" of an X.509 certificate, it uses *precisely* this 
mechanism.  Relying parties use this information to determine if an X.509 
certificate is acceptable for their application.  In my opinion, this 
mechanism is also sufficient to indicate the grade of time data.

(4) The time stamp token can optionally include extensions.  These 
extensions field is a generic mechanism to convey additional 
information.  For those that find the policy field insufficient, this field 
could be used to convey additional and specific information regarding the 
time source and other operational aspects of the time stamp server.  The 
BERT token might be such a candidate.

(5) I understand that Todd and some others would like to "formally define 
what an evidentiary grade source is and what it must conform to."  A 
commendable goal, but I am not sure that PKIX is the place to draft this 
definition.  It is certainly outside my narrow field of competency!  I also 
fear that this definition will be different for each "local" legal 
system.  However, the TSP should certainly be able to convey this 
information when a standard definition emerges.  In light of (4), I do 
*not* believe that this requires any changes to the TSP specification.

In summary, I believe that the TSP specification provides just the right 
level of specificity.  It requires time stamp servers to implicitly 
indicate the grade of time data through an OID.  Relying parties can use 
this information to decide if the time data is acceptable for their 
application.  The TSP specification *permits* time stamp servers to 
explicitly indicate the grade of time data through an extension field.  As 
legal frameworks emerge, this will support an explicit inclusion of locally 
relevant time data grading information.

My two cents.

Thanks,

Tim Polk