Subject: Re: Draft on TimeStampedData

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 30 Aug 2007 12:54:22 +0200

I welcome the proposal in principle and browsed through it.

The title of the document is "Syntax for binding documents with time stamps". 
However, its content is different: "Syntax for binding one document with time stamps".

This raises the issue whether the proposal should be limited to one document, 
or be extended to support more than one document. 

I would rather prefer the latter. To this respect there would be two options:

a) have a sequence of documents, and/or
b) have a (Merkle) tree of documents,

Other opinions ?

Denis

============================================================

>Dear all,
>
>I would like to submit to your attention my draft below, which addresses
>a very simple issue and proposes a very simple solution:
>
>http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-00.txt
>
>It's just a few pages, so you will not waste much time reading it.
>
>I am also attaching to this message the very small presentation I
>prepared for the July PKIX meeting (but failed to send it on time).
>
>I would invite those of you who are dealing with digital time stamping
>and time-stamped documents of any sort, to share your opinion about this
>proposal. I would suggest that it became a new working item of the PKIX
>group.
>
>Thanks in advance for any comments.
>
>Adriano

---

From: "Santoni Adriano" <[email-masked]>
Date: Thu, 30 Aug 2007 14:21:02 +0200

I actually meant to address one document, not a set of documents. 

After all, if a set of documents needs to be time-stamped as a whole, the N documents (or whatever mix of files) could be tar'ed or zip'ed or otherwise packaged together before the resulting package be enveloped as described in my draft.

Besides, I meant this an additional way to protect one "content" in the same vein of CMS. As CMS addresses one content at a time, and not N contents, and because my proposal inherits from the ContentInfo structure, I think we should not provide for multiple contents.

Another reason why I would rather not modify the syntax so to manage N documents, is because that would complicate processing by the "recipient" applications and make interoperability harder to achieve, without adding much of a benefit.

However, if your opinion is shared by enough people, I would adopt your option a).

Let's see what the others have to say.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Denis Pinkas
Inviato: giovedì 30 agosto 2007 12.54
A: [email-masked]
Oggetto: Re: Draft on TimeStampedData

This raises the issue whether the proposal should be limited to one document, or be extended to support more than one document. 

Other opinions ?

Denis

>Dear all,
>
>I would like to submit to your attention my draft below, which 
>addresses a very simple issue and proposes a very simple solution:
>
>and time-stamped documents of any sort, to share your opinion about 
>this proposal. I would suggest that it became a new working item of the 
>PKIX group.
>

---

From: Young H Etheridge <[email-masked]>
Date: Thu, 30 Aug 2007 15:06:42 -0400

I tend to agree with Adriano.  There are already various ad hoc 
standards for compositing several information resources into a single 
resource.  As Adriano has suggested in the draft, "tar" and "zip" are 
prime examples of archiving or compositing information collections.  
Furthermore, leaving the decision to the application as to the method of 
generating the information composite seems to be less restrictive, but 
still fulfill the apparent intent of the syntax.

However,  I suggest that the reference to RFC3161 should be extended as 
was the case in RFC4998.  RFC4998 more generally defines a 
standards-based Timestamp as:

> Timestamp: A cryptographically secure confirmation generated by a
>    Time Stamping Authority (TSA).  [RFC3161] specifies a structure for
>    timestamps and a protocol for communicating with a TSA.  Besides
>    this, other data structures and protocols may also be appropriate,
>    e.g., such as defined in [ISO-18014-1.2002], [ISO-18014-2.2002],
>    [ISO-18014-3.2004], and [ANSI.X9-95.2005].
Not restricting the Timestamp to be merely RFC3161 compliant will 
enhance the resilience of this binding syntax by allowing more than one 
variation on Timestamp.

Thanks,

yhe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Aug 2007 15:41:30 -0400

At 3:06 PM -0400 8/30/07, Young H Etheridge wrote:
>standards for compositing several information resources into a 
>single resource.  As Adriano has suggested in the draft, "tar" and 
>"zip" are prime examples of archiving or compositing information 
>collections.  Furthermore, leaving the decision to the application 
>as to the method of generating the information composite seems to be 
>less restrictive, but still fulfill the apparent intent of the 
>syntax.
>
>However,  I suggest that the reference to RFC3161 should be extended 
>as was the case in RFC4998.  RFC4998 more generally defines a 
>enhance the resilience of this binding syntax by allowing more than 
>one variation on Timestamp.
>
>Thanks,
>
>yhe

A very quick look at RFC 4998 (BTW, folks, don't run the letters 
"RFC" and the RFC number together. We do that in citations, but not 
in normal, written English.) shows it to be an informative reference, 
not a normative reference.  I general the IETF avoids normative 
references to standards that one has to pay to acquire :-).  Also, 
allowing for more types of time stamps does not facilitate 
interoperability; it requires support for more time stamp mechanisms, 
formats, etc. in interoperable implementations. yes, it is more 
"encompassing" but not necessarily preferable.

Steve

---

From: Young H Etheridge <[email-masked]>
Date: Thu, 30 Aug 2007 16:33:18 -0400

Stephen Kent wrote:
>> Furthermore, leaving the decision to the application as to the method 
>> of generating the information composite seems to be less restrictive, 
>> but still fulfill the apparent intent of the syntax.
>>
> A very quick look at RFC 4998 (BTW, folks, don't run the letters "RFC" 
> and the RFC number together. We do that in citations, but not in 
> normal, written English.) shows it to be an informative reference, not 
> a normative reference.  I general the IETF avoids normative references 
> to standards that one has to pay to acquire :-).  Also, allowing for 
> more types of time stamps does not facilitate interoperability; it 
> requires support for more time stamp mechanisms, formats, etc. in 
> interoperable implementations. yes, it is more "encompassing" but not 
> necessarily preferable.
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.

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.

yhe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Aug 2007 17:05:28 -0400

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Aug 2007 17:11:04 -0400

RFC 4073 shows how to use CMS when multiple documents need to be 
protected together.  As you say, ZIP and tar are other approaches.

Russ

At 08:21 AM 8/30/2007, Santoni Adriano wrote:

>After all, if a set of documents needs to be time-stamped as a 
>whole, the N documents (or whatever mix of files) could be tar'ed or 
>zip'ed or otherwise packaged together before the resulting package 
>be enveloped as described in my draft.
>
>Besides, I meant this an additional way to protect one "content" in 
>the same vein of CMS. As CMS addresses one content at a time, and 
>not N contents, and because my proposal inherits from the 
>ContentInfo structure, I think we should not provide for multiple contents.
>
>Another reason why I would rather not modify the syntax so to manage 
>N documents, is because that would complicate processing by the 
>"recipient" applications and make interoperability harder to 
>achieve, without adding much of a benefit.
>
>Da: [email-masked] 
>[mailto:[email-masked]] Per conto di Denis Pinkas
>This raises the issue whether the proposal should be limited to one 
>document, or be extended to support more than one document.
>

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 09:16:13 +0200

>>However,  I suggest that the reference to RFC3161 should be extended as was the case in RFC4998.  
>> RFC4998 more generally defines a standards-based Timestamp as:

Yes, I can also agree with this. I will modify the syntax so that more than one type of "evidence" (including an ER as per RFC4998) is supported.

Will post a modified syntax shortly.

Adriano

-----Messaggio originale-----
Da: Young H Etheridge [mailto:[email-masked]] 
Inviato: giovedì 30 agosto 2007 21.07
A: Santoni Adriano
Cc: [email-masked]
Oggetto: Re: R: Draft on TimeStampedData

I tend to agree with Adriano.  There are already various ad hoc standards for compositing several information resources into a single resource.  As Adriano has suggested in the draft, "tar" and "zip" are prime examples of archiving or compositing information collections.  
Furthermore, leaving the decision to the application as to the method of generating the information composite seems to be less restrictive, but still fulfill the apparent intent of the syntax.

>    [ISO-18014-3.2004], and [ANSI.X9-95.2005].
Not restricting the Timestamp to be merely RFC3161 compliant will enhance the resilience of this binding syntax by allowing more than one variation on Timestamp.

Thanks,

yhe

Santoni Adriano wrote:
>> http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-00.
>> tx
>> t
>>
>> I would invite those of you who are dealing with digital time 
>> stamping and time-stamped documents of any sort, to share your 
>> opinion about this proposal. I would suggest that it became a new 
>> working item of the PKIX group.
>>

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 09:26:03 +0200

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).

Adriano

-----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:
>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.

>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

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 31 Aug 2007 12:08:03 +0200

> protected together.  As you say, ZIP and tar are other approaches.
Adriano,

I think Russ is quite right. I interprete his message as: Try and look 
at RFC 4073 and see
whether you can use it. What is wrong with making a collection of the 
data an a time stamp?

In draft-santoni-timestampeddata-00.txt filename, mimetype etc are not 
part of the time
stamped data. There are cases where you want to have the content 
structured in some way,
e.g. indicate the mime type.
With RFC 4073 logic and similar to S/MIME usage of signedData you could 
decide to have a
Mime-wrapper, i.e. at least one metadata concerning the type of the data.

Peter