Subject: Re: Draft on TimeStampedData

From: Tilo Kienitz <[email-masked]>
Date: 31 Aug 2007 12:06:00 +0200

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.

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

---

From: "Julien Stern" <[email-masked]>
Date: Fri, 31 Aug 2007 13:42:38 +0200

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

Regards,

--
Julien

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 14:20:41 +0200

To accomodate for RFC 4998, I would propose the following syntax:

TimeStampedData ::= SEQUENCE {
	version			INTEGER { v1(1) },
	fileName		UTF8String,
	mimeType 	 	PrintableString,
	content		OCTET STRING,
	evidence		Evidence
}

Evidence ::= CHOICE {
	timeStamps		[0] SET (SIZE(1..MAX)) OF TimeStampToken,
	evidenceRecord	[1] EvidenceRecord -- according to RFC 4998
}

(I am not sure whether it would be better to use explicit or implicit tags...)

Regarding the idea of having an URI instead of a filename: I'd prefer to think over things a little bit more, and maybe collect more feedback.

In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scenario, then I do not want my company's hostnames and pathnames to be included in the envelope so that the recipient can see them.

Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Julien Stern
Inviato: venerdì 31 agosto 2007 13.43
A: [email-masked]
Oggetto: Re: Draft on TimeStampedData

On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
> > 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).
> 
> 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.

Regards,

--
Julien

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

---

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 31 Aug 2007 17:39:29 +0200

At this point I am a little bit puzzled.

The timeStamps choice is a SET OF, so it is not a ContentInfo instance; and therefore it has no Object ID to distinguish it from an EvidenceRecord. And neither this latter is a ContentInfo. So I am not sure what you mean.

If you are suggesting a different syntax, would you please specify the syntax you have in mind?

Adriano

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

> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scen…
I have no objections to your inclusion of RFC 4998 evidence record as a binding choice.  But, does it address Steve's proposed compromise regarding dictating RFC 3161 as a MUST TimeStampToken?  The evidence record in RFC 4998 does not dictate those terms.

With Steve's compromise in mind: Am I mistaken in my belief that the TimeStampToken in your original TimeStampedData SEQUENCE is actually a CMS ContentInfo and as such is already identified as to object ID?  If so, then would not further refinement of the TimeStampToken be superfluous?  Also, wouldn't interoperability be served in full, in that RFC 3161-only TSA's (TTP or private) should inter-operate as expected with Adriano's suggested syntax(es)?  Rejection of a TimeStampToken that a TSA doesn't understand is integral to interoperability.

Then I believe that compromise seems to be unnecessary since the syntax, including Adriano's new proposal, already achieves that which is desired by all?

Therefore, I believe that if I am correct in my above belief then mandating RFC 3161 is again superfluous and that RFC 3161 should be informative not normative, possibly strongly emphasized as in RFC 4998.  
CMS ContentInfo addresses interoperability very well.

---

From: Young H Etheridge <[email-masked]>
Date: Fri, 31 Aug 2007 11:48:10 -0400

Adriano,

To add to your thought processes:  I believe that a URI of 
"file:///private.stuff" addresses your concern for privacy of the 
physical URI.  But, allowing URI in the syntax will make less private 
repositories, not necessarily file systems, more universally 
accessible.  The intent of the URI in RFC 3986 is to also allow for 
abstractly identifying a resource, not necessarily providing a physical 
resource.  In this manner the URI could then be used as an object 
identity in database(s).

Take care,

yhe

---

From: Young H Etheridge <[email-masked]>
Date: Fri, 31 Aug 2007 11:24:06 -0400

> In my mind, I can send a TimeStampedData envelope to business partners and/or public agencies via email. If the timestamped document is a local one, which I think is a meaningful and realistic scen…
I have no objections to your inclusion of RFC 4998 evidence record as a 
binding choice.  But, does it address Steve's proposed compromise 
regarding dictating RFC 3161 as a MUST TimeStampToken?  The evidence 
record in RFC 4998 does not dictate those terms.

With Steve's compromise in mind: Am I mistaken in my belief that the 
TimeStampToken in your original TimeStampedData SEQUENCE is actually a 
CMS ContentInfo and as such is already identified as to object ID?  If 
so, then would not further refinement of the TimeStampToken be 
superfluous?  Also, wouldn't interoperability be served in full, in that 
RFC 3161-only TSA's (TTP or private) should inter-operate as expected 
with Adriano's suggested syntax(es)?  Rejection of a TimeStampToken that 
a TSA doesn't understand is integral to interoperability.

Then I believe that compromise seems to be unnecessary since the syntax, 
including Adriano's new proposal, already achieves that which is desired 
by all?

Therefore, I believe that if I am correct in my above belief then 
mandating RFC 3161 is again superfluous and that RFC 3161 should be 
informative not normative, possibly strongly emphasized as in RFC 4998.  
CMS ContentInfo addresses interoperability very well.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 31 Aug 2007 19:21:09 +0200

1 - There is no need for tagging, since  contentInfo is a SEQUENCE.

2 - RFC 4073 allows

       ContentWithAttributes ::= SEQUENCE {
              content     ContentInfo,
              attrs       SEQUENCE SIZE (1..MAX) OF Attribute }

         So what prohibist to define an appropriate attribute that contains
         a time stamp, or, in fact just a ContentInfo.

     We would need some attribute defining the mime/type and filename
          as a hint, or reuse some exiting pkcs9 type.
     If one needs to time stamp some attributes together with some data
          then one would not have 'data' as an encapsulated content but
          ContentWithAttributes.