From owner-ietf-ltans Thu Dec 2 03:45:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Bjr3N077351; Thu, 2 Dec 2004 03:45:54 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2Bjr6e077347; Thu, 2 Dec 2004 03:45:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2BjrRB076997 for ; Thu, 2 Dec 2004 03:45:53 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iB2BjhiZ013842 for ; Thu, 2 Dec 2004 06:45:43 -0500 Message-Id: <200412021145.iB2BjhiZ013842@host13.websitesource.com> From: "Carl Wallace" To: Subject: Meeting minutes Date: Thu, 2 Dec 2004 06:45:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C4D83A.8B9977D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTYZHQcYOKPIDSaQJ+EsJYHUwGR8w== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C4D83A.8B9977D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wallace: WG status and Archive Requirements document status briefings - Abandoned aggressive schedule - Three working group documents in progress: Archive Requirements document, ERS and Notary document - Agreement: Requirements document can assert that both crypto and non-crypto are ok, but the WG work will focus on crypto mechanisms. (SC: question what about 2 of 2 with a random stream for XOR - will that meet the requirement?) - What is Archive Policy? Is this recertification/timing policy. Timing and mechanism (signature based or hash based time stamp) and access control and access policy. Who is allowed to change archivation period is access control policy? Masinter: Notary Services discussion - Definition of notary debate, name being changed to data certification and validation services - Went through the document - Can a human notary use the document to perform their services - Trials in CA on electronic notary. We do not know what it is: electronic assistance to notary, replacement of notary. - Went through use cases of human notary and how electronic notary will do it. - Specific workflows in the Notary document - DVCS is proposed as a place to build on. Is there any prohibition on moving it from PKIX to LTANS. PKIX mail list should be asked. It seems to be experimental RFC and hence ok. - How we got to data certification from notary? - Long term trusted third party certification - Debate with Chokhani on Archiving Vs. Notary. Not sure what the conclusion. - Russ: Are you happy with the outcome. - Larry: Seem to be happy with single service that offers archival and notary. He felts that they go hand in hand in the sense that there is no benefit to electronic notary without long temr archive. - Carl calls on OASIS and W3 - No response. - Collapse the archive and notary requirements document into one. - Russ: When will the documents be coming to IESG for approval? - Carl: Most likely not before Minneapolis. Need WG consensus first. ------=_NextPart_000_0018_01C4D83A.8B9977D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting minutes

Wallace: WG status and Archive Requirements = document status briefings

- Abandoned aggressive schedule

- Three working group documents in progress: = Archive Requirements document, ERS and Notary document

- Agreement: Requirements document can assert = that both crypto and non-crypto are ok, but the WG work will focus on = crypto mechanisms.  (SC: question what about 2 of 2 with a random = stream for XOR – will that meet the requirement?)

- What is Archive Policy?  Is this = recertification/timing policy.  Timing and mechanism (signature = based or hash based time stamp) and access control and access = policy.  Who is allowed to change archivation period is access = control policy?

Masinter: Notary Services discussion

- Definition of notary debate, name being = changed to data certification and validation services

- Went through the document

- Can a human notary use the document to perform = their services

- Trials in CA on electronic notary.  We do = not know what it is: electronic assistance to notary, replacement of = notary.

- Went through use cases of human notary and how = electronic notary will do it.

- Specific workflows in the Notary = document

- DVCS is proposed as a place to build on.  = Is there any prohibition on moving it from PKIX to LTANS.  PKIX = mail list should be asked.  It seems to be experimental RFC and = hence ok.

- How we got to data certification from = notary?

- Long term trusted third party = certification

- Debate with Chokhani on Archiving Vs. = Notary.  Not sure what the conclusion.

- Russ: Are you happy with the outcome.

- Larry: Seem to be happy with single service = that offers archival and notary.  He felts that they go hand in = hand in the sense that there is no benefit to electronic notary without = long temr archive.

- Carl calls on OASIS and W3 – No = response.

- Collapse the archive and notary requirements = document into one.

- Russ: When will the documents be coming to = IESG for approval?

- Carl: Most likely not before = Minneapolis.  Need WG consensus first.






------=_NextPart_000_0018_01C4D83A.8B9977D0-- From owner-ietf-ltans Fri Dec 10 05:07:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD7hML049791; Fri, 10 Dec 2004 05:07:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD7hkj049788; Fri, 10 Dec 2004 05:07:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD7fXn049722 for ; Fri, 10 Dec 2004 05:07:42 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBAD7cn21456; Fri, 10 Dec 2004 14:07:38 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 14:07:38 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBAD7WF29248; Fri, 10 Dec 2004 14:07:32 +0100 (MET) Date: Fri, 10 Dec 2004 14:07:32 +0100 (MET) From: Peter Sylvester Message-Id: <200412101307.iBAD7WF29248@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Cc: ietf-ltans@imc.org, LMM@acm.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: During a telephone call Denis informed me that he had missed the following message. For convenience (of Denis), I resend it. Sorry to bother the others again with the content. :-) Peter cc-recipients can stop reading here. ----- Begin Included Message ----- Date: Sat, 02 Oct 2004 19:32:02 -0700 From: Larry Masinter Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org I apologize for not reviewing your comments carefully before writing my own. In several places we make conflicting suggestions for what should be done with the text. I suppose with editorial suggestions that the editors have the final call, but where there are areas of technical disagreement, the working group should comment. I think it's appropriate to respond to comments when they are received, rather than waiting for the end of the 'last call' period. Here are my comments on yours; we should work to resolve conflicts where we've made different suggestions: > The document misses to indicate that it is necessary to demonstrate the > origin of the data The submitter? Or the originator? Or both? > and that the document has been placed in a storage before > a given date so that even the system engineers in charge of > the archive system do not have the possibility to modify any more stored > documents. Is this a requirement of the protocol, or a definition of a long-term archive system? > It is proposed to delete the present abstract and to replace it with: > > "This document specifies the technical requirement for long-term archive > services able to support non repudiation of data origin with integrity and > existence of data at a given time. Data to be stored and retrieved may > include signed data. Long-term archive services operate under an archive > policy which will need to be periodically redefined as the time goes. This > document specifies the main constituents of an archive policy". This still doesn't distinguish between the description of an archive service and the requirements for the protocol for interacting with it. To be honest, it's usually fruitless to focus on the abstract if there is disagreement about the substance, so we should come back to the abstract later. I like most of what you wrote. I still don't understand exactly what is meant by an 'archive policy' and whether it is a service-wide policy or a document-specific policy. Can one archive service provider proxy for many different ones, each of which with its own policy? > In fact the main constituents of an archive policy still need > to be defined. Yes, please. > The following comments focus on one of the components of an archiving > policy, i.e. the cryptographic maintenance policy, so the > work still needs to be done. Perhaps you could be more explicit, or give some references, to an example of what such a complete policy might be? > 2. Introduction > > The second paragraph needs to be revisited (besides the two > typos in the first sentence) because it is too vague. > Proposed replacement: > > "A long term archive service accepts data from users. This data may be > confidential data or public data. When it is confidential data, it is the > responsibility of users only to take care of the confidentiality of the data > they submit. If users care that their data shall not have its semantics > disclosed to the system engineers from the long term archive service, then > they shall take care themselves of the protection of their data. Is this really the idea? That the long-term archive has no responsibility to keep its archived data private??!? I could imagine different archives with different service guarantees, but it's hard to imagine a scenario where there is no requirement for confidentiality by the service provider, e.g., if I don't want my identity and the amount of data I've archived to be made public. So, if privacy from traffic analysis is a requirement, why is privacy in general not a requirement? > When data is confidential data, it is important that > submitters can check for themselves: Is it the submitters that want to check, or some third party to which the submitters wish to provide evidence? A submitter knows what was submitted, no? > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement (*), and > > - that the data originates from them (either symmetric > or asymmetric cryptography may be used). I think the comment about cryptography is perhaps out of place. It is a mechanism, not a requirement. Or is there a requirement to use cryptography? Or to support one or the other or both? > (*) more precisely a proof of existence of data at a given > time preceding the archival time, to demonstrate that the data was placed in > a server from the long-term archive before that time. I think there's a case where a malicious (or hacked) LTA might provide unmodified data to some retrievers and modified data to others, so it's useful to be clear about WHICH data has been 'unmodified'. > When the data is public data, it is important to be able to > demonstrate to someone else (i.e. obtain a non-repudiation evidence): Non-repudiation is important whether or not the data is public. > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement, and > > - that the data originally placed originates from a given entity > (different from servers belonging to the long-term archive > service). Note: that entity may or may not be a Notary. I don't understand the use case where a Notary might be the 'originator'. Surely the Notary is another party whose role is to add assurances, not an originator. Or do you imagine a real (human) Notary using a LTA service? > Since the document addresses long term storage, transfer from > one data storage unit to another may happen. Retrieval of data may > thus be done from a server different from the server where the data was > originally stored. It is therefor important to attach the security to the data > itself and not to rely only on the security mechanisms and procedures performed > by the server where the data is stored or retrieved. I don't think this follows. It's important for the storage to be secure operationally, and that any transfers be performed securely. One way to do that would be to encrypt the data and rely on the encryption during the transfer, but this has its difficulties, especially if the data is accompanied by meta-data (oh, access control policies) that might also be confidential. > Two non-repudiation evidences will need to be provided: > > - a first one to demonstrate to third parties the data originally > placed originates from a given entity, > > - a second one to demonstrate to third parties that the data was > originally accepted for storage, at a given time, by a server > belonging to a given long-term archive service. This is a good separation. I'm still a little uncomfortable with 'originates', since the demonstration isn't really of the origination but an initial attestation. > Since these evidences will be provided using cryptographic > means, Must they be provided using cryptographic means? There are no other means? How about 'When these evidences are provided ...'. > Some CA keys used to validate an electronic signature may last in practice > shorter that the end of the validity period of a signature policy. So it is > important to be able to maintain their validity beyond the end of the > validity period of the signature policy. I'm unclear about whose validity 'maintain their validity' applies to. The CA keys? You're going to maintain the validity of the keys beyond the end of the validity period of the keys? > This cryptographic maintenance activity is part of the responsibilities of a > long-term archive service and will be performed according to one or more > cryptographic maintenance policies." I think cryptographic maintenance activities are one way of providing long-term assurance, certainly. > > 3. Introduction > > The third paragraph needs to be revisited because it is inappropriate. > > Validation of assertions of agreements originally asserted with digital > signatures is not a task that is within the scope of a long-term archive > service. Proposed replacement: > > "A long-term archive service may optionally support a service able to check > an evidence demonstrating that an archive package has been originally > accepted for storage, at a given time, by a server belonging to another > given long-term archive service." I'm not sure why it is out of scope. It seems like a natural service for long-term archive services to offer. > 4. Introduction > 5. Introduction I think my suggestions here are more explicit than yours, but I hope I've accomplished the same goal. > 6. Terminology ... > Cryptographic maintenance policy: a named set of rules that > defines how to maintain the validity of digitally signed objects > should one of the hash functions or asymmetrical algorithm used > to create a digital signature of a signed object become weak or > one of the private keys used to create a > digital signature of a signed object be compromised or become weak. When there is a 'named set of rules', what is the namespace? Who maintains it? Note that all of the maintenance should happen BEFORE 'hash functions or asymmetrical algorithms become week' and BEFORE private keys are compromised or become weak and not after. > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I think what you're saying is that cryptographic maintenance is an option for providing long-term assurance. Of course, you could consider this 'two modes', but calling them 'active' and 'passive' is misleading. There may be other operational ways of providing long-term assurance that don't involve cryptographic maintenance but are still 'active'. > When operating is the active mode, a long-term archive service has to apply > a cryptographic maintenance policy on archived data objects using the > critical cryptographic parameters associated with every archived data object. > > When operating either in the passive or the active mode, a long-term archive > service has to apply a cryptographic maintenance policy on the archived > packages using the cryptographic maintenance parameters associated with a > set of archived packages". Cryptographic maintenance is only applied when cryptographic maintenance is applied, though. So how could a service with opaque data and no information about its signatures apply a cryptographic maintenance policy? ----- End Included Message ----- From owner-ietf-ltans Fri Dec 10 05:56:44 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBADui4f019549; Fri, 10 Dec 2004 05:56:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBADuiX1019548; Fri, 10 Dec 2004 05:56:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailer.berkom.de (mailer.berkom.de [141.39.13.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBADuh0g019468 for ; Fri, 10 Dec 2004 05:56:43 -0800 (PST) (envelope-from ErnstG.Giessmann@t-systems.com) Received: from fw4.telekom.de (gw4.telekom.de [141.39.2.1]) by mailer.berkom.de (0.00.0/8.12.9) with ESMTP id iBADuVhC008811; Fri, 10 Dec 2004 14:56:31 +0100 (MET) Received: by fw4.telekom.de; (8.8.8/1.3/10May95) id OAA12019; Fri, 10 Dec 2004 14:56:31 +0100 (MET) Received: from somewhere by smtpxd Received: from somewhere by smtpxd Message-ID: <41B9AAE5.2090801@t-systems.com> Date: Fri, 10 Dec 2004 14:55:49 +0100 From: Ernst G Giessmann User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Sylvester Cc: ietf-ltans@imc.org Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <200412101307.iBAD7WF29248@chandon.edelweb.fr> In-Reply-To: <200412101307.iBAD7WF29248@chandon.edelweb.fr> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter Sylvester wrote: > During a telephone call Denis informed me that he had missed the > following message. For convenience (of Denis), I resend it. Sorry to > bother the others again with the content. :-) > > Peter ... >> In fact the main constituents of an archive policy still need to be >> defined. The following comments focus on one of the components of >> an archiving policy, i.e. the cryptographic maintenance policy, so >> the work still needs to be done. The technical problem of maintaining the security status as it was at the time of deposit is that algorithms become weaker and that certificates binding a service or name to a public key may go out-of-date. The service provider can stop her operation after the latest NotAfter indication of all issued certificates is over and then you loose the outside trust anchor of the archive. So it is not document specific, but you must be able to determine starting from the document which service-specific policy was active as the document was deposed. Certainly we can consider different possiblities for maintenance but first we must think on crypto solutions. Regards, Ernst. From owner-ietf-ltans Mon Dec 13 07:32:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFWkE2039865; Mon, 13 Dec 2004 07:32:46 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDFWk7a039864; Mon, 13 Dec 2004 07:32:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFWjCW039844 for ; Mon, 13 Dec 2004 07:32:45 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Dec 2004 16:32:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Mon, 13 Dec 2004 16:32:12 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E029FC3DE@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQ From: "HOUSSIER Loic RD-MAPS-ISS" To: X-OriginalArrivalTime: 13 Dec 2004 15:32:21.0470 (UTC) FILETIME=[F00027E0:01C4E128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDFWkCW039859 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I am pretty new to ltans subjets. I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case. §4.1.1 You talk about "acknowledgment" that have to be provided by a LTA. I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA. What the need of unsigned acknowledgment? For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents. Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed. §4.2.1 Why lta MUST permit the specify of metadata ? Can it be possible for a LTA services not to propose this permission ? Has metadata to be outside the data ? Couldn't it be inside a group of data --> [[data][metadata]], in order not to be dealed by LTA ? §4.5.1 The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ? So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..." Well I think that's all. Regards, Loïc HOUSSIER Loïc HOUSSIER France Telecom/Division R&D/MAPS/NSS Ingénieur recherche et développement 38-40, rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Tel: +33 (0)1 45 29 58 08 Fax: +33 (0)1 45 29 65 19 -----Message d'origine----- De : owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] De la part de Ernst G Giessmann Envoyé : vendredi 10 décembre 2004 14:56 À : Peter Sylvester Cc : ietf-ltans@imc.org Objet : Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Peter Sylvester wrote: > During a telephone call Denis informed me that he had missed the > following message. For convenience (of Denis), I resend it. Sorry to > bother the others again with the content. :-) > > Peter ... >> In fact the main constituents of an archive policy still need to be >> defined. The following comments focus on one of the components of >> an archiving policy, i.e. the cryptographic maintenance policy, so >> the work still needs to be done. The technical problem of maintaining the security status as it was at the time of deposit is that algorithms become weaker and that certificates binding a service or name to a public key may go out-of-date. The service provider can stop her operation after the latest NotAfter indication of all issued certificates is over and then you loose the outside trust anchor of the archive. So it is not document specific, but you must be able to determine starting from the document which service-specific policy was active as the document was deposed. Certainly we can consider different possiblities for maintenance but first we must think on crypto solutions. Regards, Ernst. From owner-ietf-ltans Mon Dec 13 08:53:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGroMa022687; Mon, 13 Dec 2004 08:53:50 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDGroxH022686; Mon, 13 Dec 2004 08:53:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGrmP9022348 for ; Mon, 13 Dec 2004 08:53:48 -0800 (PST) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCTOM (pc-tom [141.12.87.62]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id RAA00278 for ; Mon, 13 Dec 2004 17:53:29 +0100 (MET) Message-Id: <200412131653.RAA00278@sonne.sit.fraunhofer.de> From: To: Subject: AW: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Mon, 13 Dec 2004 17:56:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <3418F3471F1CA4409901547349FFAE2E029FC3DE@FTRDMEL2.rd.francetelecom.fr> Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQAAIoUsA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDGrnP9022679 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > Im Auftrag von HOUSSIER Loic RD-MAPS-ISS > Gesendet: Montag, 13. Dezember 2004 16:32 > An: ietf-ltans@imc.org > Betreff: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks > > > Hello, > I am pretty new to ltans subjets. > I read the Requirements draft and have some questions. Don't worry if some > looks stupid, please let me know if it's the case. > Be welcome. Your Questions are not new, but not stupid. > > > §4.1.1 > You talk about "acknowledgment" that have to be provided by a LTA. > I think these must be signed by the LTA in order to give submitter an > evidence that he sent data to LTA. > What the need of unsigned acknowledgment? In an inhouse environment LTA is a service for an application system. E.g. inhouse environment is a hospital, LTA is document management or archive system and application system is a medical system used for generation of medical documents and signing them by doctors. In this case only evidence records are needed to verify, that archived documents existed at a certain point in past - e.g. before signature and hash-algorithms used in it got weak or certificates in it were revoked. Acknoledgement is useful to have an indication, that storing was accepted and successful. But no proof for document delivery is needed, therefore no signed acknoledgements are needed. If archive service is an external by a service provider, proof of delivery using a signed acknowledgement might be helpful. Problem is, that signed acknowledgement is valid only a relatively short time. It will loose its value of evidence over long periods of time (up to 10 or more years), because hash- and signature algorithms in it will get weak and certificates expire. Archive service provider possibly could therefore repudiate this acknowledgement after lets say 20 or 30 years if he wants to. Sending signed acknowledgement to another service provider who has to archive it would leed us to recursive and in effect very complex solutions. Therefore we prefer other strategies like protocols and external audits of archive service providers to avoid successful repudiation of delivery. Last but not least it would not be acceptable for users that he must store signed acknoledgements for every (maybe little) document he delivered to an archive service provider. If he wants to avoid to store documents by using an archive provider and has to store signed acknoledgements - were is the benefit? Storing a little index like a hash value or an integer should be sufficient to retrieve archived documents. From owner-ietf-ltans Mon Dec 13 08:58:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGwWWp027135; Mon, 13 Dec 2004 08:58:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDGwWdA027132; Mon, 13 Dec 2004 08:58:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGwU5h027086 for ; Mon, 13 Dec 2004 08:58:31 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDGwWn08202; Mon, 13 Dec 2004 17:58:32 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 17:58:32 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDGwVc09139; Mon, 13 Dec 2004 17:58:31 +0100 (MET) Date: Mon, 13 Dec 2004 17:58:31 +0100 (MET) From: Peter Sylvester Message-Id: <200412131658.iBDGwVc09139@chandon.edelweb.fr> To: ietf-ltans@imc.org, loic.houssier@francetelecom.com Subject: Re: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks X-Sun-Charset: ISO-8859-1 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: loic and Ernst, First, sorry for the late answer. > Hello, > I am pretty new to ltans subjets. > I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case. > Questions are rarely stupid, only the answers, so you are in a safer position than me (since I am responding) :-) > §4.1.1 > You talk about "acknowledgment" that have to be provided by a LTA. > I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA. > What the need of unsigned acknowledgment? The idea behind is that the archive service has a backend that provides a 'pointer' to the data, let's say a URI and then, independantly, and responing to other requirement, there may or may not be a front end that adds some security envelope attesting other information. You can for example have a (TLS) connection that just return a URI. > > For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents. You are refering to the 'grouping' at the end of chapter 4? My interpretation of 4.7.1 seems to indicate to me that indeed at least each element needs to be identifiable individually ==> acknowledgement, and of course, there is an acknowmedgment for the group as a whole. I haven't yet finished some work of 'folding' out common basic data elements from the original darfts and texts (TAP, DVCS, ERS, ...), so i have not yet a comple picture of what a group actually is, and what protocol exchanges are really necessary; groups may be represented for example as a mime multipart, as the newly proposed contentinfo which encapsulates several others, as some manifest in XML, or as hash trees with some simple things as leafs, ... > > Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed. > I can parse this question? Are you saying that an archiver must inform a client before the end of a period in order to permit an extension? I think that this is somewhat of of scope, since it at least it can be added as an additional service by an archiver, but not as an essential feature of the protocol. or, when you say 'MUST inform', what does this mean? How can the archiver get a proof of this? One may be tempted to say: May not delete before explicit confirmation of the client. But what does this mean? Do you have an idea of a protocol exchange? > > §4.2.1 > Why lta MUST permit the specify of metadata ? > Can it be possible for a LTA services not to propose this permission ? > Has metadata to be outside the data ? The current idea among the few persons who try to come up with a protocol is: metadata can be outside and inside. Some may be outside, i.e. explicity visible in an attestation describing the content: 'This is the attestation for patent number 123', 'The archived raw data are in format "mimetype", The 'owner' 'dublin core info', whatever you want to see explicitely. Some metadata can be inside (not visible without retreaving the data), and mainly useful for organising the internal work of the archiver, or to provide for potential transformations in future. The same information as outside, thus, you don't want them to be seen immediately in an attestation. You need to have at least (either explicitely or in a customer policy) a definition of the nature of the raw octets to be archived. > Couldn't it be inside a group of data --> [[data][metadata]], in order not to be dealed by LTA ? That is a possible approach: It may also be possible to specify something like a mime multipart/mixed or the newly proposed ContentInfo that encapsulated several Contentinfos. (If we talk CMS), in xml-dsig, there may be other structure with manifests etc. > > §4.5.1 > The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ? > So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..." > The term is correct: You may not have any confidentiality requirements for a particular context, but if you have them, the server must provide the means. The server cannot decide (dynamically) to forget about confidentiality. (Well, this is said with my limited noletsch ow ze inklisch laehngwitsch.) > Well I think that's all. > > Regards, > > Loïc HOUSSIER > > Peter Sylvester wrote: > > > During a telephone call Denis informed me that he had missed the > > following message. For convenience (of Denis), I resend it. Sorry to > > bother the others again with the content. :-) > > > > Peter > ... > >> In fact the main constituents of an archive policy still need to be > >> defined. The following comments focus on one of the components of > >> an archiving policy, i.e. the cryptographic maintenance policy, so > >> the work still needs to be done. > > The technical problem of maintaining the security status as it was at > the time of deposit is that algorithms become weaker and that > certificates binding a service or name to a public key may go > out-of-date. The service provider can stop her operation after the > latest NotAfter indication of all issued certificates is over and then > you loose the outside trust anchor of the archive. You mention TWO things here: - timely dependency of certificates (the ones used by the service provider I guess) ==> A known technique is to replace digital signatures by a hash links for which the top most hash is verifiable at the current time. (This can be also by means not using digital signatures, e.g. by comparision with a well published hash). - cryptographic weaknesses. ==> in the above, dependancy on secrets for authenticity can be replaced by hashes, weaknesses in hash function, long term security needs at least one additional redundant need (for VERY long term), like a good possiblity that a current physical copy had been done at the indicated time, or transformations have been confirmed etc. > > So it is not document specific, but you must be able to determine > starting from the document which service-specific policy was active as > the document was deposed. > > Certainly we can consider different possiblities for maintenance but > first we must think on crypto solutions. I am not sure about the 'first' in this sentence :-) Do you want to address failures of hash functions. > > Regards, > Ernst. > > > From owner-ietf-ltans Thu Dec 16 06:57:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGEvXA3087790; Thu, 16 Dec 2004 06:57:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGEvX3J087785; Thu, 16 Dec 2004 06:57:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGEvVAJ087693 for ; Thu, 16 Dec 2004 06:57:31 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 15:57:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Thu, 16 Dec 2004 15:57:22 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C4BE@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQAAIoUsAAk60/UA== From: "HOUSSIER Loic RD-MAPS-ISS" To: , X-OriginalArrivalTime: 16 Dec 2004 14:57:22.0876 (UTC) FILETIME=[8C615FC0:01C4E37F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBGEvWAJ087764 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thank You for the answer. Comments below. Loïc > In an inhouse environment LTA is a service for an application > system. E.g. > inhouse environment is a hospital, LTA is document management > or archive > system and application system is a medical system used for > generation of > medical documents and signing them by doctors. > In this case only evidence records are needed to verify, that archived > documents existed at a certain point in past - e.g. before > signature and > hash-algorithms used in it got weak or certificates in it > were revoked. > Acknoledgement is useful to have an indication, that storing > was accepted > and successful. But no proof for document delivery is needed, > therefore no > signed acknoledgements are needed. [LH]So, there is case where signed notification is not needed. But if there is some use-case where it is, shouldn't it be consider ? > > If archive service is an external by a service provider, > proof of delivery > using a signed acknowledgement might be helpful. Problem is, > that signed > acknowledgement is valid only a relatively short time. It > will loose its > value of evidence over long periods of time (up to 10 or more years), > because hash- and signature algorithms in it will get weak > and certificates > expire. Archive service provider possibly could therefore > repudiate this > acknowledgement after lets say 20 or 30 years if he wants to. > Sending signed acknowledgement to another service provider who has to > archive it would leed us to recursive and in effect very > complex solutions. [LH] Can't we imagine a TAA sending signed-notification each time the precedent one becomes invalid ? I see TAA as trusted authority, then I can believe that it must send me notification when new ones are needed. > Therefore we prefer other strategies like protocols and > external audits of > archive service providers to avoid successful repudiation of delivery. [LH] Not sure that I understand your words. " avoid succesfull repudiation of delivery" means "avoid sucessfull repudiation of reception"? What we need I think is to be sure that the data send are well archived. Am I wrong ? > Last but not least it would not be acceptable for users that > he must store > signed acknoledgements for every (maybe little) document he > delivered to an > archive service provider. If he wants to avoid to store > documents by using > an archive provider and has to store signed acknoledgements - > were is the > benefit? [LH] With the idea of sending signed notification when needed, user (of TAA) only get one thing from the TAA, as with the acknoledgement. > Storing a little index like a hash value or an integer should > be sufficient > to retrieve archived documents. [LH] that little index or hash value couldn't be in the signed-notification ? From owner-ietf-ltans Thu Dec 16 07:23:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGFN5dl010484; Thu, 16 Dec 2004 07:23:05 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGFN5uA010482; Thu, 16 Dec 2004 07:23:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGFN3RN010458 for ; Thu, 16 Dec 2004 07:23:04 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 16:23:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Thu, 16 Dec 2004 16:23:03 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C50D@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcThNPsvzUkKA1J+RfiXVeCJhrN0fACSq5Wg From: "HOUSSIER Loic RD-MAPS-ISS" To: "Peter Sylvester" , X-OriginalArrivalTime: 16 Dec 2004 15:23:04.0782 (UTC) FILETIME=[236D8EE0:01C4E383] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBGFN4RN010472 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, my remarks/questions below Loïc > > §4.1.1 > > You talk about "acknowledgment" that have to be provided by a LTA. > > I think these must be signed by the LTA in order to give > submitter an evidence that he sent data to LTA. > > What the need of unsigned acknowledgment? > > The idea behind is that the archive service has a backend > that provides a 'pointer' to the > data, let's say a URI and then, independantly, and responing > to other requirement, there > may or may not be a front end that adds some security > envelope attesting other information. > > You can for example have a (TLS) connection that just return a URI. [LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clear my mind ? > > Nearly End of duration period of archive must be provided > to submitter, in order to let him change the duration if needed. > > > I can parse this question? Are you saying that an archiver > must inform a client before the > end of a period in order to permit an extension? > > I think that this is somewhat of of scope, since it at least > it can be added as an > additional service by an archiver, but not as an essential > feature of the protocol. > > or, when you say 'MUST inform', what does this mean? How can > the archiver get a proof > of this? One may be tempted to say: May not delete before > explicit confirmation of > the client. But what does this mean? Do you have an idea of a > protocol exchange? [LH] I just had a problem with this. A the end of the archivation period, (if it's 30 years e.g.) how the user know that it is the end ? Must only the user deal with that ? > > > > §4.5.1 > > The confidentiality might be not necessary. By example, > let's think about a service that propose to archive patent. > What the need of confidentiality ? > > So I propose to change "A long term archive MUST provide > means to ensure..." by "A long term archive MAY..." > > > The term is correct: You may not have any confidentiality > requirements for a particular context, but > if you have them, the server must provide the means. The > server cannot decide (dynamically) to forget > about confidentiality. (Well, this is said with my limited > noletsch ow ze inklisch laehngwitsch.) [LH] As you can read, my english is poor compare to yours. What I wanted to say is that an LTA could not provide means for confidentiality. Confidentiality could be part of the front end of the service, no? Thank you From owner-ietf-ltans Thu Dec 16 08:26:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGGQItb045523; Thu, 16 Dec 2004 08:26:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGGQIhB045521; Thu, 16 Dec 2004 08:26:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGGQGAv045514 for ; Thu, 16 Dec 2004 08:26:17 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBGGQIn09625; Thu, 16 Dec 2004 17:26:19 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 16 Dec 2004 17:26:19 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBGGQIs22830; Thu, 16 Dec 2004 17:26:18 +0100 (MET) Date: Thu, 16 Dec 2004 17:26:18 +0100 (MET) From: Peter Sylvester Message-Id: <200412161626.iBGGQIs22830@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, loic.houssier@francetelecom.com Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clear my mind ? That was also my position (water below), i.e. an service where you don't split between the backend of archiving and a front end that delivers an attestation. I don't thino you are wrong, you just use TWO services one behind each other in a particular configuration, hydrogen+oxygen but you can have oxygen+carbon, this gives something else, also good for plants. The analogy stops here, because I am not saying that you need boths, since otherwise plants won't grow. :-) but you can have different type of USERS and SERVICES, it depends on where you put responsibilities. And sometime you need a 'NOTARY' in between. > [LH] I just had a problem with this. A the end of the archivation period, (if it's 30 years e.g.) how the user know that it is the end ? > Must only the user deal with that ? Well, a user can count? Whether a user is informed about a deletion, seems to me an independant service, informing *THE USER* after 30 years may be difficult anyway. what seems important for the protocol is that the user can be identified, i.e. one has enough redundant information about who owns or may own or may retrieve the info, this may be for example the court of city, etc. > [LH] As you can read, my english is poor compare to yours. What I wanted to say is that an LTA could not provide means for confidentiality. > Confidentiality could be part of the front end of the service, no? Or the user: As far as I know, confidentiality with crypto means is never supposed to last TOO long. An example: Would you think that a company that hold a patent and recipe for a well know brown coloured drink would store the information at an external archiver and transfer the information using the Internet? regards Peter From owner-ietf-ltans Fri Dec 17 01:19:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH9JITI026932; Fri, 17 Dec 2004 01:19:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH9JIRJ026929; Fri, 17 Dec 2004 01:19:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH9JFNx026810 for ; Fri, 17 Dec 2004 01:19:16 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Dec 2004 10:19:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Fri, 17 Dec 2004 10:19:14 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C7B2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTji/r2NZ6DlNifQDqnGDDEolBT0QAhdFDg From: "HOUSSIER Loic RD-MAPS-ISS" To: "Peter Sylvester" Cc: X-OriginalArrivalTime: 17 Dec 2004 09:19:15.0349 (UTC) FILETIME=[7A7C2C50:01C4E419] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBH9JHNx026877 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, See my comments hereafter: > > [LH]I my view, a LTA was an trusted authority, then could > be able to deliver signed-notification. (analogy whith TSA). > Am I really wrong ? If it's the case, and if you have the > time, could you clear my mind ? > > > That was also my position (water below), i.e. an service > where you don't split > between the backend of archiving and a front end that delivers > an attestation. > > I don't thino you are wrong, you just use TWO services one behind > each other in a particular configuration, hydrogen+oxygen > but you can have oxygen+carbon, this gives something else, > also good for > plants. The analogy stops here, because I am not saying that you need > boths, since otherwise plants won't grow. :-) > > but you can have different type of USERS and SERVICES, it depends > on where you put responsibilities. And sometime you need a 'NOTARY' > in between. > [LH] I need there an explanation what's a 'NOTARY' in this case ? > > > [LH] I just had a problem with this. A the end of the > archivation period, (if it's 30 years e.g.) how the user know > that it is the end ? > > Must only the user deal with that ? > > Well, a user can count? [LH] Well I guess so. >Whether a user is informed about a > deletion, seems to > me an independant service, informing *THE USER* after 30 years > may be difficult anyway. what seems important for the protocol is > that the user can be identified, i.e. one has enough > redundant information > about who owns or may own or may retrieve the info, this may > be for example > the court of city, etc. [LH] I agree, you're right. > > [LH] As you can read, my english is poor compare to yours. > What I wanted to say is that an LTA could not provide means > for confidentiality. > > Confidentiality could be part of the front end of the service, no? > > Or the user: As far as I know, confidentiality with crypto > means is never > supposed to last TOO long. An example: Would you think that a > company that > hold a patent and recipe for a well know brown coloured drink > would store > the information at an external archiver and transfer the > information using > the Internet? [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think. Furthermore, I'm not sure I understand what you say... Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ? > regards > Peter Thank you, Loïc From owner-ietf-ltans Fri Dec 17 05:18:30 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBHDIUVj019580; Fri, 17 Dec 2004 05:18:30 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBHDIUZF019579; Fri, 17 Dec 2004 05:18:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBHDITSJ019543 for ; Fri, 17 Dec 2004 05:18:29 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBHDIHn25198; Fri, 17 Dec 2004 14:18:17 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 17 Dec 2004 14:18:17 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBHDIGl26031; Fri, 17 Dec 2004 14:18:16 +0100 (MET) Date: Fri, 17 Dec 2004 14:18:16 +0100 (MET) From: Peter Sylvester Message-Id: <200412171318.iBHDIGl26031@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, loic.houssier@francetelecom.com Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > but you can have different type of USERS and SERVICES, it depends > > on where you put responsibilities. And sometime you need a 'NOTARY' > > in between. > > > [LH] I need there an explanation what's a 'NOTARY' in this case ? > *My* interpretation is: The 'notarisation middleperson' has a contract with some archiving service provider or operates its own boxes to store data. The interface to this box is secured with whatever way between the 'notarisation service' and the box. on the other side, janus has clients that need some 'attestation', in order to add this to a 'dossier' or not. ... > > the Internet? > > [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think. I think there is no disagreement; there different situations. There is some desire from the client to have a particular level of confidentiality, and the service proposes some way to respect this. This can be that the serice says: you have to encrypt your data by yourself, we do our best not to communicate to others but ... (I am not saying what I'd do as a customer in this case). But even that artist data may be public, it may not mean that everybody has a total access to the data *and* the way they are stored. The operator may choose a bunker, which as a side effect ensures *some* confidentiality, although this is not its main purpose. > Furthermore, I'm not sure I understand what you say... > Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ? > I think we agree, but to be sure: Since there are different layers and services, some parts may contribute to onfidentiality, others do not. The back back end stores data, the meaning of the data may be pretty undefined there, i.e. there may not be many requirements for the data to reveal something about the information they represent (it could be encrypted docs, or pieces). An operator provides some means not to operate in a totally open environment, but that's just a common sense or defense in depth behaviour. /P Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBHDIUVj019580; Fri, 17 Dec 2004 05:18:30 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBHDIUZF019579; Fri, 17 Dec 2004 05:18:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBHDITSJ019543 for ; Fri, 17 Dec 2004 05:18:29 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBHDIHn25198; Fri, 17 Dec 2004 14:18:17 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 17 Dec 2004 14:18:17 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBHDIGl26031; Fri, 17 Dec 2004 14:18:16 +0100 (MET) Date: Fri, 17 Dec 2004 14:18:16 +0100 (MET) From: Peter Sylvester Message-Id: <200412171318.iBHDIGl26031@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, loic.houssier@francetelecom.com Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > but you can have different type of USERS and SERVICES, it depends > > on where you put responsibilities. And sometime you need a 'NOTARY' > > in between. > > > [LH] I need there an explanation what's a 'NOTARY' in this case ? > *My* interpretation is: The 'notarisation middleperson' has a contract with some archiving service provider or operates its own boxes to store data. The interface to this box is secured with whatever way between the 'notarisation service' and the box. on the other side, janus has clients that need some 'attestation', in order to add this to a 'dossier' or not. ... > > the Internet? > > [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think. I think there is no disagreement; there different situations. There is some desire from the client to have a particular level of confidentiality, and the service proposes some way to respect this. This can be that the serice says: you have to encrypt your data by yourself, we do our best not to communicate to others but ... (I am not saying what I'd do as a customer in this case). But even that artist data may be public, it may not mean that everybody has a total access to the data *and* the way they are stored. The operator may choose a bunker, which as a side effect ensures *some* confidentiality, although this is not its main purpose. > Furthermore, I'm not sure I understand what you say... > Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ? > I think we agree, but to be sure: Since there are different layers and services, some parts may contribute to onfidentiality, others do not. The back back end stores data, the meaning of the data may be pretty undefined there, i.e. there may not be many requirements for the data to reveal something about the information they represent (it could be encrypted docs, or pieces). An operator provides some means not to operate in a totally open environment, but that's just a common sense or defense in depth behaviour. /P Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH9JITI026932; Fri, 17 Dec 2004 01:19:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBH9JIRJ026929; Fri, 17 Dec 2004 01:19:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBH9JFNx026810 for ; Fri, 17 Dec 2004 01:19:16 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Dec 2004 10:19:15 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Fri, 17 Dec 2004 10:19:14 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C7B2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTji/r2NZ6DlNifQDqnGDDEolBT0QAhdFDg From: "HOUSSIER Loic RD-MAPS-ISS" To: "Peter Sylvester" Cc: X-OriginalArrivalTime: 17 Dec 2004 09:19:15.0349 (UTC) FILETIME=[7A7C2C50:01C4E419] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBH9JHNx026877 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, See my comments hereafter: > > [LH]I my view, a LTA was an trusted authority, then could > be able to deliver signed-notification. (analogy whith TSA). > Am I really wrong ? If it's the case, and if you have the > time, could you clear my mind ? > > > That was also my position (water below), i.e. an service > where you don't split > between the backend of archiving and a front end that delivers > an attestation. > > I don't thino you are wrong, you just use TWO services one behind > each other in a particular configuration, hydrogen+oxygen > but you can have oxygen+carbon, this gives something else, > also good for > plants. The analogy stops here, because I am not saying that you need > boths, since otherwise plants won't grow. :-) > > but you can have different type of USERS and SERVICES, it depends > on where you put responsibilities. And sometime you need a 'NOTARY' > in between. > [LH] I need there an explanation what's a 'NOTARY' in this case ? > > > [LH] I just had a problem with this. A the end of the > archivation period, (if it's 30 years e.g.) how the user know > that it is the end ? > > Must only the user deal with that ? > > Well, a user can count? [LH] Well I guess so. >Whether a user is informed about a > deletion, seems to > me an independant service, informing *THE USER* after 30 years > may be difficult anyway. what seems important for the protocol is > that the user can be identified, i.e. one has enough > redundant information > about who owns or may own or may retrieve the info, this may > be for example > the court of city, etc. [LH] I agree, you're right. > > [LH] As you can read, my english is poor compare to yours. > What I wanted to say is that an LTA could not provide means > for confidentiality. > > Confidentiality could be part of the front end of the service, no? > > Or the user: As far as I know, confidentiality with crypto > means is never > supposed to last TOO long. An example: Would you think that a > company that > hold a patent and recipe for a well know brown coloured drink > would store > the information at an external archiver and transfer the > information using > the Internet? [LH]But maybe I gave a clumsy example. Let's think about DRM. Artist can store music theme without needing confidentiality I think. Furthermore, I'm not sure I understand what you say... Are we OK in the fact that the TAA must not deal with confidentiality, wheter it is dealed by submitter or front-end service ? > regards > Peter Thank you, Loïc Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGGQItb045523; Thu, 16 Dec 2004 08:26:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGGQIhB045521; Thu, 16 Dec 2004 08:26:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGGQGAv045514 for ; Thu, 16 Dec 2004 08:26:17 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBGGQIn09625; Thu, 16 Dec 2004 17:26:19 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 16 Dec 2004 17:26:19 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBGGQIs22830; Thu, 16 Dec 2004 17:26:18 +0100 (MET) Date: Thu, 16 Dec 2004 17:26:18 +0100 (MET) From: Peter Sylvester Message-Id: <200412161626.iBGGQIs22830@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, loic.houssier@francetelecom.com Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > [LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clear my mind ? That was also my position (water below), i.e. an service where you don't split between the backend of archiving and a front end that delivers an attestation. I don't thino you are wrong, you just use TWO services one behind each other in a particular configuration, hydrogen+oxygen but you can have oxygen+carbon, this gives something else, also good for plants. The analogy stops here, because I am not saying that you need boths, since otherwise plants won't grow. :-) but you can have different type of USERS and SERVICES, it depends on where you put responsibilities. And sometime you need a 'NOTARY' in between. > [LH] I just had a problem with this. A the end of the archivation period, (if it's 30 years e.g.) how the user know that it is the end ? > Must only the user deal with that ? Well, a user can count? Whether a user is informed about a deletion, seems to me an independant service, informing *THE USER* after 30 years may be difficult anyway. what seems important for the protocol is that the user can be identified, i.e. one has enough redundant information about who owns or may own or may retrieve the info, this may be for example the court of city, etc. > [LH] As you can read, my english is poor compare to yours. What I wanted to say is that an LTA could not provide means for confidentiality. > Confidentiality could be part of the front end of the service, no? Or the user: As far as I know, confidentiality with crypto means is never supposed to last TOO long. An example: Would you think that a company that hold a patent and recipe for a well know brown coloured drink would store the information at an external archiver and transfer the information using the Internet? regards Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGFN5dl010484; Thu, 16 Dec 2004 07:23:05 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGFN5uA010482; Thu, 16 Dec 2004 07:23:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGFN3RN010458 for ; Thu, 16 Dec 2004 07:23:04 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 16:23:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Thu, 16 Dec 2004 16:23:03 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C50D@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcThNPsvzUkKA1J+RfiXVeCJhrN0fACSq5Wg From: "HOUSSIER Loic RD-MAPS-ISS" To: "Peter Sylvester" , X-OriginalArrivalTime: 16 Dec 2004 15:23:04.0782 (UTC) FILETIME=[236D8EE0:01C4E383] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBGFN4RN010472 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter, my remarks/questions below Loïc > > §4.1.1 > > You talk about "acknowledgment" that have to be provided by a LTA. > > I think these must be signed by the LTA in order to give > submitter an evidence that he sent data to LTA. > > What the need of unsigned acknowledgment? > > The idea behind is that the archive service has a backend > that provides a 'pointer' to the > data, let's say a URI and then, independantly, and responing > to other requirement, there > may or may not be a front end that adds some security > envelope attesting other information. > > You can for example have a (TLS) connection that just return a URI. [LH]I my view, a LTA was an trusted authority, then could be able to deliver signed-notification. (analogy whith TSA). Am I really wrong ? If it's the case, and if you have the time, could you clear my mind ? > > Nearly End of duration period of archive must be provided > to submitter, in order to let him change the duration if needed. > > > I can parse this question? Are you saying that an archiver > must inform a client before the > end of a period in order to permit an extension? > > I think that this is somewhat of of scope, since it at least > it can be added as an > additional service by an archiver, but not as an essential > feature of the protocol. > > or, when you say 'MUST inform', what does this mean? How can > the archiver get a proof > of this? One may be tempted to say: May not delete before > explicit confirmation of > the client. But what does this mean? Do you have an idea of a > protocol exchange? [LH] I just had a problem with this. A the end of the archivation period, (if it's 30 years e.g.) how the user know that it is the end ? Must only the user deal with that ? > > > > §4.5.1 > > The confidentiality might be not necessary. By example, > let's think about a service that propose to archive patent. > What the need of confidentiality ? > > So I propose to change "A long term archive MUST provide > means to ensure..." by "A long term archive MAY..." > > > The term is correct: You may not have any confidentiality > requirements for a particular context, but > if you have them, the server must provide the means. The > server cannot decide (dynamically) to forget > about confidentiality. (Well, this is said with my limited > noletsch ow ze inklisch laehngwitsch.) [LH] As you can read, my english is poor compare to yours. What I wanted to say is that an LTA could not provide means for confidentiality. Confidentiality could be part of the front end of the service, no? Thank you Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGEvXA3087790; Thu, 16 Dec 2004 06:57:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBGEvX3J087785; Thu, 16 Dec 2004 06:57:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBGEvVAJ087693 for ; Thu, 16 Dec 2004 06:57:31 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 16 Dec 2004 15:57:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Thu, 16 Dec 2004 15:57:22 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E02A3C4BE@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQAAIoUsAAk60/UA== From: "HOUSSIER Loic RD-MAPS-ISS" To: , X-OriginalArrivalTime: 16 Dec 2004 14:57:22.0876 (UTC) FILETIME=[8C615FC0:01C4E37F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBGEvWAJ087764 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thank You for the answer. Comments below. Loïc > In an inhouse environment LTA is a service for an application > system. E.g. > inhouse environment is a hospital, LTA is document management > or archive > system and application system is a medical system used for > generation of > medical documents and signing them by doctors. > In this case only evidence records are needed to verify, that archived > documents existed at a certain point in past - e.g. before > signature and > hash-algorithms used in it got weak or certificates in it > were revoked. > Acknoledgement is useful to have an indication, that storing > was accepted > and successful. But no proof for document delivery is needed, > therefore no > signed acknoledgements are needed. [LH]So, there is case where signed notification is not needed. But if there is some use-case where it is, shouldn't it be consider ? > > If archive service is an external by a service provider, > proof of delivery > using a signed acknowledgement might be helpful. Problem is, > that signed > acknowledgement is valid only a relatively short time. It > will loose its > value of evidence over long periods of time (up to 10 or more years), > because hash- and signature algorithms in it will get weak > and certificates > expire. Archive service provider possibly could therefore > repudiate this > acknowledgement after lets say 20 or 30 years if he wants to. > Sending signed acknowledgement to another service provider who has to > archive it would leed us to recursive and in effect very > complex solutions. [LH] Can't we imagine a TAA sending signed-notification each time the precedent one becomes invalid ? I see TAA as trusted authority, then I can believe that it must send me notification when new ones are needed. > Therefore we prefer other strategies like protocols and > external audits of > archive service providers to avoid successful repudiation of delivery. [LH] Not sure that I understand your words. " avoid succesfull repudiation of delivery" means "avoid sucessfull repudiation of reception"? What we need I think is to be sure that the data send are well archived. Am I wrong ? > Last but not least it would not be acceptable for users that > he must store > signed acknoledgements for every (maybe little) document he > delivered to an > archive service provider. If he wants to avoid to store > documents by using > an archive provider and has to store signed acknoledgements - > were is the > benefit? [LH] With the idea of sending signed notification when needed, user (of TAA) only get one thing from the TAA, as with the acknoledgement. > Storing a little index like a hash value or an integer should > be sufficient > to retrieve archived documents. [LH] that little index or hash value couldn't be in the signed-notification ? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGwWWp027135; Mon, 13 Dec 2004 08:58:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDGwWdA027132; Mon, 13 Dec 2004 08:58:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGwU5h027086 for ; Mon, 13 Dec 2004 08:58:31 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBDGwWn08202; Mon, 13 Dec 2004 17:58:32 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 13 Dec 2004 17:58:32 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBDGwVc09139; Mon, 13 Dec 2004 17:58:31 +0100 (MET) Date: Mon, 13 Dec 2004 17:58:31 +0100 (MET) From: Peter Sylvester Message-Id: <200412131658.iBDGwVc09139@chandon.edelweb.fr> To: ietf-ltans@imc.org, loic.houssier@francetelecom.com Subject: Re: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks X-Sun-Charset: ISO-8859-1 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: loic and Ernst, First, sorry for the late answer. > Hello, > I am pretty new to ltans subjets. > I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case. > Questions are rarely stupid, only the answers, so you are in a safer position than me (since I am responding) :-) > §4.1.1 > You talk about "acknowledgment" that have to be provided by a LTA. > I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA. > What the need of unsigned acknowledgment? The idea behind is that the archive service has a backend that provides a 'pointer' to the data, let's say a URI and then, independantly, and responing to other requirement, there may or may not be a front end that adds some security envelope attesting other information. You can for example have a (TLS) connection that just return a URI. > > For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents. You are refering to the 'grouping' at the end of chapter 4? My interpretation of 4.7.1 seems to indicate to me that indeed at least each element needs to be identifiable individually ==> acknowledgement, and of course, there is an acknowmedgment for the group as a whole. I haven't yet finished some work of 'folding' out common basic data elements from the original darfts and texts (TAP, DVCS, ERS, ...), so i have not yet a comple picture of what a group actually is, and what protocol exchanges are really necessary; groups may be represented for example as a mime multipart, as the newly proposed contentinfo which encapsulates several others, as some manifest in XML, or as hash trees with some simple things as leafs, ... > > Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed. > I can parse this question? Are you saying that an archiver must inform a client before the end of a period in order to permit an extension? I think that this is somewhat of of scope, since it at least it can be added as an additional service by an archiver, but not as an essential feature of the protocol. or, when you say 'MUST inform', what does this mean? How can the archiver get a proof of this? One may be tempted to say: May not delete before explicit confirmation of the client. But what does this mean? Do you have an idea of a protocol exchange? > > §4.2.1 > Why lta MUST permit the specify of metadata ? > Can it be possible for a LTA services not to propose this permission ? > Has metadata to be outside the data ? The current idea among the few persons who try to come up with a protocol is: metadata can be outside and inside. Some may be outside, i.e. explicity visible in an attestation describing the content: 'This is the attestation for patent number 123', 'The archived raw data are in format "mimetype", The 'owner' 'dublin core info', whatever you want to see explicitely. Some metadata can be inside (not visible without retreaving the data), and mainly useful for organising the internal work of the archiver, or to provide for potential transformations in future. The same information as outside, thus, you don't want them to be seen immediately in an attestation. You need to have at least (either explicitely or in a customer policy) a definition of the nature of the raw octets to be archived. > Couldn't it be inside a group of data --> [[data][metadata]], in order not to be dealed by LTA ? That is a possible approach: It may also be possible to specify something like a mime multipart/mixed or the newly proposed ContentInfo that encapsulated several Contentinfos. (If we talk CMS), in xml-dsig, there may be other structure with manifests etc. > > §4.5.1 > The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ? > So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..." > The term is correct: You may not have any confidentiality requirements for a particular context, but if you have them, the server must provide the means. The server cannot decide (dynamically) to forget about confidentiality. (Well, this is said with my limited noletsch ow ze inklisch laehngwitsch.) > Well I think that's all. > > Regards, > > Loïc HOUSSIER > > Peter Sylvester wrote: > > > During a telephone call Denis informed me that he had missed the > > following message. For convenience (of Denis), I resend it. Sorry to > > bother the others again with the content. :-) > > > > Peter > ... > >> In fact the main constituents of an archive policy still need to be > >> defined. The following comments focus on one of the components of > >> an archiving policy, i.e. the cryptographic maintenance policy, so > >> the work still needs to be done. > > The technical problem of maintaining the security status as it was at > the time of deposit is that algorithms become weaker and that > certificates binding a service or name to a public key may go > out-of-date. The service provider can stop her operation after the > latest NotAfter indication of all issued certificates is over and then > you loose the outside trust anchor of the archive. You mention TWO things here: - timely dependency of certificates (the ones used by the service provider I guess) ==> A known technique is to replace digital signatures by a hash links for which the top most hash is verifiable at the current time. (This can be also by means not using digital signatures, e.g. by comparision with a well published hash). - cryptographic weaknesses. ==> in the above, dependancy on secrets for authenticity can be replaced by hashes, weaknesses in hash function, long term security needs at least one additional redundant need (for VERY long term), like a good possiblity that a current physical copy had been done at the indicated time, or transformations have been confirmed etc. > > So it is not document specific, but you must be able to determine > starting from the document which service-specific policy was active as > the document was deposed. > > Certainly we can consider different possiblities for maintenance but > first we must think on crypto solutions. I am not sure about the 'first' in this sentence :-) Do you want to address failures of hash functions. > > Regards, > Ernst. > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGroMa022687; Mon, 13 Dec 2004 08:53:50 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDGroxH022686; Mon, 13 Dec 2004 08:53:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDGrmP9022348 for ; Mon, 13 Dec 2004 08:53:48 -0800 (PST) (envelope-from Ulrich.Pordesch@sit.fraunhofer.de) Received: from PCTOM (pc-tom [141.12.87.62]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id RAA00278 for ; Mon, 13 Dec 2004 17:53:29 +0100 (MET) Message-Id: <200412131653.RAA00278@sonne.sit.fraunhofer.de> From: To: Subject: AW: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Mon, 13 Dec 2004 17:56:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <3418F3471F1CA4409901547349FFAE2E029FC3DE@FTRDMEL2.rd.francetelecom.fr> Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQAAIoUsA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDGrnP9022679 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > Im Auftrag von HOUSSIER Loic RD-MAPS-ISS > Gesendet: Montag, 13. Dezember 2004 16:32 > An: ietf-ltans@imc.org > Betreff: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks > > > Hello, > I am pretty new to ltans subjets. > I read the Requirements draft and have some questions. Don't worry if some > looks stupid, please let me know if it's the case. > Be welcome. Your Questions are not new, but not stupid. > > > §4.1.1 > You talk about "acknowledgment" that have to be provided by a LTA. > I think these must be signed by the LTA in order to give submitter an > evidence that he sent data to LTA. > What the need of unsigned acknowledgment? In an inhouse environment LTA is a service for an application system. E.g. inhouse environment is a hospital, LTA is document management or archive system and application system is a medical system used for generation of medical documents and signing them by doctors. In this case only evidence records are needed to verify, that archived documents existed at a certain point in past - e.g. before signature and hash-algorithms used in it got weak or certificates in it were revoked. Acknoledgement is useful to have an indication, that storing was accepted and successful. But no proof for document delivery is needed, therefore no signed acknoledgements are needed. If archive service is an external by a service provider, proof of delivery using a signed acknowledgement might be helpful. Problem is, that signed acknowledgement is valid only a relatively short time. It will loose its value of evidence over long periods of time (up to 10 or more years), because hash- and signature algorithms in it will get weak and certificates expire. Archive service provider possibly could therefore repudiate this acknowledgement after lets say 20 or 30 years if he wants to. Sending signed acknowledgement to another service provider who has to archive it would leed us to recursive and in effect very complex solutions. Therefore we prefer other strategies like protocols and external audits of archive service providers to avoid successful repudiation of delivery. Last but not least it would not be acceptable for users that he must store signed acknoledgements for every (maybe little) document he delivered to an archive service provider. If he wants to avoid to store documents by using an archive provider and has to store signed acknoledgements - were is the benefit? Storing a little index like a hash value or an integer should be sufficient to retrieve archived documents. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFWkE2039865; Mon, 13 Dec 2004 07:32:46 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBDFWk7a039864; Mon, 13 Dec 2004 07:32:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBDFWjCW039844 for ; Mon, 13 Dec 2004 07:32:45 -0800 (PST) (envelope-from loic.houssier@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Dec 2004 16:32:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Date: Mon, 13 Dec 2004 16:32:12 +0100 Message-ID: <3418F3471F1CA4409901547349FFAE2E029FC3DE@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks Thread-Index: AcTewSMNJ+OTVbjfRgylStL26+rhSQCZUsoQ From: "HOUSSIER Loic RD-MAPS-ISS" To: X-OriginalArrivalTime: 13 Dec 2004 15:32:21.0470 (UTC) FILETIME=[F00027E0:01C4E128] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iBDFWkCW039859 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I am pretty new to ltans subjets. I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case. §4.1.1 You talk about "acknowledgment" that have to be provided by a LTA. I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA. What the need of unsigned acknowledgment? For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents. Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed. §4.2.1 Why lta MUST permit the specify of metadata ? Can it be possible for a LTA services not to propose this permission ? Has metadata to be outside the data ? Couldn't it be inside a group of data --> [[data][metadata]], in order not to be dealed by LTA ? §4.5.1 The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ? So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..." Well I think that's all. Regards, Loïc HOUSSIER Loïc HOUSSIER France Telecom/Division R&D/MAPS/NSS Ingénieur recherche et développement 38-40, rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Tel: +33 (0)1 45 29 58 08 Fax: +33 (0)1 45 29 65 19 -----Message d'origine----- De : owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] De la part de Ernst G Giessmann Envoyé : vendredi 10 décembre 2004 14:56 À : Peter Sylvester Cc : ietf-ltans@imc.org Objet : Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Peter Sylvester wrote: > During a telephone call Denis informed me that he had missed the > following message. For convenience (of Denis), I resend it. Sorry to > bother the others again with the content. :-) > > Peter ... >> In fact the main constituents of an archive policy still need to be >> defined. The following comments focus on one of the components of >> an archiving policy, i.e. the cryptographic maintenance policy, so >> the work still needs to be done. The technical problem of maintaining the security status as it was at the time of deposit is that algorithms become weaker and that certificates binding a service or name to a public key may go out-of-date. The service provider can stop her operation after the latest NotAfter indication of all issued certificates is over and then you loose the outside trust anchor of the archive. So it is not document specific, but you must be able to determine starting from the document which service-specific policy was active as the document was deposed. Certainly we can consider different possiblities for maintenance but first we must think on crypto solutions. Regards, Ernst. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBADui4f019549; Fri, 10 Dec 2004 05:56:44 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBADuiX1019548; Fri, 10 Dec 2004 05:56:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailer.berkom.de (mailer.berkom.de [141.39.13.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBADuh0g019468 for ; Fri, 10 Dec 2004 05:56:43 -0800 (PST) (envelope-from ErnstG.Giessmann@t-systems.com) Received: from fw4.telekom.de (gw4.telekom.de [141.39.2.1]) by mailer.berkom.de (0.00.0/8.12.9) with ESMTP id iBADuVhC008811; Fri, 10 Dec 2004 14:56:31 +0100 (MET) Received: by fw4.telekom.de; (8.8.8/1.3/10May95) id OAA12019; Fri, 10 Dec 2004 14:56:31 +0100 (MET) Received: from somewhere by smtpxd Received: from somewhere by smtpxd Message-ID: <41B9AAE5.2090801@t-systems.com> Date: Fri, 10 Dec 2004 14:55:49 +0100 From: Ernst G Giessmann User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Sylvester Cc: ietf-ltans@imc.org Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <200412101307.iBAD7WF29248@chandon.edelweb.fr> In-Reply-To: <200412101307.iBAD7WF29248@chandon.edelweb.fr> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter Sylvester wrote: > During a telephone call Denis informed me that he had missed the > following message. For convenience (of Denis), I resend it. Sorry to > bother the others again with the content. :-) > > Peter ... >> In fact the main constituents of an archive policy still need to be >> defined. The following comments focus on one of the components of >> an archiving policy, i.e. the cryptographic maintenance policy, so >> the work still needs to be done. The technical problem of maintaining the security status as it was at the time of deposit is that algorithms become weaker and that certificates binding a service or name to a public key may go out-of-date. The service provider can stop her operation after the latest NotAfter indication of all issued certificates is over and then you loose the outside trust anchor of the archive. So it is not document specific, but you must be able to determine starting from the document which service-specific policy was active as the document was deposed. Certainly we can consider different possiblities for maintenance but first we must think on crypto solutions. Regards, Ernst. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD7hML049791; Fri, 10 Dec 2004 05:07:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iBAD7hkj049788; Fri, 10 Dec 2004 05:07:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iBAD7fXn049722 for ; Fri, 10 Dec 2004 05:07:42 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iBAD7cn21456; Fri, 10 Dec 2004 14:07:38 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 10 Dec 2004 14:07:38 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iBAD7WF29248; Fri, 10 Dec 2004 14:07:32 +0100 (MET) Date: Fri, 10 Dec 2004 14:07:32 +0100 (MET) From: Peter Sylvester Message-Id: <200412101307.iBAD7WF29248@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Cc: ietf-ltans@imc.org, LMM@acm.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: During a telephone call Denis informed me that he had missed the following message. For convenience (of Denis), I resend it. Sorry to bother the others again with the content. :-) Peter cc-recipients can stop reading here. ----- Begin Included Message ----- Date: Sat, 02 Oct 2004 19:32:02 -0700 From: Larry Masinter Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org I apologize for not reviewing your comments carefully before writing my own. In several places we make conflicting suggestions for what should be done with the text. I suppose with editorial suggestions that the editors have the final call, but where there are areas of technical disagreement, the working group should comment. I think it's appropriate to respond to comments when they are received, rather than waiting for the end of the 'last call' period. Here are my comments on yours; we should work to resolve conflicts where we've made different suggestions: > The document misses to indicate that it is necessary to demonstrate the > origin of the data The submitter? Or the originator? Or both? > and that the document has been placed in a storage before > a given date so that even the system engineers in charge of > the archive system do not have the possibility to modify any more stored > documents. Is this a requirement of the protocol, or a definition of a long-term archive system? > It is proposed to delete the present abstract and to replace it with: > > "This document specifies the technical requirement for long-term archive > services able to support non repudiation of data origin with integrity and > existence of data at a given time. Data to be stored and retrieved may > include signed data. Long-term archive services operate under an archive > policy which will need to be periodically redefined as the time goes. This > document specifies the main constituents of an archive policy". This still doesn't distinguish between the description of an archive service and the requirements for the protocol for interacting with it. To be honest, it's usually fruitless to focus on the abstract if there is disagreement about the substance, so we should come back to the abstract later. I like most of what you wrote. I still don't understand exactly what is meant by an 'archive policy' and whether it is a service-wide policy or a document-specific policy. Can one archive service provider proxy for many different ones, each of which with its own policy? > In fact the main constituents of an archive policy still need > to be defined. Yes, please. > The following comments focus on one of the components of an archiving > policy, i.e. the cryptographic maintenance policy, so the > work still needs to be done. Perhaps you could be more explicit, or give some references, to an example of what such a complete policy might be? > 2. Introduction > > The second paragraph needs to be revisited (besides the two > typos in the first sentence) because it is too vague. > Proposed replacement: > > "A long term archive service accepts data from users. This data may be > confidential data or public data. When it is confidential data, it is the > responsibility of users only to take care of the confidentiality of the data > they submit. If users care that their data shall not have its semantics > disclosed to the system engineers from the long term archive service, then > they shall take care themselves of the protection of their data. Is this really the idea? That the long-term archive has no responsibility to keep its archived data private??!? I could imagine different archives with different service guarantees, but it's hard to imagine a scenario where there is no requirement for confidentiality by the service provider, e.g., if I don't want my identity and the amount of data I've archived to be made public. So, if privacy from traffic analysis is a requirement, why is privacy in general not a requirement? > When data is confidential data, it is important that > submitters can check for themselves: Is it the submitters that want to check, or some third party to which the submitters wish to provide evidence? A submitter knows what was submitted, no? > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement (*), and > > - that the data originates from them (either symmetric > or asymmetric cryptography may be used). I think the comment about cryptography is perhaps out of place. It is a mechanism, not a requirement. Or is there a requirement to use cryptography? Or to support one or the other or both? > (*) more precisely a proof of existence of data at a given > time preceding the archival time, to demonstrate that the data was placed in > a server from the long-term archive before that time. I think there's a case where a malicious (or hacked) LTA might provide unmodified data to some retrievers and modified data to others, so it's useful to be clear about WHICH data has been 'unmodified'. > When the data is public data, it is important to be able to > demonstrate to someone else (i.e. obtain a non-repudiation evidence): Non-repudiation is important whether or not the data is public. > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement, and > > - that the data originally placed originates from a given entity > (different from servers belonging to the long-term archive > service). Note: that entity may or may not be a Notary. I don't understand the use case where a Notary might be the 'originator'. Surely the Notary is another party whose role is to add assurances, not an originator. Or do you imagine a real (human) Notary using a LTA service? > Since the document addresses long term storage, transfer from > one data storage unit to another may happen. Retrieval of data may > thus be done from a server different from the server where the data was > originally stored. It is therefor important to attach the security to the data > itself and not to rely only on the security mechanisms and procedures performed > by the server where the data is stored or retrieved. I don't think this follows. It's important for the storage to be secure operationally, and that any transfers be performed securely. One way to do that would be to encrypt the data and rely on the encryption during the transfer, but this has its difficulties, especially if the data is accompanied by meta-data (oh, access control policies) that might also be confidential. > Two non-repudiation evidences will need to be provided: > > - a first one to demonstrate to third parties the data originally > placed originates from a given entity, > > - a second one to demonstrate to third parties that the data was > originally accepted for storage, at a given time, by a server > belonging to a given long-term archive service. This is a good separation. I'm still a little uncomfortable with 'originates', since the demonstration isn't really of the origination but an initial attestation. > Since these evidences will be provided using cryptographic > means, Must they be provided using cryptographic means? There are no other means? How about 'When these evidences are provided ...'. > Some CA keys used to validate an electronic signature may last in practice > shorter that the end of the validity period of a signature policy. So it is > important to be able to maintain their validity beyond the end of the > validity period of the signature policy. I'm unclear about whose validity 'maintain their validity' applies to. The CA keys? You're going to maintain the validity of the keys beyond the end of the validity period of the keys? > This cryptographic maintenance activity is part of the responsibilities of a > long-term archive service and will be performed according to one or more > cryptographic maintenance policies." I think cryptographic maintenance activities are one way of providing long-term assurance, certainly. > > 3. Introduction > > The third paragraph needs to be revisited because it is inappropriate. > > Validation of assertions of agreements originally asserted with digital > signatures is not a task that is within the scope of a long-term archive > service. Proposed replacement: > > "A long-term archive service may optionally support a service able to check > an evidence demonstrating that an archive package has been originally > accepted for storage, at a given time, by a server belonging to another > given long-term archive service." I'm not sure why it is out of scope. It seems like a natural service for long-term archive services to offer. > 4. Introduction > 5. Introduction I think my suggestions here are more explicit than yours, but I hope I've accomplished the same goal. > 6. Terminology ... > Cryptographic maintenance policy: a named set of rules that > defines how to maintain the validity of digitally signed objects > should one of the hash functions or asymmetrical algorithm used > to create a digital signature of a signed object become weak or > one of the private keys used to create a > digital signature of a signed object be compromised or become weak. When there is a 'named set of rules', what is the namespace? Who maintains it? Note that all of the maintenance should happen BEFORE 'hash functions or asymmetrical algorithms become week' and BEFORE private keys are compromised or become weak and not after. > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I think what you're saying is that cryptographic maintenance is an option for providing long-term assurance. Of course, you could consider this 'two modes', but calling them 'active' and 'passive' is misleading. There may be other operational ways of providing long-term assurance that don't involve cryptographic maintenance but are still 'active'. > When operating is the active mode, a long-term archive service has to apply > a cryptographic maintenance policy on archived data objects using the > critical cryptographic parameters associated with every archived data object. > > When operating either in the passive or the active mode, a long-term archive > service has to apply a cryptographic maintenance policy on the archived > packages using the cryptographic maintenance parameters associated with a > set of archived packages". Cryptographic maintenance is only applied when cryptographic maintenance is applied, though. So how could a service with opaque data and no information about its signatures apply a cryptographic maintenance policy? ----- End Included Message ----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2Bjr3N077351; Thu, 2 Dec 2004 03:45:54 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iB2Bjr6e077347; Thu, 2 Dec 2004 03:45:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iB2BjrRB076997 for ; Thu, 2 Dec 2004 03:45:53 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iB2BjhiZ013842 for ; Thu, 2 Dec 2004 06:45:43 -0500 Message-Id: <200412021145.iB2BjhiZ013842@host13.websitesource.com> From: "Carl Wallace" To: Subject: Meeting minutes Date: Thu, 2 Dec 2004 06:45:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C4D83A.8B9977D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTYZHQcYOKPIDSaQJ+EsJYHUwGR8w== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C4D83A.8B9977D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wallace: WG status and Archive Requirements document status briefings - Abandoned aggressive schedule - Three working group documents in progress: Archive Requirements document, ERS and Notary document - Agreement: Requirements document can assert that both crypto and non-crypto are ok, but the WG work will focus on crypto mechanisms. (SC: question what about 2 of 2 with a random stream for XOR - will that meet the requirement?) - What is Archive Policy? Is this recertification/timing policy. Timing and mechanism (signature based or hash based time stamp) and access control and access policy. Who is allowed to change archivation period is access control policy? Masinter: Notary Services discussion - Definition of notary debate, name being changed to data certification and validation services - Went through the document - Can a human notary use the document to perform their services - Trials in CA on electronic notary. We do not know what it is: electronic assistance to notary, replacement of notary. - Went through use cases of human notary and how electronic notary will do it. - Specific workflows in the Notary document - DVCS is proposed as a place to build on. Is there any prohibition on moving it from PKIX to LTANS. PKIX mail list should be asked. It seems to be experimental RFC and hence ok. - How we got to data certification from notary? - Long term trusted third party certification - Debate with Chokhani on Archiving Vs. Notary. Not sure what the conclusion. - Russ: Are you happy with the outcome. - Larry: Seem to be happy with single service that offers archival and notary. He felts that they go hand in hand in the sense that there is no benefit to electronic notary without long temr archive. - Carl calls on OASIS and W3 - No response. - Collapse the archive and notary requirements document into one. - Russ: When will the documents be coming to IESG for approval? - Carl: Most likely not before Minneapolis. Need WG consensus first. ------=_NextPart_000_0018_01C4D83A.8B9977D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting minutes

Wallace: WG status and Archive Requirements = document status briefings

- Abandoned aggressive schedule

- Three working group documents in progress: = Archive Requirements document, ERS and Notary document

- Agreement: Requirements document can assert = that both crypto and non-crypto are ok, but the WG work will focus on = crypto mechanisms.  (SC: question what about 2 of 2 with a random = stream for XOR – will that meet the requirement?)

- What is Archive Policy?  Is this = recertification/timing policy.  Timing and mechanism (signature = based or hash based time stamp) and access control and access = policy.  Who is allowed to change archivation period is access = control policy?

Masinter: Notary Services discussion

- Definition of notary debate, name being = changed to data certification and validation services

- Went through the document

- Can a human notary use the document to perform = their services

- Trials in CA on electronic notary.  We do = not know what it is: electronic assistance to notary, replacement of = notary.

- Went through use cases of human notary and how = electronic notary will do it.

- Specific workflows in the Notary = document

- DVCS is proposed as a place to build on.  = Is there any prohibition on moving it from PKIX to LTANS.  PKIX = mail list should be asked.  It seems to be experimental RFC and = hence ok.

- How we got to data certification from = notary?

- Long term trusted third party = certification

- Debate with Chokhani on Archiving Vs. = Notary.  Not sure what the conclusion.

- Russ: Are you happy with the outcome.

- Larry: Seem to be happy with single service = that offers archival and notary.  He felts that they go hand in = hand in the sense that there is no benefit to electronic notary without = long temr archive.

- Carl calls on OASIS and W3 – No = response.

- Collapse the archive and notary requirements = document into one.

- Russ: When will the documents be coming to = IESG for approval?

- Carl: Most likely not before = Minneapolis.  Need WG consensus first.






------=_NextPart_000_0018_01C4D83A.8B9977D0--