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

From: "todd glassey" <[email-masked]>
Date: Wed, 13 Sep 2000 09:52:13 -0700

Absolutely - This is right on the money!

Thanks Bob

----- Original Message -----
From: "Bob Jueneman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 13, 2000 9:02 AM
Subject: Re: The need for two grades of time data.

I believe that what Todd is trying to say is that the question isn't,
"What time is it?" but rather "What time is it, and who says so, and
why should anyone believe them?"

If I have correctly understood his position, I think he has an
excellent point.

I think I have told this story before, but when I was a kid in
Cheyenne, there was a jewelry store that had a very fancy
nautical chronometer displayed in their window, and many
people in town used it to set their watches.

One day, the jeweler observed an executive of the Union Pacific
Railroad setting his watch, and they got to talking about time.  The
executive said rather proudly that he set his watch according to the
jeweler's chronometer every day, and then adjusted their railroad
clock accordingly, including the clock that blew the noon whistle.
The jeweler blanched, and said, "But I set my chronometer according
to your whistle!"

Isn't necessary to get  involved in all of the intricacies of various
legal system, and what constitutes acceptable evidence, to realize that
like all weights and measures, the standards must eventually be
shown to be traceable back to an agreed-upon source.

If absolute time is important, then the traceability of that time back to
an agreed-upon reference is important.  One way to beat a speeding
ticket is to challenge the calibration of the radar gun and/or the
speedometer of the cop car, and the same principle will apply here.

(Whether absolute time ought to be all that important is a different matter,
but if it is, the same chain of custody issues should apply as apply to
a certificate chain.)

Bob

>>> Stephen Kent <[email-masked]> 09/13/00 09:09AM >>>
Todd,

>Thanks for responding Steve, but again the real issue with this
>concept of evidentiary time is in treating the parametric time data
>as content rather than control process elements. Once you do that it
>gets to be obvious that you need a auth/certification stream and
>chain-of-custody model for that time data to meet these evidentiary
>needs.
>
>So I have to ask - "What is the problem with treating time and
>perhaps other parametric data like location data, as through it had
>the same risks with it that the Human or Entity Identity issues that
>spawned PKIX in the first place? because it does?"
>
>We seem to as a group have restricted our relating to time and other
>parametric evidentiary processes as though they were only part of
>the plumbing and it just aint so.
>
>Any of the data points that are use inside the decision support
>process protocols that we are building (OCSP, TSP, etc etc etc) are
>all tied to the requirement of some evidentiary anchor - Someone or
>something has to sign that top level cert, some key generator has to
>pump out that key pairing, and that data has been sanctified by PKIX
>to date as it rightly should, but the use of traditional Control
>Data points a parts of the larger evidentiary or decision support
>process warrants that that data have the same integrity as any other.

I sometimes have trouble parsing your text; this is one of those
times. There must be a clearer way to communicate what you're trying
to state. Please try again.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Wed, 13 Sep 2000 11:37:37 -0700

----- Original Message -----
From: "todd glassey" <[email-masked]>
To: "Rich Salz" <[email-masked]>
Sent: Wednesday, September 13, 2000 11:37 AM
Subject: Re: The need for two grades of time data.

> SNIP
>
> > As for Bob's point about "who says it's that time" -- isn't this the
> > same as "who signed the cert binding the name to the key"?  Again, not
> > in our purview.
>
> Sure it is Rich - We are not answering the question itself, just creating
> the mechanism through which it may be answered. thats the difference here.
>
> No one said that you have to use the extra overhead of certifiable and
> audited timebase services, but if ou need that level of trust you should
be
> able to get it in the general use model we are proposing here.
>
> If not what I bethappens is that some other standard that addresses
exactly
> this eventially absorbs the lower-security TSP model and thus the TSP
Draft
> is made part of a larger Evidentiary grade transaction framework as an
> optional LOW TRUST variant.
>
> The issue of the uniform Binary Token is still looming to deal with
though.
> Todd
> > /r$

---

From: Peter Williams <[email-masked]>
Date: Thu, 14 Sep 2000 12:22:42 -0700

To sidestep the CA-oriented control model for grades of time
distribution, and stay within IETF compliance guidelines, what a 
TSA can do is use a Validation Authority (VA) to provide an 
OCSP response to the relying party.  This OCSP response attests to a 
status of Steve's TSA certificate, as normal. The VA's policy can be 
tuned to the needs of the relying parties, however. And, these
parties require more than the assurance of the TSA's network 
identity when relying upon time for security, according to Todd.

Any VA can be tuned to the needs of the relying parties 
trust model. That is, it can base its OCSP response off of 
(a) the CA repository of certificate management information
(b) one or more CRLs issued by a CRL issuer
(c) "other information" pertinent to the reliance model

The great thing about separating CAs from VAs 
is that we get application-specific, and party--specific
signed-transaction reliance models, for free. Lets apply 
now what IETF has given us:

As per IETF standardized options, using private OCSP extensions,
the augmented information in the OCSP response (issued by a VA
acting in support of a high-grade TSP policy) can be:
"Todd's evidence trail"! As Steve said, this information
is private to the TSA's policy, and is not necessarily the 
subject of IETF standardization. Local security
policy is, by definition, outside IETF
scope.

These evidentiary objects can, if you believe Todd's marketing, 
authenticate & qualify the *source* of the timing information 
values. The TSA agent originates in its signed
response msg a message bearing these values: the OCSP
response bears the "evidence" that enables a relying
party to obtain a supporting proof trail for the TSA response.
This (apparently) shows to third-parties that the TSA had 
access to a reliable time source, when preparing its 
signed response.

Once we do this, we can have n levels of time quality,
and n systems (some patented probably) for proving 
access to a reliable time source.

The user is insulated from patents, but can leverage
the proprietary timing-evidences, when there is value,
by choosing which VA to use.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 11:26 AM
To: Bob Jueneman
Cc: [email-masked]
Subject: Re: The need for two grades of time data.

Bob,

>why should anyone believe them?"

Since Todd agrees with Bob's concise translation, I think this is really
easy:

	- by choosing to use the service of a given TSA, the client 
is relying on the TSA to state the time

	- the TSA has a cert to identity it, and that cert is issued 
by a CA, who vouches for the accuracy of the ID, consistent with our 
usual CA model

	- a TSA publishes the technical basis for its time keeping, 
which provides the basis for the last value judgement

So, if the goal is to answer Bob's questions, I think we're done.  If 
one believes that we should move on to establishing criteria for 
different grades of time stamps, you're probably subscribed to the 
wrong WG list, and the wrong standards body, i.e., the IETF is not in 
the business of generating assurance standards of this sort.

Steve

---

From: Frank Balluffi <[email-masked]>
Date: Thu, 14 Sep 2000 13:01:38 -0700

Steve Kent said:

> Let me give a simple, direct, analogy analogy. We don't say (in 2459) 
> that a CA should or must use a FIPS 140-1 certified crypto module to 
> protect its private signature keys. This is outside the scope of our 
> standard, and it is a very significant aspect of the confidence that 
> a client would place in a CA.

Two more examples:

1. Section 6.1 of RFC 2459 does not define how a public key may be trusted:

"The text assumes that the trusted public key (and related information) is
contained in a "self-signed" certificate.  This simplifies the description
of the path processing procedure.  Note that the signature on the
self-signed certificate does not provide any security services.  The trusted
public key (and related information) may be obtained in other formats; the
information is trusted because of other procedures used to obtain and
protect it."

2. RFC 2459 does not even specify how a signature is generated (e.g., via a
monolithic or fragmented private key).

In this way RFC 2459 does its job while allowing others to do their jobs.

Frank

---

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 08:28:15 -0700

Sorry Peter, Yes of course . Let me say this publicly for all -

I will remove my objections to the TSP being advanced to "proposed Draft
Standard", but I have to ask the WG Chairs - Hey Stephen/Tim - Is this TSP
effort intended to be PKIX's "One and only" Time Stamping Protocol?

By the way - I still think it is silly to do this, to advance this
particular draft without the mods I have asked for (esp. the AD), and at the
very least I really want to get the term "TTP"  into the name of the Draft
effort so it more accurately reflects the process of what it provides.

But I understand that this effort (the TSP one) is being perceived now as
one of those "Bill's that languish in committee too long" - and the need to
advance it or to kill it.

Todd

----- Original Message -----
From: "Peter Sylvester" <[email-masked]>
To: <[email-masked]>
Sent: Monday, September 18, 2000 7:37 AM
Subject: Re: Fw: The need for two grades of time data.

> >
> > All - this is a conversation between Denis Pinkas and myself in which:
> >
> >     1)     I removed my objections to the TSP Draft being advanced to
draft
> > standard
>
> I guess You mean PROPOSED STANDARD?
>
>

---

From: Hal Lockhart <[email-masked]>
Date: Thu, 21 Sep 2000 12:37:42 -0400

> Small problem here: Is PKIX not a customer of NTP, for its 
> time information?
> 
> -Mat Butler

Not necessarily. As I understand it, I can by a couple of atomic clocks, or
a land line to NIST and go into the TSP business.

Hal

=======================================================
Harold W. Lockhart            Entegrity Solutions
2 Mount Royal Avenue          Marlborough, MA 01752 USA
V: 1-508-624-9600 x 260       [email-masked]
F: 1-508-229-0338             www.entegrity.com
=======================================================