[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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
=================================================================
Object: Re: Comments on time-stamp-01: Identification of TSA
Date: Thu, 27 May 1999 13:55:18 -0400
From: Stephen Kent <kent@bbn.com>
To: "Todd S. Glassey - ELN" <tsgman@earthlink.net>
Copies: <ietf-pkix@imc.org>
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 <Denis.Pinkas@bull.net>
To: "Todd S. Glassey - ELN" <tsgman@earthlink.net>
Copies: ietf-pkix@imc.org
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 <kent@bbn.com>
> To: Todd S. Glassey - ELN <tsgman@earthlink.net>
> Cc: <ietf-pkix@imc.org>
> 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" <Todd.Glassey@www.GMTsw.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "Hans Nilsson"
<hans.nilsson@iD2tech.com>
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)