Subject: Re: Draft on TimeStampedData

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 3 Sep 2007 09:48:05 +0200

>On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>> 
>> Adriano,
>> 
>> > After pondering on this and other remarks, I cannot help but agree 
>> > with Steve.
>> > 
>> > My original and essential goal is that of facilitating interoperability
>> > in a currently unregulated field. If we allow for several "degrees of 
>> > freedom", than interoperability will be hampered from the beginning. 
>> > So I'd better stick to RFC 3161 for now. We could include support for 
>> > RFC 4998 Evidence Records later on, at the time when they become a 
>> > widespread reality comparable to RFC 3161 TimeStampTokens (which are 
>> > widely implemented).
>> 
>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
>> customers evidence records are a widespread reality already. 
>> A standardized way to put some data and their evidence record into
>> a single file would be useful.

>I strongly concur with this comment. Allowing the usage of ERS as
>well as simple timestamps would allow the TimestampedData to leverage
>all the work of RFC 4998 regarding timestamps instead of reinventing
>the wheel in the future.

RFC 4998 has already defined its own structure: ArchiveTimeStamp.
The need to expand the proposal to RFC 4998 has not been demonstrated.
Sticking to RFC 3161 will also allow better interoperability and maintain simplicity.

Denis 

>Regards,
>
>--
>Julien
>
>> Kind regards
>> Tilo
>> 
>> 
>> > -----Messaggio originale-----
>> > Da: Stephen Kent [mailto:[email-masked]] 
>> > Inviato: giovedì 30 agosto 2007 23.05
>> > A: Young H Etheridge
>> > Cc: Santoni Adriano; [email-masked]
>> > Oggetto: Re: R: Draft on TimeStampedData
>> > 
>> > At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:
>> >>>...
>> >>Agreed, w.r.t. normative vs informative.  The above quote from
>> >>RFC-4998 merely underscores that this draft should also suggest, 
>> >>informatively, that the choice of Timestamp should be one that meets 
>> >>the normative syntax for Timestamp and not specify that which is in 
>> >>RFC-3161.  Nothing gets broken by being less restrictive and generally 
>> >>more informative to the community-at-large.
>> > 
>> > I have to disagree with your conclusion. If we require 3161 time stamps in an RFC of the sort Adriano proposed, then everyone can parse them if they comply with the RFC. If the RFC says "insert the time stamp from any standard you want here, and just tell us which one you used" then we have a problem. A compliant implementation can generate data structures containing time stamps that other compliant implementations cannot parse. That's the sort of interoperability problem we try to avoid in the IETF.
>> > 
>> >>My notion of resilience does not mean "more encompassing" but that of 
>> >>providing the user community with choice and an enhanced safeguard 
>> >>against the possibility of the weakening of an algorithm.
>> > 
>> > Choices can be good, but they can create interoperability problems in some cases, like this one. Also, we have algorithm agility as a requirement in all of our work, so the second concern you cite does not seem to apply here.
>> > 
>> > Steve
>> 
>> 
>> -- 
>> Tilo Kienitz
>> SecCommerce Informationssysteme GmbH
>> Obenhauptstr. 5
>> D - 22335 Hamburg
>> Germany                                   http://www.seccommerce.de
>> 
>> 
>

Regards,

Denis Pinkas

---

From: Tilo Kienitz <[email-masked]>
Date: 03 Sep 2007 17:28:55 +0200

> RFC 4998 has already defined its own structure: ArchiveTimeStamp.

An ArchiveTimeStamp does not contain a document. It only contains
hashes of documents.

> The need to expand the proposal to RFC 4998 has not been demonstrated.

If someone wants to keep a document and its EvidenceRecord together 
in a single file, then the proposal will help him. 

Tilo