Subject: The need for two grades of time data.

From: "todd glassey" <[email-masked]>
Date: Tue, 12 Sep 2000 10:24:47 -0700

All - I have some concerns with the TSP Draft and one of them that I will break out here is the merging of the concepts that Evidentiary and Policy Grade time sources are identical. They simply are not. There are a number of problems with the concept that instantaneously accurate time data is also provable by itself in the future. Without the proofing model, the value of the time data is that of the weakest link in the system.

The issue is that we use time as content and as a control parameter and it has very different uses and requirements in each. The use of time as evidentiary content, i.e. as in time stamping, is one where the source and viability of the time data is critical and with the current TSP we have chooses for some reason to specifically overlook this.

What I want to do is to start a process of formally defining what an evidentiary grade time source is and what it must conform to. 

This in PKIX and will allow us to understand time use models and more adequately define the needs and roles of trusted timing authorities in our larger trust processes.

Does this seem like a win for the group?

Todd Glassey

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Sep 2000 14:12:50 -0400

Todd,

>All - I have some concerns with the TSP Draft and one of them that I 
>will break out here is the merging of the concepts that Evidentiary 
>and Policy Grade time sources are identical. They simply are not. 
>There are a number of problems with the concept that instantaneously 
>accurate time data is also provable by itself in the future. Without 
>the proofing model, the value of the time data is that of the 
>weakest link in the system.
>
>The issue is that we use time as content and as a control parameter 
>and it has very different uses and requirements in each. The use of 
>time as evidentiary content, i.e. as in time stamping, is one where 
>the source and viability of the time data is critical and with the 
>current TSP we have chooses for some reason to specifically overlook 
>this.
>
>What I want to do is to start a process of formally defining what an 
>evidentiary grade time source is and what it must conform to.
>
>This in PKIX and will allow us to understand time use models and 
>more adequately define the needs and roles of trusted timing 
>authorities in our larger trust processes.
>

As noted in my response to your earlier message, the IETF is an 
international standards organization. The IAB and IESG have 
promulgated position statements on this topic several times. It has 
been most obvious in adopting security standards that conflicted with 
export control rules in several countries.

Looking at this in an international context, and absent a uniform, 
authoritative basis for the sort of time stamp related criteria you 
allude to above, it would seem that this sort of work is not 
consistent with what the IETF does as a standards body.

Steve

---

From: Rich Salz <[email-masked]>
Date: Tue, 12 Sep 2000 14:35:35 -0400

> evidentiary grade time source is and what it must conform to.

The IETF is not the place for this.  Start with ABA, or a similar
legal-focused entity.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 12 Sep 2000 12:12:55 -0700

>Does this seem like a win for the group?

No. In fact, it seems like a lose. It would be better to discuss this 
among experts in the field (that is, lawyers) with some technical 
assistance from the security industry.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "todd glassey" <[email-masked]>
Date: Tue, 12 Sep 2000 18:05:06 -0700

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.
  ----- Original Message ----- 
  From: Stephen Kent 
  To: todd glassey 
  Cc: [email-masked] 
  Sent: Tuesday, September 12, 2000 11:12 AM
  Subject: Re: The need for two grades of time data.

  Todd,

  As noted in my response to your earlier message, the IETF is an international standards organization. The IAB and IESG have promulgated position statements on this topic several times. It has been most obvious in adopting security standards that conflicted with export control rules in several countries. 

  Looking at this in an international context, and absent a uniform, authoritative basis for the sort of time stamp related criteria you allude to above, it would seem that this sort of work is not consistent with what the IETF does as a standards body.

  Steve

---

From: "todd glassey" <[email-masked]>
Date: Tue, 12 Sep 2000 18:27:11 -0700

Rich - I'm sorry but the IETF is exactly the place for it.

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

> The IETF is not the place for this.  Start with ABA, or a similar

SNIP

> >
> > The term "evidence" does pertain to proof, but "proof" has different
> > meanings in different contexts. Civil trial evidence rules vary from
> > one jurisdiction to another. PKIX is NOT going to wait for these
> > rules to become uniform, or cater to different sets of rules. This is
> > new legal territory and until there are ample case law precedents
> > nobody will really know what will be required.  We can get lots of
> > opinions from lawyers, and technologists who think they are lawyers,
> > but, none of these opinions are authoritative. So, PKIX will continue
> > to focus on the technical aspects of PKI and do the best we can to
> > provide a solid technical basis for whatever the legal community may
> > choose to adopt.

Actually here in the states this problem has already been answered by the
enactment of the Digital Signature Act and the Federal Rules of Evidence and
its a done deal already. Not something that Americans have a choice in
anymore, that is  without repealing or amending the currently in-force Law.
So there is law defining what X.509 Digital Signatures  and our PKIX systems
do here in the US... and the rest of the world is not far behind.

What I personally think this means to PKIX is that it whether "it like it or
not, it needs to look at legal things or it will eventuaually get its hand
whacked so bad that someone like congress will step in an nationalize it.",
and I think this neither funny or to far off in the inconceivable future
either. The systems and processes that PKIX architects will carry our money
and commerce and that means regulation like you never saw before. The last
50 years have just been getting ready for it. Just wait and see.

The reality is that now that there is legal basis in the technologies we
designed, they answer to a higher authority than us or the IESG and that is
that. If PKIX doesn't like this unique twist of fate, then maybe shutting it
down is appropriate.

In closing the point is that we as PKIX have an opportunity to embrace a set
of operations and audit guidelines that will enable more of what we produce
to see the end-market.

How grand is our collective ego to not want this?

Todd

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Sep 2000 11:22:28 +0100

> How grand is our collective ego to not want this?

The IETF has already decided that enforcing various local laws is not
within its remit (see the Raven WG) - that's not to say that PKIX should
not attempt to make itself useful within likely international legal
frameworks, but only in the sense of being capable of supporting them,
insofar as is possible and in keeping with the open and international
nature of the protocols, not by enforcing them as protocol requirements.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

Coming to ApacheCon Europe 2000? http://apachecon.com/

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 13 Sep 2000 12:57:15 +0200

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 <[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.
>
> 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: J Adrian Pickering <[email-masked]>
Date: Wed, 13 Sep 2000 12:09:59 +0100

>nature of the protocols, not by enforcing them as protocol requirements.

I concur. The focus is technical. However, technical decisions need to be 
made in the light of the real-world environment as far as we are able. This 
is tricky, but we MUST show that we have tried. That will ensure that IETF 
is exonerated from any legal flak later. We are in moving towards 
shark-infested waters with no cages at present.

Adrian Pickering/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Sep 2000 11:09:07 -0400

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.
>
>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.
>
>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 09:00:27 -0700

Ben, I have to respond on two subjects here -
Nobody is asking the IETF to be a COP or to do squat about actually
enforcing laws; but for PKIX in particular to continue to develop protocols
that do not take into account that there may be some legal precedent or
issue with the use of its Protocols, then PKIX is negligent, IMHO and
unfortunately so would its members and management be in my opinion if they
did nothing about this.

Bluntly - If you knowingly say "that is not important to me as I only design
the process model", then when that process model gets blown out  of the
water by an auditor, we collectively look pretty stupid.

What is PKIX's problem with realizing that it has a responsibility to the
community it serves, and that has nothing to do with its members? The
reality is that the pace in the PKI world is now starting to pick up to the
point where things are going to get mooshed, and bluntly we can save
ourselves a lot of effort and worry about end use applicability and
requirements by just adding the Applicability Documents to our efforts. This
is part of enabling the people that use our work to make determinations on
its applicability - unless that is not what the IETF or PKIX as a collective
wants...

As to the need for two grades of time. One is simply plumbing and the other
is the water that flows through the pipes. Much care is already given to
authenticate digital entities and any auditor will tell you that if that
much care is placed on authenticating abstract data like "Who" then the
"When" deserves the same or better.

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

> > > >      What I want to do is to start a process of formally defining
what
> > an

---

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

Steven - group ----> Let me try again.

    1)    The issue is that many of our systems address time as though it were part of the control infrastructure and we ignore the need to provide proofing as to what the time data is and where it came from - Does that answer this comment?

    2)    We are building many protocols that provide a layered framework for building transaction services and processing. In fact that the X509 Digitally Signed Documents now automatically have legal consequence here in the States, in my mind opens a whole new realm of requirements for us to have to take into account.

Does this explain what I mean?

Todd
  ----- Original Message ----- 
  From: Stephen Kent 
  To: todd glassey 
  Cc: [email-masked] 
  Sent: Wednesday, September 13, 2000 8:09 AM
  Subject: Re: The need for two grades of time data.

  Todd,

  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: Rich Salz <[email-masked]>
Date: Wed, 13 Sep 2000 12:41:05 -0400

> we ignore the need to provide proofing as to what the time data is and
> where it came from

This makes sense.  It also reinforces my belief that it doesn't belong
in the IETF any more than proof that IBM.COM really is, IBM. :)

> In fact that the X509 Digitally Signed Documents now automatically have
> legal consequence here in the States, in my mind opens a whole new realm
> of requirements for us to have to take into account. Does this explain
> what I mean?

They don't automatically have legal consequence; they lost the automatic
non-legal status.  That's a big, but apparently subtle, distinction,
that yet again shows why evidentiary issues are beyond our ken.
	/r$

---

From: "todd glassey" <[email-masked]>
Date: Wed, 13 Sep 2000 10:00:22 -0700

Rich I still disagree with you and pretty strongly too -
----- Original Message -----
From: "Rich Salz" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 13, 2000 9:41 AM
Subject: Re: The need for two grades of time data.

> in the IETF any more than proof that IBM.COM really is, IBM. :)

Except that what you are now talking about is operating the trust process
rather than architecting it, and of course the IETF is not a commercial
trust provider. That goes without saying. the issue here is in architecing
systems that do not support the needs of current and obviously emerging
laws, standards, and BCP models, and since we set so few of those in the
Techno Puratory of the PKIX WG we ned to be aware of them above us. Heck,
even the forges of the underworld took input from Zeus.

> non-legal status.

Sure they do. Anything I sign with my Digital Cert is represented as my wet
signature under the law . Making it essentially  a legal instrument of my
agency. That's just the way it is.

>That's a big, but apparently subtle, distinction,

No not true. It shows why its so important for our second-tier processes,
protocol models, and BCP's to be so closely tied to what is applicable. As
to the core tier one standards they rely on, that is another issue.

Todd

---

From: Rich Salz <[email-masked]>
Date: Wed, 13 Sep 2000 13:31:17 -0400

> Rich I still disagree with you and pretty strongly too -

Apparently so. :)   I'm hoping this will be my last note on this topic
-- it's probably time for the rough consensus to take over.

> Anything I sign with my Digital Cert is represented as my wet
> signature under the law

Anything?  No.  There can be a whole bunch of important exceptions (Sec.
103), and as I read the "consent" sections -- it's only equivalent to a
wet signature if I agree to accept it, or be bound by it when signing to
you.
Again, I only make these points to show out out-of-scope these
conversations are, here.  Feel free to rebut away; I'll remain silent.
:)

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.
	/r$

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Sep 2000 18:38:48 +0100

> same as "who signed the cert binding the name to the key"?  Again, not

Now I'm confused. We provide a mechanism by which that can be
ascertained. Of course, we don't care who, in particular, it is, but we
do care that that can be determined, don't we?

Cheers,

Ben.

---

From: J Adrian Pickering <[email-masked]>
Date: Wed, 13 Sep 2000 18:54:01 +0100

>do care that that can be determined, don't we?

We should. We should ensure that the technical support for this is as best 
as it possibly can be. Take care with that word 'who'. TSA's are automatons 
and will probably grow to stamping millions of transactions per hour, all 
potentially of legal significance.

To repeat Bob's statement:

'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?"'

1. What time is it? - there are technical fixes for this (but be aware of 
Bob's chronometer story!)

2. Who says so? - we have to trust the TSA's signing. However, who 'is' the 
TSA and who (i.e. what human) is going to vouch for its proper operation? 
Who manages the TSA's certificate? Probably some system that also features 
a PKIX time stamper...

3. Why should anyone believe them? - beats me. My reading of the US Rules 
of Evidence leads me to believe this is going to be very tricky. It'll also 
be so in the UK, especially in criminal cases.

Adrian Pickering/
ECS, University of Southampton, UK

---

From: "todd glassey" <[email-masked]>
Date: Wed, 13 Sep 2000 15:16:50 -0700

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,

Todd,

Steve

Todd,

Regards,

Denis

(snip)

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Sep 2000 14:11:35 -0400

Todd,

>     1)    The issue is that many of our systems address time as 
>though it were part of the control infrastructure and we ignore the 
>need to provide proofing as to what the time data is and where it 
>came from - Does that answer this comment?

No, it does not.

>
>     2)    We are building many protocols that provide a layered 
>framework for building transaction services and processing. In fact 
>that the X509 Digitally Signed Documents now automatically have 
>legal consequence here in the States, in my mind opens a whole new 
>realm of requirements for us to have to take into account.

I don't believe this is an accurate characterization of current law 
in the U.S., by a long shot. According to current law, I believe that 
a lot of this that are divorced from digital signatures and the X.509 
PKI model have legal standing, and many things that are based on 
these standards do NOT automatically have such standing. So, this is 
a vast oversimplification.

>Does this explain what I mean?

Not really.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Sep 2000 14:22:14 -0400

Todd,

>even the forges of the underworld took input from Zeus.

By Jove, this is hard to parse! Note that PKIX also has not chosen to 
generate a set of standards for CA operation, defining different 
grades of "trust."  A BCP is out of the question at this point, 
because there is insufficient experience to generate such a document 
for a TSP.  It might be called a BCS (Best Current Speculation), but 
the IETF does not publish BCS's.

>agency. That's just the way it is.

No, it's not. I sign authentication challenges with a private key and 
there is no legal (NR) implication associated with that.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Sep 2000 15:35:17 -0400

Todd,

>needs. As it sits now it is too closed and restricted.

I.e., it does not support the model you proposed.

>proofing model. Might as well be human testimony.

The use of a TTP as a basis for time stamping is consistent with the 
use of a TTP as a CA. In each case, clients evaluate the policies and 
procedures employed by the TTP and decide if they are sufficient for 
the application context of interest. there is no single, right set of 
policies and procedures that is adequate for all applications, and 
thus we leave it to the clients to decide what is good enough in each 
case.  A government may choose to establish minimum criteria for TTPs 
to operate WITHIN ITS JURISDICTION, but that is outside the scope of 
what the IETF does.

>Your included text starts here

Yes, it was, and we're past that point.

<snip>

I'll cut to the chase, for those who may have trouble deciphering 
what Todd is saying.

Todd's model calls for a secure, highly accurate time stamp device to 
be inserted into every workstation that generates a document that 
needs to be time stamped.  The device, if one has confidence in it 
and the system by which it receive its time source, provides the 
"authenticated" time source that Todd alludes to. Todd has been 
affiliated with a company that manufactures a device which meets the 
criteria he has established. TSP does not encompass this model, hence 
the problem.

I don't mean to pass judgement on the model Todd espouses, or on 
devices that implement it. However, the model that TSP supports is 
one that has been discussed in the literature for at least 15, maybe 
25, years, and which is very widely accepted. It is a simple one, 
that appears to be free of IP claims at this time, although certain 
implementations of a TSA might be covered by patents.

Most folks I have spoken with do not believe that most business 
transactions require extremely precise time stamps, accurate to a 
millisecond. Most folks I have spoken with do believe that the TTP 
model encompassed by TSP is sufficient for most business needs. Most 
believe that a TSA will be able to employ a set of mechanisms to 
ensure reasonable accuracy and protect against undetected tampering 
with the clock, so as to convince clients that it is reasonable to 
rely on the TSA.  Some means of doing this may be patented, other 
probably are not. The market will decide what's good enough, and the 
courts will eventually decide if the market got it right.

Note that in many business contexts, the adequacy of information 
security measures, with regard to legal liability, is determined not 
on an absolute scale, but based on what is common, accepted practice. 
So, if most businesses use NT as a platform for hosting a security 
sensitive application, you are not legally negligent for doing so, 
even if security experts point out that there are better choices. In 
that light, the TTP TSA model, if accepted in the marketplace, may 
well become a definition of "good enough."

Steve

---

From: "todd glassey" <[email-masked]>
Date: Thu, 14 Sep 2000 12:35:11 -0700

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "Ben Laurie" <[email-masked]>; "Rich Salz" <[email-masked]>;
<[email-masked]>
Sent: Thursday, September 14, 2000 11:27 AM
Subject: Re: The need for two grades of time data.

> We seem to be talking past one another here.  You suggest that PKIX
> develop protocols that take into account laws and legal precedents.

No I do not.

Thats the breakdown between what I am saying and what a number of people are
hearing. Let me try again, I suggest that PKIX not build protocol that the
legal or audit people have to declare publically brain dead or worse,
commercially of less use than we would all like them to be.

The issue here is that PKIX is moving into the realm of applications level
decision support instead of core crypto enablement, and with this there are
the use mdoels that the real world mandates.

> I
> maintain that, for the digital signature environment, the laws are
> fragmented along national lines and we have no significant body of
> case law from which to draw inspiration.

Stop this here. We are not talking about settinglaw or policy here in the
IETF we have legislature and Government for that. What we are talking about
is not building technologies that do not answer any particular need in the
user community.

> Since the IETF does not want
> to create standards that are parochial, and because there is
> considerable variation here, it seems appropriate to NOT tailor our
> work to any existing body of regulations.

Or likewise find that our work is invalidated because of existing ones.

> Don't speak for the Wg as a while when you say that :-).

Steven You are the chair here with Tim and what you say carries a lot of
weight. Lets face it.

> I have to be blunt here too. What really seems to be going on is that
> you have previously proposed a time stamping model that is not
> congruent with what the WG has decided to standardize via TSP. Denis
> alluded to this in his message about BERT, which this WG rejected
> over a year ago, and which was rejected by the STIME WG as well. Your
> most recent response to Denis confirms this.
>
> Let me clarify, in my role as co-chair: the WG rejected BERT.

No it did not. You and one or two others specific to this argument made that
decison and the Archive clearly replays this to anyone that looks. There was
never a Poll taken anywhere. Lets get that straight.

If anyone has any concern regarding that, they might want to look it up in
the archive. I chose at that time to not argue with the management of the
WG. Now that the same draft is stuck at the Standard's Gate its time to
speak up.

> This analogy is opaque to me.

What does this mean, that you do not understand that time as content
deserves the same contextual processing that other evedentiary content does?

Or is it the physics issues of how to deploy and audit the deployment of
time, or that time data's syncghronicity with a National Timing Standard and
being able to prove so some time in the future through a imple mechanical
process. What is it that is opaque?

---

From: "todd glassey" <[email-masked]>
Date: Thu, 14 Sep 2000 12:49:05 -0700

Stephen - Response inline below.

SNIP

> >trust provider.

What I meant is that the above example was particular to the operations of a
Trust Business model rather than the process of designing one which is what
I thought we were up to. That is the stating that IBM.COM is actually
IBM.COM is part of a real worlds operations process not a technological one.

> > That goes without saying. the issue here is in architecing

I was watching the Baron von Munchahusen the other night and thinking to the
Uma Thermond scene where she is dancing away with the Baron while Lucifer is
getting madder and madder on the floor. That is the source of this analogy.

> the IETF does not publish BCS's.

I apologize. My thoughts get jumbled sometimes.

> >  > > legal consequence here in the States, in my mind opens a whole new
realm
> there is no legal (NR) implication associated with that.

Yes it is  - and I think you are dead wrong here - The document still has
your legally binding signature process attached to/on it. If the document is
not a one of Legal Conveyance, i.e some instrument, then the signature holds
no more importance than the signing of this note, but if it were a contract,
then the same signature would be evidentiary in form and binding.

The point is that anything signed with a DS now has the potential of being
legally binding in a contractural manner and that also needs to be taken
into account with the TS Protocol.

---

From: "todd glassey" <[email-masked]>
Date: Thu, 14 Sep 2000 13:38:42 -0700

Stephen,
One simple and elegant solution would be to change the name from "The PKIX
Time Stamping Protocol" to "The PKIX TTP Time Stamping Protocol", and allow
other TS protocols that are not TTP in nature to progress as well.

By the way, If the response is no because we only need one TTP protocol the
TSP protocol itself violates that rule. NTP has offered its uses timestamps
and many people have used the NTP protocol for timestamping for years. What
this means is that are production systems relying on discreet NTP TST's for
their validation and this has been going on for at least 8 years that I am
aware of.

And now that the old-hat NTP 3.x symmetric crypto has given way to the PKI
based AutoKey, as in the additions recently filed by Dave Mills against his
NTP 4,0 Standard, the facility offered by the generic NTP 4.0 PKI Server
does most if not all of what the TSP wants to do and it authenticates the
time source. Oh and the real win is that there are already tens of millions
of NTP instances deployed out there and whether the PKIX group likes it or
not its the way it is. So Unicast Timestamping with NTP is something that
has been available for years but in a somewhat undocumented state.

My point is that there is already one fully entrenched TS enable protocol
that has successfully had global deployment accomplished for it.

PKIX might want to take that into account.  The concept that by rolling the
rev levels of NTP in every Cisco Router magically becoming a timestamper
capable of legally binding marques.. seems to me to be the real win for
timestamping.

Just my two cents

Todd

---

From: "todd glassey" <[email-masked]>
Date: Thu, 14 Sep 2000 17:24:17 -0700

Stephen and group -
----- Original Message -----

SNIP

> has been available for years but in a somewhat undocumented state.

I want everyone to understand that I am not trying to be a jerk here, I
probably should have used more benign language - I just think that with the
sheer number of NTP Servers out there already, that NTP as a common
timestamping system may actually make a lot of sense and PKIX might not be
able to stop its use to focus favor on the TSP. That's all.

T.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Sep 2000 09:46:09 +0200

Todd,

> I myself  would support advancing the TSP Draft to Standard 

You are a little bit ahead of your time. BTW, which time reference
are you using ? :-). We are not advancing the TSP Draft to
"Standard", but to "Proposed Standard". It can only be advanced to
"Standard" once it has reached the "Proposed Standard" status and
when other conditions apply.

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.

> if it allowed
> for multiple use models, and updating to address emerging and audit driven

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Sep 2000 10:31:00 -0400

Todd,

NTP is a time distribution system, but not a time stamping system. 
Looking at the latest NTP security draft from Dave Mills, the 
services offered by NTP have not changed in this regard.  Thus a TSA 
might choose to employ NTP, but it need not do so. TSP is flexible in 
allowing a TSA to choose the method(s) that it employs, and in 
allowing the market and the legal system to decide which methods are 
appropriate.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Sep 2000 11:00:57 -0400

Todd,

>commercially of less use than we would all like them to be.

We agree on this goal.

>the use mdoels that the real world mandates.

There is considerable literature to suggest that the TTP TSA model in 
the TSP spec is adequate.

>is not building technologies that do not answer any particular need in the

You maintain that the model upon which TSP is based is inadequate to 
meet the needs of NR support. I see little or no evidence to 
substantiate this claim. Your messages contain vague references but 
nothing concrete. If you provided text from some regulation and show 
how the proposed technology was inadequate, that would be a start. 
However, the laws associated with NR are fragmented and not yet 
tested in courts. So, even if you were to find one such instance in 
some NR regulation, it would not prove that the TSP model is 
generally inadequate.

<snip>

>process. What is it that is opaque?

The opacity is a result of your choice of language, e.g., "time as content
deserves the same contextual processing that other [sic] evedentiary 
content does."

Steve

---

From: "todd glassey" <[email-masked]>
Date: Sun, 17 Sep 2000 11:15:54 -0700

Actually Stephen, irrelevant of the intent of the original design the NTP
protocol works wonderfully as a time stamping source and movement transport.
This is exactly my point. From an audit model perspective NTP has been there
and has been doing this duty for years, and as valiant as it is, the
industry already has tens of millions of NTP instances deployed and that
also is part of the point I want to make here.

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 15, 2000 7:31 AM
Subject: Re: The need for two grades of time data.

> NTP is a time distribution system, but not a time stamping system.

Maybe by how it is used, but that just aint true with regard to its
functionality. Time data, via NTP or ACTS, is moved about in the form of a
token or data stream. After receipt it is processed to produce the component
data by the application that receives it. In exactly those terms it is a
timestamping system. Sign and upload your identity and you get back a server
signed response token showing the both of you together. How cozy. Add the
Client Side Time and you have a Differential Stamp showing Delta T between
the two systems. Put this token into a DB of tokens and you have a TS DB
System.

My point here again is that this is identical in mechanism to the TSP, the
question is whether the process' intention was to set the OS level Clock
and/or to create some evidentiary mark with the data it got. In the case of
the new NTP, it can do both. What NTP does not provide that the TSP API does
is the ability to validate the internal components of the marque (TST), but
that
is really just a use specific service API. So this could easily be added at
the Application Level since the NTP Tokens are so well received globally.

By the way, NTP generically does do something critical for a TSP (IMHO) that
the TSP does not do and that is to Log its Data to the Local System's
Logging Instance whatever that is. Although this is a functionality that is
really added in the implementation of the protocol as a client/server
rather than in the core protocol, still it is a formal part of the BCP for
using NTP and that is something that the TSP clearly does not have. Myself,
I think this was an oversight in the functionality of the TSP system, but
what the hey, a simple App. Desc. might have solved this.

Not that I am suggesting  scrapping the TSP as I have said many a time, but
it is important to realize that there are other protocols out there that can
and will perform this task as well, and unless PKIX intends to do more than
just enact a standard and wait for the world to come to it, with this new
PKI ability in NTP, my feeling is that it will be too easy to do exactly
what the TSP does with NTP. Admittedly through a different API and process
flow but the end result I think is actually a better stamp. Not only is the
token structure already compliant with millions of environments it clearly
can talk about the time data itself. Something else that the TSA/TSP cant do
yet.

> allowing the market and the legal system to decide which methods are

Steve, the TSP is essentially an API of services for managing and producing
marques, yes? So then it could easily convert those API Services  to NTP
service calls and then the TSP would work layered on the New NTP.  Hmmmm.
New Product Idea here. Put the TS Token into the Client-Uploadable Payload
for the NTP Stream and viola Timestamper and OS level Time Management in one
clean environment.Use the API as an extension to manage the specific
components/contents of the tokens itself.

Anyway - trying to fight something that is already ubiquitously deployed
seems a bit feeble as well to me. But what they hey, what do I know?

---

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

Todd,

>other TS protocols that are not TTP in nature to progress as well.

We can consider this change, if there is adequate support for it.

>their validation and this has been going on for at least 8 years that I am

NTP does not provide secure time stamps in the sense we're talking 
about.  The latest NTP document from Dave Mills is clear about the 
security services it tries to offer, and the goal is not NR.  My 
reading suggests that digital signatures are employed in his protocol 
only hourly, to authenticate values that, in turn, are used to 
provide quick authentication of individual time values. Each 
individual time value is protected by a MAC computed using a sequence 
of keys that are part of a hash sequence, analogous to s-key.

>has been available for years but in a somewhat undocumented state.

Your use of the term "timestamping" here is not consistent with the 
NR-supportive use that we're debating. It is not equivalent. Perhaps 
what you mean is that one can develop another approach to time 
stamping using authenticated NTP as a basis. That option is available 
to TSAs.

>capable of legally binding marques.. seems to me to be the real win for

Given the security management typically afforded to routers, this is 
indeed a comforting thought :-).

Steve

---

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

> We can consider this change, if there is adequate support for it.

Thanks Stephen - Hi all. I would like to amend the name of the Current TSP
Draft now queued for Draft Standard Status to indicate that the TSP Method
only works as a TTP. Does anyone have a problem with this, and if so could
you ring me up to speed on it?

Todd