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

From: Mathew Butler <[email-masked]>
Date: Wed, 13 Sep 2000 16:36:50 -0700

Oooh, this is a 'pet project' thing.

I agree that the time needs to be authenticated, and perhaps more
importantly, the source of the time needs to be authenticated.  Network Time
Protocol et al notwithstanding, it's far too easy for a single machine's
clock to be adjusted for whatever reason.  (And, with NTP, for the entire
network's time to be adjusted.)

So, we cannot trust anything that comes out of a single network.  Now, if
there's a device that provides an accurate source of time data (such as by
listening to the US Naval Observatory time radio frequency, or the GPS
date/time), is there anything to say that the manufacturer of such
data-providing device should not have a CA key that could then be used to
sign embedded timestamping certificates in the devices themselves?  Perhaps
either by passing the data in to be timestamped, or by generating a
self-contained "timestamp token" that would be embedded in the data before
signing?

(I can see a market for a network-based service, as well... get a signed
timetoken for $0.33, as much as it costs to get something postmarked at the
USPS? :>)

The time data must be authenticated.  Otherwise, I could set my machine's
clock in the past and sign something with an expired certificate that will
-appear- to be valid.  There are two things that I can see that could stop
this:

1) A 'secure notary log' form of software, that logs everything that I sign,
or
2) A 'trusted timestamp'.

With a 'trusted timestamp', we have a problem, though... what if I want to
generate something later, but make it appear to be earlier?  I could request
a timestamp of, say, 3 years ago, and not embed that into the data I want to
sign until now.  So, we have to have a kind of dual-process system, where
the embedded timestamp is the 'was-not-signed-before' date, and the wrapping
timestamp is the 'was-not-signed-after' date.  And if the timesource is
someone or something that is "trusted", then it's the window inside that
makes the difference.

(Incidentally, I'm a techie who just got burned on not being able to prove
when a physical document was signed, so I have my own agenda here, that is
perhaps useful to more than just myself.)

-Mat Butler

-----Original Message-----
From: todd glassey [mailto:[email-masked]]
Sent: Wednesday, September 13, 2000 3:17 PM
To: Denis Pinkas
Cc: [email-masked]
Subject: Re: The need for two grades of time data.

Denis,
I apologize for the length of this response but you hit some hot spots for
me - and I really dislike the provincial tone this has taken on, including
my own. It is clear to me that there is emotional content for all concerned
here and we need to rise above that as Time Stamping is way to
important to the bigger picture of eBusiness and Audit/.Risk management.

Before you goon and read the response below and get ticked off  - let me say
I myself  would support advancing the TSP Draft to Standard 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.

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: Bruno Salgueiro <[email-masked]>
Date: Thu, 14 Sep 2000 11:11:48 +0100

Hi to all.

  That's why the DVCS standard is important. Please take a look at the
latest standard and see why with DVCS you can be sure that a document
was signed at least at a particular time, also verifying signatures and
certificates.

  I think that we're trying to overkill TSP with this discussion. TSP
only asserts that some bytes were delivered at a particular time and
the TSP's policy will say specifically what kind of source was used
to get the timestamp. Couldn't we say, for the sake of clarity and pet
projects aside, that there should be a kind of CP for TSPs regarding
time accuracy?

  Finally, I went to the BERT site, read the "standard" quickly and I
don't think that it (or something similar) might solve this issue. The
trust on the time source and the signature of the token being
timestamped
must come from the TSA, IMHO.

Regards,

-- 
=======================================================
Bruno Salgueiro       (mailto:[email-masked])
                   
Grupo de Trabalho de Certificação Digital
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

This message was digitally signed with a MULTICERT cer-
tificate to give an identity assurance. In order to
download the root MULTICERT certificate please go to :
             http://www.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================