[Fwd: Re: R: R: TimeStampedData draft updated - please comment]
Alfredo Esposito <alfredo.esposito@infocamere.it> Fri, 07 December 2007 14:50 UTC
Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0eWu-0002RN-MV for pkix-archive@lists.ietf.org; Fri, 07 Dec 2007 09:50:16 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0eWs-0008Vn-L8 for pkix-archive@lists.ietf.org; Fri, 07 Dec 2007 09:50:16 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7DjWmI062204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 06:45:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB7DjWrU062203; Fri, 7 Dec 2007 06:45:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.3.213]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7DjShQ062184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 06:45:30 -0700 (MST) (envelope-from alfredo.esposito@infocamere.it)
Received: from lxm07.intra.infocamere.it (lxm07.intra.infocamere.it [1.5.72.7]) by lxme02.infocamere.it (8.13.6/8.13.6) with ESMTP id lB7DjRx2029458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 7 Dec 2007 14:45:28 +0100
Received: from lxm07.intra.infocamere.it (IDENT:U2FsdGVkX18QvNs2BHj0bevY/5dbLqQT8+lxVXoIkIs@localhost.localdomain [127.0.0.1]) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id lB7DjRvs006782; Fri, 7 Dec 2007 14:45:27 +0100
Received: from [1.71.4.82] ([1.71.4.82]) (authenticated bits=0) by lxm07.intra.infocamere.it (8.12.11/8.12.11) with ESMTP id lB7DjQuI006764; Fri, 7 Dec 2007 14:45:27 +0100
Message-ID: <47594E73.6020000@infocamere.it>
Date: Fri, 07 Dec 2007 14:45:23 +0100
From: Alfredo Esposito <alfredo.esposito@infocamere.it>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: ietf-pkix@imc.org, ietf-smime@imc.org
Subject: [Fwd: Re: R: R: TimeStampedData draft updated - please comment]
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Virus-Scanned: ClamAV 0.91.2/5028/Fri Dec 7 10:05:22 2007 on lxme02
X-Virus-Scanned: ClamAV 0.91.2/5028/Fri Dec 7 10:05:22 2007 on lxm07.intra.infocamere.it
X-Virus-Status: Clean
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 4.9 (++++)
X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7
About the Mime element I think the content field SHALL contain the original data since the timestampdata is usually calculated on the file as is stored on the user's hard disk not a mime element. Adding a mime header would generate a more cumbersome (and error prone) verification process
Finally, I agree with Denis Pinkas that the CMS WG is is the right one to publish the proposed standard. The OID itself is telling
Left aside these minor issues, the proposal addresses a problem that in my country (Italy) creates some interoperability trouble.
Having an IETF standards to refer to would be really useful
Alfredo Esposito
InfoCert SpA
PKI Department
Italy
Santoni Adriano wrote:
So you are suggesting that in the TimeStampedData structure: 1) the 'content' field should be a MIME element (and therefore contain a MIME content-type header), 2) the 'mimeType' field should be removed (as a consequence of the previous point). Did I take your right? I would not oppose to this arrangement, if it helped gathering more consensus. My only objection is that it will require a mix of text- and BER-based processing in order to fully open and disassemble a TimeStampedData instance. This is a bit unelegant IMO (but I know it is just normal in the S/MIME field, which I was not specifically addressing btw). Adriano -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Russ Housley Inviato: venerdì 23 novembre 2007 20.41 A: Santoni Adriano Cc: ietf-pkix@imc.org; ietf-smime@imc.org Oggetto: Re: R: TimeStampedData draft updated - please comment Santoni: Sorry for not being clear. My comment is directed toward you, but I included the ASN.1 fragment from Denis to highlight my point. Please take a look at RFC 3852. You will see that content types (object identifiers) are used to identify the format of any content. Many have been registered over the years. If you see TimeStampedData as an addition to the CMS, then this same technique needs to be employed. In the CMS, as I said in my earlier message, the id-data object identifier is used when the content is MIME encoded. The MIME type is not carried in the fields of the CMS. Russ At 02:46 AM 11/21/2007, Santoni Adriano wrote:Russ, I am not sure if you were addressing your comment to me or to Denis... At any rate, I would like to point out that the syntax I am proposing implies no MIME encoding at all. The data (like e.g. a patent, an offer, a contract, an income statement, a device driver, a security patch, a sensitive database, etc) is bundled in its native form, "as is". And thus, there is no MIME header to speak of. That's why I have provided for a 'mimeType' field: as a hint for the recipient/verifying application to guess what kind of data is carried within the TimeStampedData block, and what to do with it. Adriano -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Russ Housley Inviato: martedì 20 novembre 2007 22.53 A: ietf-pkix@imc.org; ietf-smime@imc.org Oggetto: Re: TimeStampedData draft updated - please comment In S/MIME, the id-data content type is used when the content is MIME encoded. Then, then MIME header in the content is used to determine the format of the content. Why does this suggest a different approach? Russ At 08:16 AM 11/19/2007, Denis Pinkas wrote:Adriano, Thank you for this new proposal. I skimmed through it. It is interesting, but I fear that it is targeted to the wrong WG. Since this would be an extension of CMS, this work item would rather belong to the S-MIME WG. For this reason, I copy the S-MIME WG. In addition, some polishing would be needed. Rather than long words, you will find hereafter a rewriting of the ASN.1 with a few explanatory comments. TimeStampedData ::= SEQUENCE { version [0] Version DEFAULT v1, fileName UTF8String, mimeType PrintableString, fileLocation UTF8String OPTIONAL, -- fileLocation is only a hint. -- The file may or may not be stored at that location. content OCTET STRING, temporalEvidences TemporalEvidences } Version ::= INTEGER { v1(0) } TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence -- This structure allows multiple levels of temporal evidences. TemporalEvidence ::= SEQUENCE { evidences Evidences, certificateLists CertificateLists OPTIONAL } CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList Evidence ::= CHOICE { timeStamps [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken } -- For each level there can be one or more time-stamps tokens. -- Before re-time stamping a set of former time-stamp tokens, -- the CRLs of the previous level of time-stamps tokens can be captured -- and inserted in the data structure. DenisHello there, here I am again with my TimeStampedData proposal. I have submitted a new draft (also attached here) that takes intoaccount some of the remarks and suggestions received so far.I have made room for additional types of temporal evidence, likee.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.I would like to invite everybody involved in time-stamping andarchiving e-documents to comment upon it: has it improved? something is missing?In particular, please state: - are you interested in this work? - do you agree to adopt it as a new PKIX work item? - are you going to use this format, once it is finished? Is anybody willing to spend a few words on this draft during theIETF meeting in Vancouver (as I cannot attend myself) ?And finally, is anybody willing to invest a little time inco-authoring this draft with me?Adriano Actalis S.p.A. Milano, ITALY -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org[mailto:owner-ietf-pkix@mail.imc.org] Per conto di Santoni AdrianoInviato: lunedì 3 settembre 2007 10.42 A: ietf-pkix@imc.org Oggetto: R: R: Draft on TimeStampedData 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 complicatethings 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 TimeStampedDatasyntax, as an alternative to the SET OF TimeStampToken;b) do not mention any specific standard for the "evidence", butjust mention RFC 3161 and RFC 4998 as two possibilities;In any case, it must be possible for the verifying application toeasily 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 emphasisshould 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 away 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 moreversatile 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 notstructured, 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: theContentWithAttributes 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:yhe@yhetheridge.org] Inviato: venerdì 31 agosto 2007 17.48 A: Santoni Adriano Cc: ietf-pkix@imc.org 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'dprefer to think over things a little bit more, and maybe collectmore feedback.In my mind, I can send a TimeStampedData envelope to businesspartners 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: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Julien Stern Inviato: venerdì 31 agosto 2007 13.43 A: ietf-pkix@imc.org 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 behampered 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 ERSas 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, -- JulienKind regards Tilo-----Messaggio originale----- Da: Stephen Kent [mailto:kent@bbn.com] Inviato: giovedì 30 agosto 2007 23.05 A: Young H Etheridge Cc: Santoni Adriano; ietf-pkix@imc.org 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 3161time 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 interoperabilityproblems 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" rel="nofollow">http://www.seccommerce.de
- [Fwd: Re: R: R: TimeStampedData draft updated - p… Alfredo Esposito