Subject: Timestamping Standards.

From: "Todd Glassey @ GMT" <[email-masked]>
Date: Tue, 2 Nov 1999 14:11:45 -0800

Hi all,  in the Timestamping services drafts there might want to be a
mention of the only standards regarding timestamping currently on the books
today, because the may change some of the focus in this effort.

They provide for a requirements to provably timestamp within three (3)
seconds of UTC and these are of course the NASD OATS requirements. NASD for
thos that are unaware is the NAtional Association of Securities Dealers and
any solution that is proffered as a timestamping one for commercial purposes
should ought to fulfill the only mandate on the books today. To get more of
this try the OATS pages at the www.nasdr.com site.

I suggest that to satisfy OATS, several use-specific assumptions have to be
made like the timestamping system itself has some provable connection to a
"reliable" source of time, and the audit model to prove that the time
setting instance at the client end was accomplished appropriately, and that
these assumptions should be spelled out i detail in the Draft

Any comments?

Todd Glassey

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Nov 1999 10:10:08 +0100

> these assumptions should be spelled out i detail in the Draft

Todd,

The draft says:

" 2.1. Requirements of the TSA

The TSA is REQUIRED:

     1.  to provide a trustworthy source of time."

To this respect there is no need to *prove* anything else. Any
additional information from the TSA may be carried back in the
security policy.

Denis

---

From: "Todd Glassey @ GMT" <[email-masked]>
Date: Wed, 3 Nov 1999 07:47:43 -0800

Denis, Robert - here we are again, disagreeing on the Time Stamping
Protocols.

OK, if I agree to drop these issues, can I/we add an appendix or supplement
to the current draft that contains a BCP model for maintaining the Clock
Timebase. This of course would be at the OS level, that is below the TS
Protocol that would be use-model compliant with OATS requirements.

This would satisfy me and would allow the process to continue with this
status-quo.

Also this addition would address the need for this BCP Model in the 'Road
Map' as well, and eliminate the need to address this further for any other
of the protocols being forged in the furnace of PKIX or its related WG's.

Bluntly, this appendix could be a recommendation for timebase management in
all PKI or IETF Operating Models.

Todd

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Nov 1999 17:17:09 +0100

Todd,

My comments are in line.

> Timebase. 

Strange kind of bargain ...  :-|

Anyway the decision is not on us, but on a working group consensus.
It still appears that they are only two, may be three ?? people in
this working group supporting this idea. This does not form a
consensus. Since the Washington meeting is now very close, I propose
that we do not use the bandwith of the PKIX mailing list and discuss
this either at the PKIX meetings and/or in the corridors.

Denis

> This of course would be at the OS level, that is below the TS

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Nov 1999 22:46:55 -0500

Todd & Mike,

>all PKI or IETF Operating Models.

After the last IETF meeting I spoke with one of the security area directors
briefly, to discuss the question of BERT and similar time stamping issues.
There was agreement that tmost aspects of the proposals that you have put
forward are outside the scope of what we need to do in the PKIX
environment, given the long standing model for TSAs and a desire to not
impose constraints on how a TSA chooses to maintain its time base.
Moreover, there was agreement that the STIME WG provides a suitable
Internet standard for time representation, if we wish to refer to formats
consistent in the IETF arena.  Since I stated at the last meeting (and
reported in the minutes) that the WG chairs would consider the question of
whether BERT was within scope, and based on the feedback from a security
AD, I have decided that, going forward, PKIX will not address the
definition of a time token representation ala BERT or analogous proposals.

In the last couple of months, Todd proposed creation of a separate WG for
this sort of task and if the IESG agrees, one can be established.  However,
from now on, PKIX will not devote additional resources to this topic.  It
has not been an accepted work item, and enough time has been devoted to its
consideration for us to decide against adding it.

Steve