Subject: R: R: Draft on TimeStampedData

From: "Santoni Adriano" <[email-masked]>
Date: Mon, 3 Sep 2007 10:41:32 +0200

Let me summarize the issues discussed so far:

1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)

In principle, I have no objections as long as we do not complicate things too much and do not hamper interoperability. 

There are at least two possible approaches to accomodate RFC 4998:

   a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
   b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;

In any case, it must be possible for the verifying application to easily detect which of the two (or more) kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.

In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is the most widely implemented type of evidence.

In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though certain applications may also support RFC 4998).

2) filename vs. URI 

Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is obviously true, but it implies that the 'content' field of TimeStampedData may be empty. This is not what I was addressing in my original proposal. It would not just require the 'content' field to be declared OPTIONAL: it would make interoperability very difficult to achieve unless we restrict the URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of the myriad possibilities. In any case, it would require ages of interoperability testing. And it would make life much harder for software implementors, without much of a benefit in view. I strongly believe in keeping things simple as much as possible.

3) multiple contents and RFC 4073

The 'content' field in the TimeStampedData envelope is not structured, in my original proposal. It is just an OCTET STRING. That allows for any kind of content to be conveyed, even a ContentCollection according to RFC 4073.

Another remark has been made with reference to RFC 4073: the ContentWithAttributes structure, also defined in RFC 4073, could in principle be used to bundle some content with the corrisponding evidence (the goal of my draft). Although this is true, it would require definining some additional OIDs, and mandating the presence of certain Attributes tagged by those OIDs. I frankly believe the TimeStampedData structure that I am proposing is better, first because it is dedicated and second because it "implements the ContentInfo interface", so to speak. It is simpler to manage for applications already able to parse different kinds of ContentInfo envelopes (there are a great many), possibly in a recursive way.

Adriano 

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

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

Santoni Adriano wrote:
> 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:
>   
>> 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.
>
> 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
>>
>>
>>     
>
>
>

---

From: "Santoni Adriano" <[email-masked]>
Date: Mon, 3 Sep 2007 15:28:30 +0200

Peter,

a text/plain object would be encoded "as is", in its native binary form -- like any other type of content, for that matter.

I suppose the accompanying 'mimeType' field would bear a value of "text/plain" or possibly "text/plain; charset=<charset-name>" if the charset cannot be inferred from context.

However, the 'mimeType' field in the TimeStampedData structure does not imply that the 'content' field encloses the body of a MIME entity (if that is what you have in mind). It is intended more like a hint about what kind of stuff can be found in the 'content' field. 

But nothing would block me if I wanted to put a full-blown MIME entity in the 'content' field, if necessary, along with all the needed MIME headers.

I am not sure if I got your question right...

Adriano

-----Messaggio originale-----
Da: Peter Sylvester [mailto:[email-masked]] 
Inviato: lunedì 3 settembre 2007 14.49
A: Santoni Adriano
Cc: [email-masked]
Oggetto: Re: R: R: Draft on TimeStampedData

How is a charset of a text/plain encoded in you proposal?

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 03 Sep 2007 14:48:42 +0200

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 03 Sep 2007 16:08:56 +0200

> a text/plain object would be encoded "as is", in its native binary form -- like any other type of content, for that matter.
Of course
> I suppose the accompanying 'mimeType' field would bear a value of "text/plain" or possibly "text/plain; charset=<charset-name>" if the charset cannot be inferred from context.
Indeed, I was trying to say "how do you indicate the charset", as you say
you usethe full value of the Content-Type header field.
In other words, you could have also name="file.txt"
Thus, no extra  parameter for the file name necessary.

Or in other words, in order to enhance 4073 to meet your needs you need 
to define
one attribut containing the mime-type, i.e. the content of a mime  
Content-type header field,
or you could even define an attribute for any header field, i.e. a 
sequence of the name
and value, e.g. you would encode a sequence of

    {"Content-Type", 'text/plain; charset=ISO-8859-1;name=toto.txt"}

you may even want to add a

    {"Content-Description","This is the timestamped version of Contract 1"}
> However, the 'mimeType' field in the TimeStampedData structure does not imply that the 'content' field encloses the body of a MIME entity (if that is what you have in mind). It is intended more lik…
I did not have this in mind unless the mime type would be 
application/mime of course.
> But nothing would block me if I wanted to put a full-blown MIME entity in the 'content' field, if necessary, along with all the needed MIME headers.
Nothing can stop you doing this, indeed :-)
> I am not sure if I got your question right...
I was imprecise, I didn' ask about the transfer encoding of the content but
wanted to be sure that on can encode the mime type parameters.