Re: Timestamping Standards.

["Michael Duren" <mike@xxxxxxxxxxxxxxxx>]

Denis,

Why don't you address Todd's proposed issue as it was stated?  Can we at
least have a discussion regarding the scope of the spec and Todd's
recommendation to consider industry requirements?

Do you think that the current timestamping definition meets the needs of the
OATS requirements?

Should it meet or attempt to address those requirements?  If not, should the
IETF address this in any way?

Are there other industry requirements that should be considered?

Is this within scope of this timestamping effort?  If not, where is the
scope of this standard stated.  If so, what are some other suggestions for
these addressing industry requirements?

What does the group think?

We touched on the scope issue at the Oslo meetings, but the group has not
discussed it since then.


Mike


-----Original Message-----
From: Denis Pinkas <Denis.Pinkas@bull.net>
To: Todd Glassey @ GMT <todd.glassey@www.gmtsw.com>
Cc: ietf-pkix@imc.org <ietf-pkix@imc.org>
Date: Wednesday, November 03, 1999 11:17 AM
Subject: Re: Timestamping Standards.


>Todd,
>
>My comments are in line.
>
>> 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.
>
>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
>> 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
>>
>> ----- Original Message -----
>> From: "Denis Pinkas" <Denis.Pinkas@bull.net>
>> To: "Todd Glassey @ GMT" <todd.glassey@gmtsw.com>
>> Cc: <ietf-pkix@imc.org>; <robert.zucceratto@entrust.com>
>> Sent: Wednesday, November 03, 1999 01:10 AM
>> Subject: Re: Timestamping Standards.
>>
>> > > 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,
>> >
>> > 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
>> >
>> >
>> > > Todd Glassey
>> >
>