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

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 07:23:07 -0700

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

    2)    I also recommend that we include the term TTP in the title of the
Draft and Denis re]torts with that PKIX may object but he is OK with it? So
how does the rest of PKIX feel about this?.

I would like to have the phrase "TTP" inserted into the title of the draft
as it is advanced to "Draft Standard" so that the use model of the Protocol
is defined by its title more accurately

Any problems with this?

Todd Glassey

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "todd glassey" <[email-masked]>
Sent: Monday, September 18, 2000 4:13 AM
Subject: Re: The need for two grades of time data.

Todd,

> Denis - Good morning how is France today? California is a bit overcast
here
> in the Valley (North end of Stanford Campus area). Anyway your responses
are
> good here.

Thanks. :-)

SNIP

> So I interpret your statement as being implicitely supportive of
> advancement to Proposed Standard, and at this time not supportive of
> advancement to Standard. Mee too. So let us close this issue.
>
> YES at this time I will remove my objections

 .. so could you simply reply to this message while copying the PKIX
mailing ?

I am not sure that the PKIX group will accept the addition of the
word "TTP" in the title, because TTP has several co-notations
according to who you speak to, but you can try.

--- SNIP ---

Regards,

Denis

> and I think I can get the Notary Associations to
> accept it if you make the mods I have requested. If you woulnd't mind
adding
> an author I will make the first pass at them and submit the new reviser
> Notary Protocol to the Group.
>
> > if it allowed
> > for multiple use models, and updating to address emerging and audit
driven
> > needs. As it sits now it is too closed and restricted.
> >
> > What we have in the TSP now  is a TTP based service model that does not
> > authenticate the time data it claims is evidence - so the total reliance
> on
> > the marque is based in proving some nebulous time data instance without
a
> > proofing model. Might as well be human testimony.
> >
> > Your included text starts here
> > --------------
> > It seems that you are trying to re-open a discussion that took place
> > in May 1999 (along BERT). So let me provide you with a copy of some
> > E-mails from May 1999 so that we can *definitively* close this
> > discussion.
> >
> > Denis
> > --------------
> >
> > Since you have thrown the "this is a closed issue" down, let me say I
> > disagree - it is my opinion that this was not decided by the group, or
> even
> > debated openly.
>
> IT IS A CLOSED ISSUE. Let me report the official minutes of the 45
> th IETF meeting to prove this (as far as I remember, you were not
> present at this meeting).
>
> " Temporal Data Token (M. Duren-WetStone)
>
> Presentation focused on format for TDT (in the TSA) that helps
> attest to the integrity of the time source, i.e., providing a link
> to a trusted time source. This approach pushes evidence of time
> source into a token, vs. other, external measures that a TSA
> akes to ensure the accuracy and integrity of its time source.
> A claimed feature of this approach is that it allows a client
> to be able to verify the utility (for non-repudiation) of the
> returned token immediately, vs. the deferred verification more
> typical of TSA operation. As with the BERT presentation, the
> speaker was asked about possible intellectual property claims
> nd about the breadth of vendor support for the propose
> TDT format. The speaker asserted that he was aware of no IP
> claims, and that he was aware of at least two vendors who had
> expressed interest in this format, although no more than one
> was building products to this spec at this time. The WG Chairs
> and the Security ADs also will need to discuss whether this is
> within the scope of PKIX, before this item progresses. "
>
> Please read very carefully the last sentence.
>
> Then, after the meeting, Stephen Kent and Warwick Ford (i.e. the two
> co-chairs of the PKIX WG) decided that BERT was not appropriate for
> PKIX. They suggested that it be brought to STIME. It was, and STIME
> rejected it as well.
>
> So, PLEASE, leave the bandwith of the PKIX mailing list for other
> maters of discussions.
>
> Denis
>
> > I understand what the TSP is and does, I think from a commercial
> standpoint
> > this is really not what time stamping systems want to be. Lets answer
the
> > following questions and see where that leads the group.
> >
> > 1)    If the purpose of the time stamping protocol is to enable decision
> > support processes by "validating signatures in time", then how is that
the
> > time data authentication process was overlooked? It seems to me that the
> > credibility of the time data is directly tied to the believability
> resource
> > produced by the Signature Validation Process, isn't it?  If so, then why
> > would we leave that to an external CPS that was tied to the Host's
> operating
> > environment or OS operation practices???
> >
> > 2)    If the purpose of  the timestamp is evidentiary, then the quality
of
> > the time data, how it is authenticated, where it came from, and who it
was
> > certified by is critical to the trust process.
> >
> > The need for a grade of time data that is nonrepudiated and is traceable
> to
> > the BIPM or UTC /GeT is very important to the big picture and every
trust
> > process we build. To put our heads in the sand and claim that this is
the
> > OS's problem or that of the people that operate the system is also
> > ludicrous.
> >
> > The point is whether you are building an evidentiary system that can
stand
> > on its own, or one that requires the TSA to validate/use the marques of.
> > You use PKI and other technologies to authenticate the source of the
> > non-parametric data points, but not the time data. Why? and why cant the
> > token stand on its own two feet?
> >
> > 3)    Why constrain the system to a TTP architecture only? many of the
> legal
> > processes we do today are based in Ceremony. Notorial, filing a legal
> > document, etc. these are all based in ceremony. So the creation of the
> > timestamp is essentially that ceremony. that means that the time stamp
> > itself is the evidentiary token representing the completion of the
> > ceremonial process and so the timestamps by themselves have value and
> worth
> > in token exchange and processing models.
> >
> > This is why BERT was so important - and as long as we are talking about
> the
> > BERT...
> >
> > BERT
> > ------
> > I agree with your commentary about how fast BERT was shot down - the
BERT
> > Token structure is clearly a threat to the TSP in that it does exactly
> what
> > is defined in the three requirements above. Now I do have to admit that
> the
> > initial BERT-1 Token Structure has some interesting problems with its
> > granularity representation and a possible potential for the dual-events
> > within the same granularity window, but that was fixed in the 2nd
> generation
> > BERT-II  Structure, which I suppose I should file.
> >
> > FYI - BERT-II turns the best of the XML and IOTP token processes into a
> TSP
> > Evidentiary Token and not only addresses the content certification, but
> the
> > type of the event as well. BERT-II supports virtually all key or crypto
> > techniques and has plugin capabilities for building an event
> representation
> > specific to the end-use needs. Its small  and expandable to also contain
> the
> > content it watermarks as well and with this model, you don't need the
Time
> > Stamp
> > Server just the BERT tool Set to extract or validate any of the
> components.
> >
> > Just follow the use rules and there you are.
> >
> > If anyone is interested in the BERT-II token structure prior to the
Draft
> > being filed in the next 2 weeks, send me a email and I will send the
> > preliminary draft to you.
> >
> > Todd
> >
> > ---- Original Message -----
> > From: "Denis Pinkas" <[email-masked]>
> > To: "todd glassey" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, September 13, 2000 3:57 AM
> > Subject: Re: The need for two grades of time data.
> >
> > 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.
> >
> > > Just my two cents.
> >
> > =================================================================
> >
> > Object:  Re: Comments on time-stamp-01: Identification of TSA
> > Date:    Thu, 27 May 1999 13:55:18 -0400
> > From:    Stephen Kent <[email-masked]>
> > To:     "Todd S. Glassey - ELN" <[email-masked]>
> > Copies:  <[email-masked]>
> >
> > Todd,
> >
> > There is no requirement that the time stamp carry info that purports
> > to trace the origin of the time source.  That info may be expressed
> > in the TSA's policy, as a static assertion, unless the WG determines
> > that such a static assertion is not sufficiently flexible.  For
> > example, a TSA might say that they use GPS, or use a specific NIST
> > source, or whatever. So long as the policy can be associated with
> > the TSA that should suffice.  I assume that a TSA will tend to be
> > consistent, for fairly long periods, in its choice of time source,
> > so a facility to record this data in each token seem like overkill.
> >
> > Steve
> >
> > =================================================================
> >
> > Object: Re: Comments on time-stamp-01: Identification of TSA
> > Date:   Fri, 28 May 1999 11:43:40 +0200
> > From:   Denis Pinkas <[email-masked]>
> > To:     "Todd S. Glassey - ELN" <[email-masked]>
> > Copies: [email-masked]
> >
> > Todd,
> >
> > Altough this E-mail is primarily for Steve, I would like to make a
> > few comments on it:
> >
> > 1° I think that the tone that is being used in your reply here is
> > not adequate and should be moderated.
> >
> > 2° We are defining a Time Stamping Protocol that can be used in many
> > dfferent contexts. We do not claim that it is usable in all the
> > contexts. We have made a few *simple* extensions that were beyond
> > the original goal, in particular to be able to answer to the simple
> > question "What time is it ?" when the requester has no local time
> > available. The primary need is only to prove that a digital
> > signature was created before a given date. That digital signature
> > may be any signature; e.g. from a user; from a CA for a user
> > certificate, cross-certificate, CRL, ARL; from an Attribute
> > Authority for an Attribute Certificate ... As there are too many
> > examples of use, only a few are mentioned in the annex.
> >
> > 3° The protocol is sufficient for our current needs. Thus I do not
> > see the need to extend the terms of reference of our charter to
> > cover more.
> >
> > Regards,
> >
> > Denis
> > (co-author of the current draft)
> >
> > > Stephen
> > > I respect and appreciate your accomplishments but I think you dead
wrong
> > > here and everything I have had to live through for the last two years
> > tells
> > > me I am right.  My issue in saying this publicly is that "Stephen
Kent"
> is
> > a
> > > name that carries a lot of weight when it is attached to an opinion,
> which
> > > is why I am so baffled as to your resistance to building in these
> proofing
> > > facilities into the timestamping process.
> > >
> > > It seems to me that what we are focusing on here is an elaborate
> mechanism
> > > to pass relative time through a distributed infrastructure, rather
than
> > the
> > > real goal - that being to have a system for representing events in
time
> > that
> > > is accurate, believable, and commercially viable.  Mark the phrase
> > > "Commercially Viable", because it is the key to any market success we
> will
> > > have unless someone puts a law in place to mandate our products.
> > >
> > > Personally, I am starting to want to call this timestamping protocol
the
> > > Bradley Fighting Vehicle of the PKIX group - ever see Kelsey Grammer
in
> > > "Pentagon Wars" - and although I know that is not true, it's sorta how
I
> > > feel about all the abuse I have taken for questioning the use and
> > > architecture of this effort's end goals.  The ultimate reason for my
> > > responses here is driven in the simple economic fact that if I have to
> > shell
> > > out money for this technology, it better pay me back somehow.
> > >
> > > As to your commentary particular that "it's not there" below, that is
to
> > > say, the ability in the protocol to prove the chain of custody against
> the
> > > time source - I know it's not there and I am trying to figure out why.
> > >
> > > What I think we have built here today is a system that requires the
user
> > or
> > > operator to jump through external hoops to prove the process and model
> of
> > > operations at the sites are OK, otherwise the timestamps issued are of
> > > questionable veracity and as such there use and reception are likely
to
> be
> > > limited.
> > >
> > > As to the existing draft's specification, my problem is that I have
> still
> > > not figured out a legally binding model for a large enough segment of
> the
> > co
> > > mmercial world to use this timestamping technology, that this makes
> > > commercial sense.
> > >
> > > DONT GET ME WRONG - I AM NOT TRYING TO TELL YOU THAT THE ZUCCERATTO,
et
> > al.
> > > DRAFT IS BROKEN, just that I want to understand the use models driving
> all
> > > this effort in detail.
> > >
> > > ----- Original Message -----
> > > From: Stephen Kent <[email-masked]>
> > > To: Todd S. Glassey - ELN <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Thursday, May 27, 1999 10:55 AM
> > > Subject: Re: Comments on time-stamp-01: Identification of TSA
> > >
> > > > Todd,
> > > >
> > > > There is no requirement that the time stamp carry info that purports
> to
> > > > trace the origin of the time source.  That info may be expressed in
> the
> > > > TSA's policy, as a static assertion, unless the WG determines that
> such
> > a
> > > > static assertion is not sufficiently flexible.
> > >
> > > I question this
> > >
> > > > For example, a TSA might
> > > > say that they use GPS,
> > >
> > > Stephen, personally I don't think that this will ever happen in a
> > > commercially functional sense.
> > >
> > > #1  no one would who needs a really viable audit done would use and
rely
> > on
> > > the timedata from GPS alone, since the US Air Force controls it. Also
> > there
> > > is the real world a pretty major problem in that the GPS sattillites
> that
> > > are currently available are going to start decommissioning themselves
> > > because their Atomic Clocks are out of cal [becuase of their age] and
> as
> > > such, they cannot be adjusted or refurbished in their current orbits.
> > >
> > > >From my last understanding, the US Congress has reallocated the
> > replacement
> > > GPS Sattellite launch slots on the STS  (the Shuttle) to other
> "projects"
> > > including the international space station, so at last count GPS is
sort
> of
> > > dying... or its at least being ignored. Also, I further understand
that
> > > there is a funny issue ofthe  Air Force trying to unload the
operational
> > > costs and responsibility for operating the GPS network since they
don't
> > need
> > > it to pilot warheads down a chimney pipe from orbital anymore.
Intertial
> > Nav
> > > being what it is these days and precision timepieces themselves...
> > >
> > > If I am wrong here, would someone from the Fed, NIST, or the Air Force
> > step
> > > in and set  the record straight for all of us?
> > >
> > > #2  I  seem to recall Judah Levine, NIST's master timekeeper,
mentioning
> > > several occaisions where the Air Force had actually intentionally
> diddled
> > > the time to make it inaccurate for 'wartime service reasons', and
since
> > GPS
> > > has no authentication for the public users, this commercial relaince
> just
> > > doesn't make sense.  If you have any doubt of this check with Pat
Cain,
> > the
> > > remark was part of Judah's general presentation to the ISC in Seattle
> last
> > > September, and  we were both there so he can verify  this
> > >
> > > #3 Also, as another issue about the physical act of deploying GPS,
most
> > > commercial customers would need Roof Access or something similar to
> > support
> > > their GPS site, unless they buy Datum's new RF system for locally
> > > distributing GPS...  [Anyone from Datum want to jump in here? Dave,
> Bill,
> > > Ron, Greg?].
> > >
> > > #4 Not to mention GPS's epoch is coming this August 22nd and none of
the
> > > cheap systems will be able to deal with it that I know of.
> > >
> > > Datum and the other players had to extensive firmware updates to
support
> > the
> > > rollover in their receivers, since when the AF designed GPS they
assumed
> > we
> > > would all be dead now or the system no longer in operation. That's why
> the
> > > 10 bit wide week counter is it in GPS. Nice thought, eh?
> > >
> > > Don't lose complete faith, all in all, they (Congress) will likely
> address
> > > this when the multitude of Cadillac Owners gets PO'd that their
> NorthStar
> > > Autolocator's don't work, or you turn your GPS system on and it say's
> > > "HELP - NO SATTELLITES ACQUIRED".
> > >
> > > Now, alternatively - there is GLONAS, but the Russian's are not looked
> on
> > > too favorably in the technical services arena to date, so it is
unlikely
> > > that this system will be implementad as a commercially viable
timesource
> > > without a new operator... like maybe the UN (just my own opinions
here,
> > > BTW). Likewise, in Germany the have the DFS77 system. My point is that
> > very
> > > few countries outside the US trust GPS and rightly so.
> > >
> > > So, unless maybe some member of the Big-4 Audit staff wants to
publicly
> > > stand up and say GPS is OK by us and our customers the world over,
I'll
> > > rest this issue.
> > >
> > > >or use a specific NIST source,
> > >
> > > In this country or in any country that contracts with NIST to operate
> > their
> > > "Clock's",  this would be fine - if you could show how the time data
got
> > to
> > > you and you could prove the chain of custody against it. Currently the
> > > public NIST servers do this.
> > >
> > > >or whatever.
> > >
> > > Annnnnngggggggghhhhhh (insert "Buzzer" sound here)- This last one is
the
> > > wrong answer from my viewpoint, "whatever" means that we get to
> > 'free-form'
> > > our proofing models - so I have to ask the rhetorical question "whats
> the
> > > point of standardizing the methodology of building the token structure
> as
> > we
> > > are with these efforts, if the time data is crap and unrelaible?",
> becuase
> > > then it all comes down to my word against your and thats worthless to
me
> > as
> > > a commercial provider. It seems to me that tghe real issue here in the
> > > relative timestamping systems is that they cannot deal with the issue
of
> > > distributing legally relaible time. Its not that hard. Its just that
its
> > > something that you have to go talk to a physicist about rather than a
> > > programmer, eh?
> > >
> > > > So long
> > > > as the policy can be associated with the TSA that should suffice.
> > >
> > > I disagree here too - The value of the timestamping is in the
stability
> of
> > > the event representation structure that is produced as  the
evidentiary
> > > output of the proofing services. Not in the TSA's policy that operates
> it.
> > > The TSA's policy is only an attribute of the engine creating the
stamp.
> > >
> > > >I assume
> > > > that a TSA will tend to be consistent, for fairly long periods, in
its
> > > > choice of time source,
> > >
> > > Steve, I think that this is a bad assumption to make. I think that
> > > timestamping is something that will happen to the bigger picture and
> that
> > > the commercial world will absorb the overhead of the token structure
and
> > > processing info, but that they need absolute, not relative
timestamping.
> > >
> > > In closing, I feel that this Time Stamping is important for making EC
a
> > > global thing like it could be. So pardon my "enthusiasm", but here the
> > real
> > > issue is the International Standarization on the event representation
> > > mechanism, i.e. the token itself. The method of creating it is
> important,
> > > but is a secondary consideration.This is why the BERT proposal is so
> > > powerful (http://www.gmtsw.com/ietf).
> > >
> > > Todd
> >
> > =================================================================
> >
> > ... and finally an E-mail sent by Todd to me, not to the PKIX
> > mailing list that is worth to mention:
> >
> > Object:  Re: Long-term validation of signatures
> > Date:    Mon, 26 Apr 1999 14:37:55 -0700
> > From:    "Todd S. Glassey" <[email-masked]>
> > To:      "Denis Pinkas" <[email-masked]>, "Hans Nilsson"
> > <[email-masked]>
> >
> > Denis, don't take my commentary wrong.
> > The Draft(s) that you Pat, Carlisle, Robert produced are
> > FANTASTIC!!!. They represent the first credible mechanism for a
> > subsumable timebase service model and thats top-notch.
> >
> > (snip)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2000 11:15:12 -0400

Todd,

I don't think the name needs to be changed, but I think the intro 
should contain  text that notes the TTP context in which TSP operates.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 11:56:57 -0700

My concern then Stephen is that this is to become the ONLY PKIX TSP.  Is
PKIX open to advancing other standards that might do this as well?

Todd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2000 15:15:26 -0400

Todd,

We have no other PKI-oriented time stamping standards on the table. I 
don't think we can answer that question in the abstract.

Any candidate would have to be technically sound, not encumbered by 
any IP [certainly no more than we already have :-)], consistent with 
our PKI models, and be accompanied by a well written description.

Nothing that has been submitted to this list has met these criteria.

Steve

---

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 14:20:32 -0700

Steve - I'm sorry - maybe I was not clear enough in what I asked. I wasn't
speaking to the actual but to the theoretical. The question is not has
anyone submitted it already, but rather will the WG Chairs support their
being more than one standard.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2000 17:41:56 -0400

Todd,

>being more than one standard.

My response reflects the fact that I would not commit to the 
viability of another standard until we hand an example in hand.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 18 Sep 2000 16:02:40 -0700

"Objection, Your Honor!  Calls for speculation."  :)

I feel like I'm watching a techno-geek courtroom drama.

Is there really any objection to the (hypothetical) statement:
"The PKIX WG Chairs would support a non-TTP TSP standard if it
met conditions X, Y, and Z (to be disclosed only under duress.)"

Seriously, is it fundamentally IP issues, or "non-TTP model"
issues, or "there can be only one TSP standard" issues, or
something else that is objectionable "on principle alone".

This is important, as much wasted effort could be avoided by
knowing in advance the substantial objections.

Curious.

___tony___

At 05:41 PM 9/18/00 -0400, Stephen Kent wrote:
>My response reflects the fact that I would not commit to the viability of 
>another standard until we hand an example in hand.
>
>Steve
>

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Sep 2000 19:05:16 -0400

Tony,

>something else that is objectionable "on principle alone".

It's not "non-TTP model" and it is IP concerns. But we also don't 
need to endorse equivalent ways of doing the same thing, since that 
degrades interoperability, or imposes extra burdens on implementors. 
We've having that debate no with regard to delegated path processing, 
validation, etc.  I don't want to limit the reasons I might object to 
another TSP proposal to the set that are immediately obvious: there 
may be innumerable examples of other bad TSP model one could devise 
:-)

>knowing in advance the substantial objections.

Another way to think of this issue is that there had better be a 
very, very good reason to introduce another means of achieving the 
same effect, or it is a waste of everyone's time.  This is generally 
a good basis for such decisions.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 18 Sep 2000 16:47:46 -0700

At 07:05 PM 9/18/00 -0400, Stephen Kent wrote:

>It's not "non-TTP model" and it is IP concerns. But we also don't need to 
>endorse equivalent ways of doing the same thing, since that degrades 
>interoperability, or imposes extra burdens on implementors. We've having 
>that debate no with regard to delegated path processing, validation, 
>etc.  I don't want to limit the reasons I might object to another TSP 
>proposal to the set that are immediately obvious: there may be innumerable 
>examples of other bad TSP model one could devise :-)

The latter seems then to fall under "something else that is objectionable 
on principle." :)

The central (non-IP) issue is then the validity of the phrase
"equivalent ways of doing the same thing".  Certainly, there is
no need or desire to really do the same thing in different but
equivalent ways ... so ...

1.  Are these "the same thing"?  Todd argues that "time as control parameter"
and "time as evidentiary content" are in principle different things, and that
this is not just a matter of degree but a matter of kind.  If these are really
not different (equivalently, not needed), then the story ends quickly.

2.  Are the assurance procedures really "equivalent ways"?  If there is truth
to the distinction regarding "time, the evidence", and a reason to believe
that it may be a quantity "in demand", then one must examine if it deserves
other than the TTP-treatment for assurance.

(Indeed, an attempt to rely upon a TTP model seems to introduce an endless
regress of stamps and assurances.  At a minimum, it has a multiplying effect
on "things to be assured about.")

Perhaps by sticking to the core "is it really different/needed" examinations,
one can progress to a resolution without the allusions to ulterior motives
that often surface (Mea Culpa!)

___tony___

---

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 16:57:42 -0700

THANKS  Tony I agree.
----- Original Message -----
From: "Tony Bartoletti" <[email-masked]>
To: "Stephen Kent" <[email-masked]>; "todd glassey"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 18, 2000 4:02 PM
Subject: Re: Fw: The need for two grades of time data.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 18 Sep 2000 17:03:18 -0700

Stephen I understand how to solve part of this problem, it is my intent to
submit an API Specification for the use of the already existing NTP AutoKey
to this group for TSP Uses.

The draft will be in as an I-D within 14-17 days. Anyone that would like to
collaborate on this please contact me immediately. We will in this draft
also show the use of the TSP API on top of NTP to address the evidentiary
problems that the TSA does not address as well as a number of other protocol
interfaces like one to generate TST's for IOTP and XML uses.

I personally would suggest holding the standard until then and reviewing it.
Two weeks does not push the time frame out too far to delay any decision on
the TSP Draft and advancing it over something as heavily deployed as the
Network Time Protocol.

Todd

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 19 Sep 2000 09:16:13 +0200

Todd,

> to this group for TSP Uses.

APIs is usually not a task performed by the IETF; it is only
performed by exception. The GSS-APIs fall under that exception. 

NTP is not part of the charter of this group, so this kind of topic
cannot be dealt in the PKIX WG, unless the charter is changed. 

> The draft will be in as an I-D within 14-17 days. 

You can certainly post such a draft, but as an individual draft, not
as a PKIX draft.

> Anyone that would like to

This is unrelated, so your "suggestion" is not relevant.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Tue, 19 Sep 2000 09:01:59 -0700

Tony your response below touches on two key issues

    1)     Is there any difference in time for evidentiary grade purposes
and that provided by any other time source (Yes of course there is.
Evidentiary Time is non-repudiated and the other time sources are not.)

    2)    How the TSP/TSA Architecture provides services.

The are both very important but important questions/concepts, and they
should not be confused. Lets look at the first one. The issue of Evidentiary
Time Data.

In answering these questions lets look at the real world solutions today.
First lets answer the question: What is the need or desire for a evidentiary
grade of time data? the answer to that is simple. In proofing and
comparison-based decision support systems, the willingness for people to
trust these systems is often 100% rooted in the whether they can document
what they say is or is not. The concept is clearly outlined and is woven
through most of what PKIX does under the term "non-repudiation", so lets
look at today's timebase system's and apply non-repudiation to them. i.e..
do they support it?

    a)    NTP by itself - NTP By itself will authenticate the end-node
identity of the Time Service Provider (the NTP Server) either in symmetric
or asymmetric service models if you can find someone to operate such a
service. Becuase of the PKI or Symmetric Key Management and the audit
overhead, none of the Public NTP Time Servers will provide this. ONLY the
commercial services like those offered by CertifiedTime today address this
concept that the quality of the time data is guaranteed inline in the NTP
Audit Process and there is a real money indemnity policy backing this. Hence
getting time from a TA (rather than a CA).

For generic NTP when the PKI Extensions are widely distributed this will
allow for various players to operate these anchored NTP Servers, but even
that wont provide the NR we are all looking for in digital trust processes.
However this NR facility, since it is not as time sensitive as the actual
deployment of NTP time makes NTP work as one obvious answer as a generic
Time Service transport including being a transport for the TSA.

Bluntly, the TSP Use and Time Data NR features could easily be added to the
NTP process as an additional parcel as a part of the user defined payload.

    b) ACTS - The NIST or USNO ACTS systems - provides no security or record
of the use. No access to certifiable time is available through this as well
although it is performed form a closed circuit non-networked system so the
audit value is better IMHO than generic NTP.

    c)    GPS Systems - Many security reports are now surfacing on the DoS
and spoofing susceptibility of the GPS system, but from an audit standpoint
there is even a larger vulnerability here in that GPS cannot be
authenticated or the results of stored in such a manner as the transaction
process can be rebuilt for later review. GPS being passive in nature has
virtually no way for Civilian Receivers to replay or rebuild any of the GPS
Timestamps issued as part of the GPS system's operations.

The other issue is in understanding the true security perimeter of the GPS
systems operations models. This is an important concept since by addressing
it we discover that GPS, an externally processed signal, and the particular
GPS data stream is unauthenticated in conveyance and its
certification/accuracy making the reliance on GPS a pure Trust RISK. Not an
enablement as many have been lead to believe. Sorry folks, the using GPS as
a source of trusted time is a mistake IMHO.

Many people believe that using a security policy wherein a log entry shows
when the GPS Signal Lost Lock will provide this "logging of the signal
process" but it really does not do this. The issue is that since the GPS
Data Service Model  is still passive in nature this relying on the "Pilot
Lock"  really means little or nothing at all from an audit perspective. The
totality of the envelope of trust for a GPS system is IMHO  the skin of the
Receiver unit itself and not its injection point into the computer whether
that is at the Bus Interface Level or through a Serial Port. .

One of the issues here is in removing human culpability from the process
stages internal to the transaction processes. It is bad enough that human
participation limits the reliability of the raw data points such that PKI
has to be used to prove them, but the same liability exists with the time
and other audit parameters as do the certificate parameters that we have
fought so hard to authenticate. This is the point wherein time data is used
as content rather than plumbing or infrastructure, and as such it deserves
the same levels of authentication and trust processing as any other
datapoint in the trust envelope in question.

The point is does the setting of the OS TOD clock require an Evidentiary
Grade of time or not. That is the question that really needs to be answered
here and the answer is that the audit and trust processes will make that
determination. Since the TSA takes time off the underlying OS without any
concern for its validity is a problem in my book too.

Todd

---

From: Michael Sierchio <[email-masked]>
Date: Tue, 19 Sep 2000 09:57:30 -0700

todd glassey wrote:

> do they support it? ...

Your observations are cogent and lucid, but I tend to agree that the 
problems you articulate are operational matters, without direct relevance
to the TSP itself.

There are hazards inherent to relying on GPS as a sole means of
authoritative time data, just as there is risk inherent in relying
on it as a sole means of navigation.  There are several operational
steps that can be taken to provide trust in the evidentiary value
of the time data used, all of which seem outside the scope of the
protocol discussion, or even the choice of time signal source.

I am very much interested in continuing the discussion, which has
merit,  in a different context.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 19 Sep 2000 10:16:09 -0700

Denis,
how is this TS API not an API and wherein is it a true networking protocol.
This process is as much application dependant as any so what would you do,
design a shared library of these services, OK that sounds like middleware to
me. What do you call it?

Todd

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 19, 2000 12:16 AM
Subject: Re: Fw: The need for two grades of time data.

> You can certainly post such a draft, but as an individual draft, not

How do you figure.

> This is unrelated, so your "suggestion" is not relevant.

Sorry it is exactly relevant and the draft should be held if the underlying
assumption I made in the original posting is correct.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 19 Sep 2000 23:03:47 -0700

I have to apologize because this is a philosophical retort  and I don't mean
to be a stick in the mud but -

> cannot be dealt in the PKIX WG, unless the charter is changed.

Denis this is just not true- the use of any protocol with PKI in it is
germain to the Charter of this WG whether that core protocol was developed
here or not.   Read the first sentence of the 2nd paragraph of the WG
Description on the WG's homepage It's quoted below:
----
"The working group is now embarking on additional standards work to develop
protocols that are either integral to PKI management, or that are otherwise
closely related to PKI use."
----
Time and its services are clearly members of this set. So then using PKI
Authenticated NTP as a timebase for general PKIX PKI would have made a lot
of sense. Especially  with the sheer number of places its already deployed.
It would have given PKIX protocol's tens of  millions more seats than they
already have, automagically. You know if people had to get x509 certs for
the millions of routers they had, it would have advanced the cause of x509
use tremendoulsy and as such our world as well.

What is it Dennis Miller Says - "But hey, that's just my opinion".

Todd

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 20 Sep 2000 08:33:17 +0200

Todd,

As you said at the very end: "But hey, that's just my opinion". I do
not share your opinion.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Sep 2000 15:55:15 -0400

Todd,

>here or not.

Not true. S/MIME, TLS and IPsec make use of PKI, but are clearly out 
of scope. They are consumers of PKI services, just as one would 
expect NTP to be when  it makes use of PKI for authentication of its 
communication.

>Read the first sentence of the 2nd paragraph of the WG
>Time and its services are clearly members of this set.

Time is covered under this when it is intrinsic to PKI management or 
use, as is the case for a time stamping protocol.  There are many 
ways for a  PKI user to acquire time for use in cert processing.

>  So then using PKI
>already have, automagically.

This is pure speculation, bereft of substantiation! It ignores the 
typical reasons usually cited for reluctance by a company to 
establish a PKI.

>You know if people had to get x509 certs for

S-BGP is another application that motivates issuance of certs to 
routers, but I don't expect it to make a dent in broader use of PKI.

Steve

---

From: Tim Polk <[email-masked]>
Date: Wed, 20 Sep 2000 16:18:52 -0400

Todd,

You said you were withdrawing your objections to TSP's progression. Thank you.

You asked to have TTP inserted into the name.  Steve suggested that the
scope could note that the spec is based on a TTP model.  I think that's
reasonable.

Let's progress TSP and move on, okay?  It's a good spec, even if it doesn't
solve everyone's problems all the time.

Now, moving on....

You have asked if the WG chairs would support an additional protocol.  I
can't speak for Steve.  As for myself, I can't support a new protocol
unless I understand what it adds.  Multiple protocols that do the same
thing are no good for anyone.

I postulated a number of properties for the TSP spec in a number of
statements in my email last Friday and asked where I was wrong.  There has
been no reply to that message from you, Adrian, or anyone else.

Please take the time to read my message from Friday and comment on it.
Either the properties I postulate are (1) wrong, (2) insufficient, or (3)
there is no need for a new protocol.  In the absence of a response to
Friday's message, I am leaning towards (3).

Thanks,

Tim Polk

---

From: "todd glassey" <[email-masked]>
Date: Wed, 20 Sep 2000 15:24:04 -0700

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2000 12:55 PM
Subject: Re: Fw: The need for two grades of time data.

Come on Steve -

> ways for a  PKI user to acquire time for use in cert processing.

Steve I think you are wrong here. What this is really all about is the
difference in using time as content and in using "what time it is" as part
of the control process.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Sep 2000 16:44:10 -0400

Todd,

>difference in using time as content and in using "what time it is" as part

We disagree.

Also, it doesn't help that you continue to employ vague terms and 
phrases in your messages, even though they are not well defined nor 
widely understood in the context where this discourse is taking 
place.  Recent examples include: "proofing and comparison-based 
decision support systems," " digital trust processes," "removing 
human culpability from the process stages internal to the transaction 
processes," and above, "control process."  Your messages are littered 
with these phrases and with the Prominent Use of Upper Case, as 
though such capitalization made the words in question more 
intelligible or identified them as well-known terms.  This does not 
help.

Steve