Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New TSTTime definition

From: "Manger, James" <[email-masked]>
Date: Wed, 4 Aug 1999 16:13:06 +1000

GeneralizedTime is a basic ASN.1 type for representing time and already
supports fractions of seconds.  For example "19851106210627.3Z" is a valid
value.  SO WHY NOT USE IT!

How about the following syntax & text:
-----
TSTInfo ::= SEQUENCE {
	...
	time		GeneralizedTime,
	uncertainty	REAL  OPTIONAL, -- in seconds
	...
}

The 'time' & 'uncertainty' fields specify the Universal Coordinated Time at
which the timestamp was created.  The 'time' value SHALL NOT be earlier than
the 'time' value in any timestamps already created by the TSA.
-----
I don't think anyone could misinterpret the syntax or semantics.  If
desired, a TSA can use the arbitrarily high time resolution to indicate an
unambiguous order for all the timestamps it creates.  If desired, a TSA can
use second resolution if it only wants to support non-repudiation (or
support legacy applications that only partially understand the
GeneralizedTime syntax).

---

From: "tog" <[email-masked]>
Date: Wed, 4 Aug 1999 07:44:36 -0700

Because there is nothing that tells me what the collective value, i.e the
empirical accuracy, or what the source of the time data is, and that is
critical the portability of the trust models, that's why.

I should trust your time just because you say so?

FOLKS - this is not about the accurate delivery of time or representing it,
there a bazillion ways to do that already. What there isn't is in a single
instance something that tells you:

   1)     what the timesource is
   2)     who say's its good-to-go
   3)     what time the timebase of the event says "time it is"
   4)    and the event itself

The proofing models for timestamping either need the trust anchors for the
timestamp inside the token structure or as part of the token processing
infrastructure itself. It really doesn't work any other way.

I deference to Stephen Kent's feelings about my coining new terms like
"Trust Anchor" - A trust anchor is a key component of any trust process or
operation that yields a fixed point of view for the transaction itself. I.E
something that anchors the transaction to another 'something' that makes it
"referable".

Todd

----- Original Message -----
From: Manger, James <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 03, 1999 11:13 PM
Subject: RE: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Aug 1999 11:39:45 -0400

Todd,

	<snip>

>infrastructure itself. It really doesn't work any other way.

	<snip>

CAs publish policies stating what they do to ensure accuracy in binding of
attributes into certificates.  The model PKIX has been following for TSAs
is the same, i.e., a clientr decides to rely on a TSA or not, based on a
disclosed policy. This approach does not require embedding data in support
of verification of TSA operations.  The only extent to which your state
above applies in this model is that the signature applied by the TSA can be
used to verify the source of the time stamp, and that can be used to make a
decision as to whether the time stamp is acceptable (based on the TSA's
policy).

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 06 Aug 1999 08:58:20 +0200

> of verification of TSA operations.  

I fully support this position and your statement, Steve.

Denis

> The only extent to which your state

---

From: "tog" <[email-masked]>
Date: Fri, 6 Aug 1999 08:00:54 -0700

Denis,
----- Original Message -----
From: Denis Pinkas <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: tog <[email-masked]>; Manger, James
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 05, 1999 11:58 PM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re: New
TSTTime definition

> I fully support this position and your statement, Steve.

This is true and seems totally based in that no one driving these standards
in PKIX  have talked to the physicists to see how they have been dealing
with highly accurate timebases in their data collection models for the last
30 years. The fact of the matter is that we as a collective group choked on
this one. Highly accurate and provable timeservices have been around for
years.

As to it's not being spec'd into X.509 - we think that this is an oversight
as well, and a growing number of us are forming to propose a certified
timebase and other trust anchors be defined as a recommended service
interface to support better trust than plain generic X.509 does by itsself.
Especially in AC's.

For timestamping to be what we all know it can be, it desparately needs to
be able to fulfill the emerging audit requirements and secure timesources
and their logging are part of that, in no uncertain terms.

Todd

---

From: "tog" <[email-masked]>
Date: Fri, 6 Aug 1999 08:33:55 -0700

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: tog <[email-masked]>
Cc: Manger, James <[email-masked]>; <[email-masked]>
Sent: Thursday, August 05, 1999 8:39 AM
Subject: Re: Lets Standardize Time Representation Formats!!!: WAS Re:
NewTSTTime definition

> disclosed policy.

Another oversight in the proofing process model IMHO

> This approach does not require embedding data in support

No then there needs to be someway to online verify that the cert polices and
practices fit in with what I as the relying party will accept. If you do not
put thise trust anchor points in the policy control models, then we will
need yet another flaming protocol to evaluate RPA (Relying Party Agreements)
online to see if the CPS and RPA's are compatible with our instance of PKI
requirements.

Thats part of the jumble that in my opinion and makes interoperating with
PKI a nightmare. I have to verify each CA services models becuase we wont
allow for this type of trust information then the open networking overhead
will kill many types of Point-Of-Sale PKI Transactions.

> decision as to whether the time stamp is acceptable (based on the TSA's

Except this adds an extra step that is easily eliminated by adding a simple
and optional amount of info to the TST itself.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Aug 1999 11:33:27 -0400

Todd,

This aspect of the time stamp discussion has taken on a rather repititous
tone.  I see a persistant push to accommodate a specific model for TSAs
that is advocated by about 3 people on the list.  Unless I see substantial
additional support for this model, preferably not by people from the same
(very small) set of companies already represented, I will continue to
believe that the WG concensus is NOT to change the model from the one we
adopted long ago.

Steve