Subject: RE: Time Stamp: Usage of TDTs

From: [email-masked]
Date: Fri, 2 Jul 1999 14:43:23 +1000

Mike, I appreciate your prompt reply. I hope you did not have to stay too
late.

[MD]
>How do you prove that a TSA is time-accurate?  I don't see anything in the
>TST that allows this, just a signature?  Because the signature is valid,
>does that mean the time is accurate?  Can this only be solved by placing
>trust in a policy or by relying on out of band information?

[MZ]
Hopefully so. Otherwise why don't I just go direct to the NIST-operated TSA,
which I'm sure provides highly accurate timing?

[MD]
>At least with the proposed use of TDTs, the client can instantly verify the
presence and validity of the TDT information >and then resubmit or incidate
a problem right away.  The result of an audit or out-of-band information
regarding the
>accuracy of a TSA's clock may not be readily available.  However, I am sure
that a company that has a TSA with an invalid >clock will run out and tell
the world right away.
>(BTW, it has not been suggested that the TDA holds any authority over the
time of a TSA).

[MZ]
TSA, by definition, is a Trusted Third Party. It means that you trust its
signature, its policy, and its diligence in abiding to its policy. What
makes you trust TDA more then TSA? Having a guard over the guard is a
burglar's delight :)
However, I do agree that some kind of a standard audit body may need to be
defined and established (NIST-based?) This TSA-auditor would periodically
and randomly check TSAs and issue 'quality ribbons', which the TSA can
attach to its policy. Clients should be able to see the results of the
audits and to initiate an audit if doubtful about quality of TSTs.

[MD]
>Why is it unreasonable to include information in the Timestamping protocol
that allows clients to trace the time value in >the stamp to some timing
authority?  If the TDT can contain time values that are traceable to a
Timing Authority, then why >not define a protocol that allows those tokens
to be included in the timestamp?
>The TDT is an optional field.

[MZ]
a TSA IS a timing authority from the client's prospective, or at least it
should be viewed as one. And you do not use the TSA as a source of a precise
timing anyway. At least the initial intention was not so. 
The prime usage of a TST is to compare the time in it to something else.
Consider two possible scenarios:
1) comparing a TST to a high resolution time value (the bid entered the
system at 15'32.1.3'):
For such a system most likely a single TSA will be used, and it is more
important to know that the ordering of TST is correct (who was the first).
Having a TDT would not help there, as each clock, whatever carefully
synchronised with NTA, has its own resolution, preventing any precise
comparison.
2)comparing a token to some 'human' time ('A document existed at 15.00
yesterday').
I do not think that synchronisation with NTA is critical here.

I'm trying to see a business case when knowing how precisely TSA clock is
synchronised with the NTA is critical, or relevant, rather then satisfying a
curiosity of the users. Please, help me out.

Sincerely
MichaelZ

---

From: "Bill Lattin" <[email-masked]>
Date: Fri, 2 Jul 1999 07:59:16 -0700

MichaelZ,

I've inserted my comments in your response to Mike Duren below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 01, 1999 21:43
> To: [email-masked]; "[Denis.Pinkas"@bull.net]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Time Stamp: Usage of TDTs
>
snip

> which I'm sure provides highly accurate timing?

Lattin:  From my earlier email, certainly policy will be important to the
operation of all TSAs and TDAs.  Some applications will only require
agreement on policy at relatively local levels (between direct participants
and the TSA); others may require agreement on a broader scale and thus
require access to an NTA (e.g. the NASDAQ OATS application).  The OATS
application is one that supports both viewpoints being expressed here:
NASDAQ could run its own TSA, but it wants the time traceable to NIST - this
is exactly where the TDA would be applicable.  Again, I don't believe NTAs
will enter the TSA business - they could, but (i)governments typically
abstain from competition with corporations, and (ii) an NTA, whose business
it is to provide time, is unlikely to want to accept the liability and
perform the other operations associated with the TSA.

snip

> I do not think that synchronisation with NTA is critical here.

Lattin:  The primary problem the proposed TDT is solving is providing
non-repudiatable traceability of time information from a clock back to an
NTA.  It can enhance accuracy, but this is not its primary purpose.  If a
TSA is using GPS as its timing source, it may be very accurate, but from a
legal standpoint, that source of time may not be acceptable for some
applications which may require direct traceability of time back to the
issuing NTA.

>[MZ] I'm trying to see a business case when knowing how precisely TSA clock
is
> curiosity of the users. Please, help me out.

Lattin:  The business case is where traceablity to an NTA is required.  In
this case, a TSA without the capability to provide traceability to an NTA
would not be acceptable (e.g. NASDAQ OATS).  The proposed TDT will provide a
simple way to do this.

No one is disputing that local policy agreement may work for a variety of
applications- especially today, but there are also applications today that
require traceability to an NTA so a local trusted clock will not suffice.
PKIX is a forward looking standard.  As more commerce and business processes
are moved to the internet, the ability to provide a link to nationally
recognized time sources will be increasingly important - it will facilitate
agreement between disparate parties as to the time of an event.  Time can be
as local or as universal as we chose to make it.  The proposed TDT is a way
to make national time available to all local TSAs.

How about opinions from others on the list?  I know you're out there...:-)

Regards,

Bill

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 02 Jul 1999 18:04:52 +0200

Bill and others,

I am watching this thread.

As far as the need of PKIX is concerned, we trust that a given TSA will give the
time up to a given (good or bad) precision. If someone does not trust a given
TSA it uses another one that it trusts. There is no need for additional proofs
(such as TDTs) for "additional trust". The trust is indicated indirectly in the
policy included in the TST. Once again the *primary* use of a TSA in PKIX is to
compare the time indicated in the TST with the time indicated in a CRL (limited
to the granularity of a second with an undefined precision).

So the use of the information, provided by a TDA, does not appear to be relevant
in that case.

Currently we can include additional data from a TDA but I have not seen
argumentations for this. The idea is not to see if there *might be* a
possibility to use that additional information, but if there is a *strong need*
for it. If yes, what for ?

Denis

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 2 Jul 1999 11:58:27 -0700

Actually Denis I would disagree.

The source of time and its accuracy are critically important to the overall
believability of the actual event represented by the timestamp and
particularly to its portability. We coined a term at Coastek called a
Portable Trust Model and that is what the timestamp is intended to produce.
A clearly defined level of portability in the enent logging system or a
validatible control signal in some other automated process model.

With that said the real issue here is the timestamp, and then the
infrastructure that creates it (the timestamp) and these need top be
specific to the end use models... The current model as proposed just
"believes" that the timebase is accurate and that for me elicits the thought
of someone standing in Court 10 years later swearing that their BCP model
involved resetting the OS TOD timebase and that the time in the timestamp is
right becuase of this... As opposing Counsel in the matter my response would
have been something like "Ahahahahahahahah - this is patently ridiculous on
the face of it. Who audited the OS to prove that the OS TOD services were
secure, audited what else was running on that platform, what other
transactions and processes interacted with this one, etc etc etc."

The bottom line is that without a clean OS independent model, it is really
difficult to get beyond the "Well we said so, isn't that enough?" proofing
models and they just won't hold water in the courts of today let alone the
computing-savvy ones of tomorrow... No, I think that if this timestamping
technology is to be of any real commercial use it has to address the
requirements that the timeservices infrastructure be capable of being
subsumed into the Server Platform as an integral component of the Audit
system.

That's why we got Datum involved in this arena so that we could address this
requirement in a HW manner and get the flimsy OS-borne support models out of
the question as to the Veracity of the Timestamp Data. BTW, for me, the
issues of placing the certification data inline as to the timebase validity
and source are key to the records that are produced being viable in and of
themselves, and not dependant on a lot of uncontrollable human parameters or
the unsafe OS infrastructure that created them.

Sorry to throw oil onto a fire, but this issue of the sanctity of the
timebase is a core gating issue in the believability of the event it
references in an absolute timestamping model.

Todd Glassey

---

From: "Bill Lattin" <[email-masked]>
Date: Sat, 3 Jul 1999 08:02:00 -0700

Denis,

As I see it, the proposed TDT enables the operation of a TSA to be extended
to address markets that it otherwise could not.

Certainly usage of a TSA will be determined by policy, but policy alone will
not be able to promote a local source of time to one that is linked to NTAs
and back to BIPM (the international source of time) in France.  There will
be applications that require a TSA to have access to NTA time; local time
will not be sufficient.  I have given a current *real* example of such a
requirement.  The TDT enables this link to the NTA and BIPM in a secure,
auditable manner.

The TDT is optional.  If a TSA doesn't need it, then it won't use it.  For
those applications requiring NTA time, then the TSA will have an
IETF-standardized way to get it.

In thinking about this further, time distribution has already been solved by
policy - global policy that establishes BIPM as the true source of
international time and that describes how the NTAs will synchronize to it.
Governments have policies declaring NTAs as the sources of national time.
All we are trying to do is enable TSAs to take advantage of an already
exisiting, recognized system - one that local TSA policy and local TSA
clocks will never  supplant.

Let's keep the TDA section in the time stamp draft.  It has been well
drafted and we have shown a use for it that is far better than just
providing incidental temporal data such as stock market closing indicies.

Best regards,

Bill

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 09:05
> To: Bill Lattin
> Cc: [email-masked]
> Subject: Usage of TDTs
>
>
> Bill and others,
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 1999 09:55:14 -0400

Todd & Bill,

I think we are seeing some serious disagreements here, in part due to
fundamentally different assumptions about implementations and the role of
IETF WGs.

This WG, like all others in the IETF, develops protocols as a means of
specifying interoperability.  We don't develop implementation
specifications; we leave that to the implementors, so long as they achieve
the interoperability requirements of the protocols.  For example, the
security offered through the use of a protocol such as SSL, IPsec, or
S/MIME is heavily dependent on the quality of the implementation.
Moreover, when these protocols are implemented on top of an insecure OS, an
active attacker has a whole new set of opportunities to circumvent the
security offered by the protocols.  This is a valid concern, but it is
outside the scope of IETF standards.  (You can find informational RFCs on
operational and implementation security issues, but they are not standards.)

When you criticise the notion that a TSA can be relied upon by its clients
to provide accurate timestamps, and cite the insecurities of OSs, you have
stepped outside of the bounds of our WG charter, and of IETF standards in
general.  One could elect to implement a protocol supporting a TSA in a
dedicated device that is immune to these criticisms.  It is fair for us to
consider, in the course of protocol design, when we may do to facilitate
more secure implementation, without prescribing implementation details.
However, as a matter of policy, I would not skew a protocol design based on
any technology that gives undue advantage to any given vendor, e.g., based
on use of a patented technology, dominant market position, etc.

Steve

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 8 Jul 1999 09:29:20 -0700

Steve I agonized over responding here to you or not.

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 07, 1999 6:55 AM
Subject: Re: Usage of TDTs

> specifying interoperability.

You talk about Interoperability in your other responses to this commentary
too and I am wondering where the interoperability is in the many protocols
that you know have under your watchful care, Oh trustee of the Technology
Farm Project...

Again the reality is that we are still too early in the development and
evolutionary curve of PKI to be forced to address the issues of
interoperability. I liken it to still being "in the Summer of Love" with
regard to the evolutioon and deployment of commercially usable PKI.

> We don't develop implementation

Your responses above are based in a flurry of motion, much of which whould
have been directed at POISSON Efforts.  The POISSON Responses will be sent
under separate cover and cross posted to the POISSON List, that I just
posted.

> general.

So any criticism of the current Timestamping Draft is a criticism of the WG
Charter? - Right. Or is it a criticism of the OS Model itself. What is it
that you are saying here, "This Criticism is outside the scope of this WG,
leave these people alone..." or what?

Come on Steve, the reaility is that the lines between the stack, the
communications processors, and the virtual services interfaces that are a
part of every commercial OS are blurring to the point of nondistinction. If
you have any doubt try to "rip" the stack out of Oh say, Solaris 2.6 or
better yet 2.7, and see what happens. Thin clients are even worse.

and as to Interoperating with a timestamp, does that happen at the routines
that create the stamp or at the data structure of the stamp itself? My vote
is at the TSToken or Data Structure of the Stamp itself.

> One could elect to implement a protocol supporting a TSA in a
> dedicated device that is immune to these criticisms.

The issue is not whether you need a device to insure theat the OS borne Time
Services are what they claim to be, but rather what and how the timestamping
model works.

The model you are so many others are working on is based in the Trusted
Third Party Model entierly, and I personally think that this is not the type
of Timestamping that Industry will mandate. If it was, then Surity and
others would be rockin' on down to the bank to deposit their checks...

What people want in timestamping is a locally valid mechanism of creating
and verifying  stamps. If they are to be issued remotely, then the said same
system needs a listener and a daemon or somesuch if you need the TTP
functionality, but to base the protocol onto the TTP model itself is silly
and short-sided, IMHO.

The world is likely to want a mechanism to establish as much credibility for
a Timestamping Solution as possible, and that means that the entire solution
needs to be able to live on a single platform, i.e. with the app that is
going to use it. It also means that the stamping model needs to be as
complete, that is  self-contained, as possible, but the stamps have to be
small enough to put into a DB without too much pain. Also that they can be
lightened further for the Warehouseing Operators becuase most of them are
choking at the concept of a 511 byte stamp like we produce with the
"neutral" version of BERT. So what is really going on here?

But there is more - the issues with the timestamping model are more
rudimentry than is being dealt with. It really seems to me that the
timestamping protocol as suggested so far is trying to do knock-offs of NTP
and OCSP and some other services that are really not it's responsibility
either.

What the time services protocols shoud do is very simple:

    1)    Allow for the credible and audited depolyment of timedata to the
host systems as part of the timestamping process. Also that the source and
credibility of the stamps and their timesource are documented.

    2)    Allow for local OS Borne Timestamps to be built and validated
sapecific to some structure standards, like BERT or whatever.

    3)    Allow for the verification of the timestamps and their ESP's
through some mechanism

    4)    Run the timestamping model in local or remote models.

    5)    Have at least one prototypical logging model for the use there of
of #2-4 above

    6)    Create a recommendation for using certified time.

> It is fair for us to

That's good, and this says that the security model is a part of the totality
of the system, here again demonstrating that the protocol is not the
protocol itself but a key piece of a larger systems that needs to be
considered as a system itself.

> on use of a patented technology, dominant market position, etc.

So, what your saying is that as the Chair, you personally will not allow for
any hanky panky in the filing or promulgation of Drafts or their Concepts.
BUT that the drafts you support must reflect non-proprietary efforts.
Doesn't this violate the charter of the IETF. I seem to recall that I can
submit proprietary efforts and you just said that you wouldn't SKEW the
standards efforts to favor any of these. So what if there are no other
solutions proposed? - Steve what this sounds like to me is an invitation for
a lawsuit with the IETF named as the Respondant. Personally I think that
this is somethign that the IETF needs to protect itself better against but I
will take that up with POISSON.

I will end this response here but I will address your other concerns in the
Letter to POISSED about the global changes in the WG Chairs Responsibilities
as Trustee's Guarding the Technology Grist Mill.

These responses are my own personal issues -Standard Disclaimer, etc etc
etc, my company has already disavowed me anyway...

Todd Glassey

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 08 Jul 1999 10:10:39 -0700

>that you know have under your watchful care, Oh trustee of the Technology

Could we dispense with the name-calling? It does not help us come up with 
solutions.

If you are wondering "where the interoperability is", there are many 
sources of information. You can alk to the implementors. Bob Moskowitz 
recently posted a draft that covers testing of CMP interoperability. Peter 
Gutmann has posted many messages about interoperability (and severe lack 
thereof) in cert format. And so on.

>interoperability.

I cannot disagree with you more strongly. It is *never* too soon to aim for 
interoperability. If immediate interoperability is not your goal, the IETF 
is probably not your venue. There are many other groups that discuss how to 
do PKI without much care for interoperability; you may be happier there. 
Or, you may realize that such groups aren't getting real work done and 
change your attitude about the importance of interoperability.

The PKIX WG is not the place to argue about whether the IETF should care 
about interoperability.

>have been directed at POISSON Efforts.

I disagree here as well. Your followup messages haven't made it to the 
poised list (or to this one), so I can't speak of their content. But until 
the IETF makes a radical change in direction (and I sincerely doubt this 
will happen soon), quality of implementation work is pretty much out of 
scope. I say "pretty much" because sometimes there are changes that can be 
made to protocols that can make them less prone to mis-implementation, and 
sometimes there is good value to additional documents that give 
implementation advice. But those are generally side issues.

>Charter? - Right.

That's not what he said: re-read your own quote. There is nothing in the WG 
charter that says anything about operating systems.

>of Timestamping that Industry will mandate.

Then you should write a new Internet Draft with the different model in it. 
Start off with a set of requirements. Describe the current model and your 
model. Discuss how your model is different (not better than) the current 
model as you see it. If there is WG interest, your draft will be adopted. 
If you don't write the draft, then all we have to work from is some 
hard-to-read mail messages.

>If it was, then Surity and

This is completely irrelevant. Microsoft rocks bigger when they go to their 
bank: are you saying that their model is better? What happens when two big 
companies with different models both rock to the bank? Do our heads 
explode? This is why the IETF doesn't care about these types of arguments.

>any hanky panky in the filing or promulgation of Drafts or their Concepts.

No, he's saying something that many of us will completely agree with: 
protocol design should not be skewed to an encumbered technology if there 
is a different, reasonably good unencumbered solution.

>Doesn't this violate the charter of the IETF.

No; if you think so, please point out specific wording in "the charter of 
the IETF" that this contradicts.

>  I seem to recall that I can
>standards efforts to favor any of these.

Correct.

>  So what if there are no other
>solutions proposed?

Then it is up to the WG to decide whether or not to embrace the proposal in 
your Internet Draft.

>  - Steve what this sounds like to me is an invitation for
>a lawsuit with the IETF named as the Respondant.

Todd, do you think that making threats like this will make people want to 
adopt your proposals? Do you react positively when folks threaten you like 
this? I'd imagine not. The best way for you to get your ideas adopted is to 
write an Internet Draft, have it discussed on the list, and see if there is 
any interest.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 8 Jul 1999 13:25:32 -0700

Paul, exactly what in this comment is a threat?

Seems like you are focusing on shooting the messeger rather than reading the
messege.

> adopt your proposals?

So who is making threats here? - Certianly not me. Nowhere does it say "I am
going to sue you"...  What it does say is that as a Lay Person, that spends
a substantial amount of time around Counsel, that this is an issue. -
Nothing more - What I am concerned with is the sanctity and value of the
efforts that we as IETF Particilpants invest in the IETF process. So in
response to this acerbic retort of yours - I have to ask "Why is it that
you, IMC Directorate,  and the rest of the management of the WG's take
criticism of the current Modus Opeandi as a threat?".

> Do you react positively when folks threaten you like
> this?

Where is the paranoia coming from here? You hold a public office and are
subjetc to public review because of it. Sorry, that's just the way it is.

> I'd imagine not.

Can I assume that you are taking the 'pointing out that you and the other WG
Chairs might be vulnerable to legal attack' as a threat?. I am sorry that
this is your interpretation -  I thought it was an observation of a
potential threat to the sanctity of our communal process here. Something
that we need to address so it doesn't happen.

In particular Paul, in light of this clarification - What is your problem
with this concept ?

> The best way for you to get your ideas adopted is to

Paul, like I said in the commentary of both of the letters I sent out... I
am not interested in going to war with anyone over these issues, obviously
you included, but I believe that you're looking at issues down in the
basement and claiming that the current policies rooted in the attic cover
them, and IMHO you are dead wrong here.  The problem is that a good number
of the issues I have pointed out aren't totally out in the light and I think
that your response above is based in maintaining the Status Quo rather than
dealing with the issues at hand.

Or am I wrong here too?... If I am wrong, then I steadfastly apologize for
any consternation I caused in your life... But if I am right then you and
every other WG Chair owes me this debt as it does with every other IETF/IMC
participant, and that is a problem. Its in my mind exactly the thing that
you pointed out when you said that "things were not going to change" and
signed it with the IMC Directorate's Signature.... See - the reality is that
'things' as you put it,  have and are continuing to change whether you, I,
or anyone else likes it or not.

BTW, I personally find it offensive for you as the IMC Director to slam
people on the list. If you want to slam me - then use your own signature and
do it as a normal mortal., but keep the IMC clean.

Todd
<Standard Disclaimers Apply>

---

From: "Bill Lattin" <[email-masked]>
Date: Thu, 8 Jul 1999 19:22:47 -0700

Steve and Denis,

Sorry for the late response to both your emails, but I've been away from my
email for a bit (imagine that :-)).  The following is my response to both
your messages...

While Todd and I share some common concerns regarding information security
and its successful implementation, I do not want the debate about TDTs to be
lost in the forest.  My thread started with a better way to use the optional
TDT field and I would like to keep the spot light focussed brightly on the
need to keep the TDT in the existing draft.  So my thread continues....

In my thread, I am not at all discussing a specific implementation; rather,
I am concerned that the currently proposed time stamp protocol will be
modified to eliminate a useful component which can be used to convey
directly applicable timing information.  Further, if eliminated, then
interoperability will suffer since no standard definition would exist for a
TDT.

The proposed use of the TDT to distribute timing traceable to a National
Timing Authority (NTA) is one which has roots in current business practice,
but which has not yet been extended to the modern digital age.  The concept
of a TSA and its need for policy shows to me that the group is struggling
with this issue (among others).  I am not criticizing the notion that the
TSA cannot be be relied upon by its clients - I have affirmed local trust in
the TSA in prior messages; the problem is that without a link to the
National Time Authority, for certain applications, local TSA policy will be
insufficient - as it is today in the paper world.

Carl Ellison once told me that just as politics are local so is trust in
names, permissions and certificates (sorry Carl for the paraphrased quote).
I agree that this is the case with names, permissions, attributes, etc.  I
disagree that this is necessarily so with time.  The international community
has established a hierarchy for synchronizing clocks and agreeing on time;
if time were purely local, no one would have bothered with such a global
agreement.  It seems that the WG is ignoring this and trying to apply a
local trust policy, similar to that used for certificates, to that of time
stamps.  While this will work for many applications, it will not suffice for
all.

The argument for using the TDT to link a TSA to this national (and
international) timing hierarchy does nothing to diminish the quality of the
TSA; it adds to its quality and it enables the TSA to participate in those
applications that require links to an NTA.  This linkage to the NTA has not
been addressed in the current draft.

Many arguments have been raised by Denis against the proposed TDT.  He
suggested using multiple time stamps instead of the TDT.  While this
approach does add multiple witnesses as does the TDT, it does nothing about
providing a link to the NTA.  He has also suggested that if someone doesn't
trust a TSA, he should use another.  What if this person has an application
that requires a link to the NTA?  Without the proposed TDT, no TSA will
comply.  Denis has suggested that TSAs are sufficient with their variable
bits of accuracy.  We, again, are not talking about local accuracy, but the
ability to tie into the international timing infrastructure.  Finally, Denis
raised the issue that verification of the TST with a TDT will be much longer
and complicated.  I sincerely doubt this is the case - verifying PKIX
certificates will likely be far more complex, but this borders on an
implementation issue :-).

So, in closing, the TDT should be kept in the draft as a necessary component
of the protocol.  The issue we are addressing with the TDT is linkage to the
NTA - something that the current "local policy-centric" approach fails to
address.

Best regards,

Bill

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, July 07, 1999 06:55
> To: [email-masked]
> Cc: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jul 1999 14:08:04 -0400

Todd,

>that you know have under your watchful care, Oh trustee of the Technology

Vendors implement to IETF standards with varying degree of fidelity.  The
IETF has shunned developing explicit test criteria, although that could
certainly help.  Sometimes outside organizations get into the act and
arrange "bakeoffs" to facilitate interoperability testing.  This too is
outside the scope of the IETF.  We usually draw the line between local
implementation issues and interface issues, because the latter affect
interoperability and the former do not.  The assumption is that if we do
our job well, and if vendors implement correctly, then interoperability
will be possible.  The WGs don't always get it right, nor do the vendors,
but it generally works out pretty well over time.  if this is not the sort
of interoperability you're looking for, then perhaps you should look
elsewhere.

>regard to the evolutioon and deployment of commercially usable PKI.

The PKIX standards define protocols, data formats, and processing
conventions to facilitate certificate management for "PKI-enabled"
applications.  We want to do so in a context that permits applications from
various vendors, and CA products and serviecs from various vendors, to
interoperate.  To that end, it is not too early to be working on
interoperability.  Perhaps your definition of interoperability is more far
reaching, more application specific, and that's why you see a disconnect.

<deleted text, purportedly POSSION related>

>leave these people alone..." or what?

I am saying that the time stamping draft is based on a notion, stated
repeatedly by many other Wg members, that a TSA is, by definition, trusted
to provide an accurate time stamp function to its subscribers.

>better yet 2.7, and see what happens. Thin clients are even worse.

I would not disagree with most of this observation, but I also don't see
it's relevance to the discussion.  What I said was that implementation
details are usually not part of our standards work.  If you criticize a
standard based on your perception of how it is to be implemented, the
criticism had better be airtight, i.e., it ought to be based on a generally
agreed upon fundamental problem that will affect ALL implementations, not
one that arises only under certain implementation assumptions.

>is at the TSToken or Data Structure of the Stamp itself.

Not sure I understand the context of this comment.

>and OCSP and some other services that are really not it's responsibility

Essentially all of the literature on secure time stamping is based on the
use of a TTP as a TSA. The underlying assumption is that a locally
controlled TSA could be manipulated by those who have physical and
administrative control over it.  If this assumption is false, it must be
because of implementation details, which raises issues about standards
scope and perhaps bout vendor-specific technology.  The reason that PKIX is
the home for a time stamp protocol development effort is because we assume
that the protocol will make use of signatures and X.509 certificates, which
fall under the purview of this WG. if these assumptions are not true, then
we may not be the right WG for the activity.  However, when the WG was
asked to voice its opinion on this topic a while ago, the response was
positive.  Thus I plan that the WG will continue to develop time stamp
protocols consistent with these constraints.

>    6)    Create a recommendation for using certified time.

I see a serious disconnect here.  Most of what you describe above is a
secure time distribution service, not a secure time stamping service.  The
former is more appropriately the purview of a newly formed WG and you
should bring these issues up there.

>as Trustee's Guarding the Technology Grist Mill.

By all means fell free to discuss these issues on the POISSON mailing list.
I am quite comfortable with my stance on this matter. The IETF has never
viewed itself as a vehicle for vendors to receive standards endorsement of
proprietary technology.  We have had much more stringent constraints re
adoption of standards that involve patents, e.g., vs. the IEEE.

Steve

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 9 Jul 1999 17:01:03 -0700

Steve,
this is getting to long to hammer the entire list with. You and I clearly
see the world through different glasses and since I believe that you believe
what you are saying - as I do, that's OK.

----- Original Message -----
From: Stephen Kent <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Sent: Friday, July 09, 1999 11:08 AM
Subject: Re: Usage of TDTs

> Todd,

T.