From owner-ietf-ltans Fri Jan 2 23:01:59 2004 Received: from netscape105.com (a64021.upc-a.chello.nl [62.163.64.21]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0371sib054186 for ; Fri, 2 Jan 2004 23:01:55 -0800 (PST) (envelope-from zuka2006@netscape.net) Message-Id: <200401030701.i0371sib054186@above.proper.com> From: Zuka To: ietf-ltans-bks@above.proper.com Reply-To: zuka2006@netscape.net Subject: MR.MUDIWA ZUKA Date: Sat, 03 Jan 2004 08:02:30 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5009bf94-5f1f-4a2f-b67a-faef2ea52bf7" This is a multi-part message in MIME format --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable DEAR SIR. HAPPY NEW YEAR .I AM A GIRL OF 25 YEARS OLD AND I AM LOOKING FOR INVESTMENT = OPPORTUNITY. I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS = INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE = NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME THROUGH = THIS EMAIL zuka2008@excite.com BEST REGARDS MS. MUDIWA ZUKA --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7-- From owner-ietf-ltans Mon Jan 12 09:41:11 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHfBib096845; Mon, 12 Jan 2004 09:41:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CHfBDt096844; Mon, 12 Jan 2004 09:41:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.89.ixos.de [149.235.31.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHf2ib096817 for ; Mon, 12 Jan 2004 09:41:09 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i0CHeswI004219 for ; Mon, 12 Jan 2004 18:40:55 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Mon, 12 Jan 2004 18:40:54 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Subject: Initial requirements for long-term archive I-D Date: Mon, 12 Jan 2004 18:40:52 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3D933.398CBCB0" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D933.398CBCB0" ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D " (first milestone, unfortunately 6 weeks behind schedule) <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data = structures and protocol) will be targeting to fulfill the discussed requirements. = The initial drafts for these 2 documents are also behind schedule but = initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind: - discuss the different sections for the document individually - if possible list the chapter you want to change and the old and the = new text to make it easier for the others to follow the discussion and for = the editor. At the moment there are even topics for dicusiion open from the writing = of the initial paper. Best regards Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/M=FCnchen E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com =20 Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Initial requirements for long-term archive I-D

Hello,

Thanks to Carl, Uli and Ralf we = finished the
"Initial requirements for long-term archive I-D "
(first milestone, unfortunately 6 = weeks behind schedule)
= <<draft-ietf-ltans-reqs-01.txt>>

I would like to encourage now the = discussion for this draft on the mailing-list as fast as possible as = the following standards (data structures and protocol)  will be = targeting to fulfill the discussed requirements. The initial drafts for = these 2 documents are also behind schedule but initial documents shall = be available for discussion end of january.

Please keep best practices for the = discussion in mind:
- discuss the different sections for = the document individually
- if possible list the chapter you = want to change and the old and the new text to make it easier for the = others to follow the discussion and for the editor.

At the moment there are even topics = for dicusiion open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may = contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the sender immediately and destroy this eMail. Any use, disclosure or = distribution of the material in this eMail is strictly = forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie bitte sofort den Absender und vernichten Sie diese = eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe = ist nicht gestattet.

------_=_NextPart_001_01C3D933.398CBCB0-- ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: text/plain; name="draft-ietf-ltans-reqs-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltans-reqs-01.txt" Internet Draft Carl Wallace=20 draft-ietf-ltans-reqs-01.txt Orion Security Solutions=20 January 2004 Ralf Brandner=20 Expires July 2004 InterComponentWare AG Walldorf Ulrich Pordesch=20 Fraunhofer Institute=20 Secure Telecooperation=20 =20 =20 Long-term Archive Service Requirements=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of [RFC2026]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced or made obsolete by other documents at=20 any time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2004). All Rights Reserved.=20 =20 Abstract=20 =20 In many scenarios, users need to be able to ensure and prove the=20 existence and integrity of data, especially digitally signed data, = in a common and reproducible way over a long and possibly undetermined=20 period of time. This document specifies the technical requirements=20 for a long-term archive service to support such scenarios.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in [RFC2119].=20 Wallace Expires July 2004 [Page 1] =0C Long-term archive service requirements January 2004=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Terminology....................................................3=20 3. Application scenarios and general requirements.................4=20 3.1 Long-term archive problems and tasks.......................4=20 3.2 Long-term Archive Service..................................5=20 3.3 Instances and overall architecture.........................7=20 4. Long-term Archive Service functional and quality requirements..8=20 5. Long-term Archive Service data structure requirements..........9=20 6. Long-term Archive Service Protocol requirements...............10=20 7. Security Considerations.......................................11=20 8. Acknowledgements..............................................11=20 9. Normative References..........................................11=20 10. Authors' Addresses...........................................13=20 =20 =20 1. Introduction=20 =20 Various scenarios require the ability to preserve digital data and=20 its value as evidence for long periods of time. If data is = important=20 and will be needed in the future, it is necessary to store it in a=20 highly secure and persistent way. If the data is needed as evidence=20 in court, it may be necessary to prove that the existed at a certain = time in the past and has not been modified since then. If data is=20 signed or timestamped it is necessary to prove that it existed = before=20 cryptographic algorithms used to generate its signatures became weak = or the certificates expired or were revoked. =20 =20 A long-term archive service aids in the preservation of data over=20 long periods of time. In particular, it periodically performs=20 activities to preserve the non-repudiation of existence and = integrity=20 as well as ensuring the availability of data.=20 =20 A variety of technical and operational means are required to achieve = this goal and technical issues beyond cryptography, such as storage=20 media lifetime, disaster planning, changes in processing or software = technology, etc., as well as legal issues must be addressed.=20 =20 It is anticipated that a timestamp will be obtained for data = submitted to a long-term archive service. Thus, for all types of data, i.e.=20 signed and unsigned, will require preservation of evidence value by=20 the long-term archive service. =20 =20 Any digital signature that may need to be verified at points in time = well into the future, e.g. past the certificate validity period or=20 past the cryptoperiod of the signature private key, is a candidate=20 for preservation using a long-term archive service. Examples = include=20 =20 =20 Wallace Expires July 2004 [Page 2] =0C Long-term archive service requirements January 2004=20 signed contracts or agreements, wills, property deeds, CRLs and=20 timestamps over any type of data. The service will provide means to = prove the integrity and time of existence of the data at a given=20 point in time. It must be provable that the data is reliable,=20 because it existed at a point in time in the past when e.g. the=20 embedded hash and signature algorithms were still strong and the=20 included certificates were not revoked.=20 =20 This document aims to identify the technical requirements for a = long- term archive service. The=20 requirements analysis is divided into two parts.=20 The first part presents several application=20 scenarios. The second part addresses more specific requirements for = functions of the service, data structures to support preservation of data integrity using cryptographic mechanisms and at least protocol=20 requirements for interacting with a long-term archive service.=20 =20 Operational requirements, such as storage media concerns, individual = legal requirements and questions dealing with accounting and billing = techniques are not addressed by this document. However, the=20 transaction data and protocols must allow information to be carried=20 either directly or indirectly to facilitate association of=20 transactions with some accounting and billing mechanism, e.g.=20 identifiers for individual clients and/or large customers.=20 =20 =20 2. Terminology=20 =20 Arbitrator: Person, who has to be convinced of various aspects of=20 authenticity (originator, integrity, time of existence) of archived=20 data objects.=20 =20 Archived data object: Data unit that is archived and has to be=20 preserved for a long time by the Long-term Archive Service. =20 =20 Archive package: Collection of information including archived data=20 objects and the associated evidence record.=20 =20 Evidence: Information that may be used to resolve a dispute about=20 various aspects of authenticity of archived data objects. =20 =20 Evidence record: Collection of evidence compiled for one or more=20 given archived data objects over time. An evidence record may=20 include timestamps and additional verification data, like=20 certificates, revocation information, trust anchors, policy details, = role information, etc.=20 =20 Originator: Role (person or process) who produces, and possibly=20 signs, a data object that is to be archived. The Originator does=20 not necessarily generate or request generation of an evidence record = for the data.=20 =20 =20 Wallace Expires July 2004 [Page = 3] =0C Long-term archive service requirements January 2004=20 Timestamp: A signed confirmation generated by a Time Stamping=20 Authority (TSA) that a data item existed at a certain time. =20 [RFC3161] specifies a good structure for timestamps and a protocol=20 for communicating with a Timestamp Authority (TSA). =20 =20 Trusted Archiving: A process that includes storing of data objects=20 for long periods of time preserving its integrity, periodic=20 generation of timestamps and collection of evidence in support of=20 long-term preservation of data integrity.=20 =20 Trusted archive authority (TAA): A service responsible for=20 preserving data for long periods of time, including generation and=20 collection of evidence, storage of archived data objects and=20 evidence, etc. A.K.A. Long-term archive service. =20 =20 User: Role (person or process), who submit data objects for=20 archiving, request archive packages and verify the evidence of an=20 archived data object using the associated evidence record,=20 optionally including the verification of any signatures within the=20 archived data object itself. =20 =20 =20 3. Application scenarios and general requirements=20 =20 =20 3.1 Long-term archive problems and tasks=20 =20 A Long-term Archive Service has to be designed to cover several=20 problems in the area of long-term archiving of data objects. The=20 following sections describe some of these problems.=20 =20 3.1.1 Availability and integrity of data for long periods of time=20 =20 Individuals, companies and organisations are facing the problem of=20 how to store electronic documents in a safe way for sometimes even=20 undetermined spans of time. Examples include digital contracts, tax = declarations or electronic birth certificates. These documents need = special care in order to ensure persistent readability, permanent=20 availability, integrity and proper protection of confidentiality. =20 While some large organisations may be capable of supporting=20 appropriate backup, archive and protection mechanisms citizens and=20 small enterprises lack the technical prerequisites for this task. =20 Service providers offering external services for such documents are=20 thus needed.=20 =20 3.1.2 Demonstration of proof of existence and integrity for court=20 =20 Many archived documents are valuable and may be used as evidence in=20 court at some point in the future, e.g. to prove entitlements to=20 =20 =20 Wallace Expires July 2004 [Page 4] =0C Long-term archive service requirements January 2004=20 benefits or damages. In this case, it might be required to prove=20 that these documents existed at a certain time in the past and where = not modified since that time. =20 =20 3.1.3 Preservation of evidence for signed or timestamped data=20 =20 Archived data objects may contain digital signatures or time stamps=20 to be able to prove the origin and the time of existence of these=20 objects and signatures. In the course of time the value of evidence = of these signatures or timestamps can decrease or can get lost for=20 many reasons:=20 =20 - Revocation information is no longer available due to the=20 decommissioning of a CA or OCSP responder;=20 =20 - Lack of availability of certificates necessary to verify a=20 digital signature;=20 =20 - Expiration or Revocation of a certificate associated with a=20 digital signature;=20 =20 - Cryptanalytic or computational advances make it possible to=20 forge documents and signatures or to compute secret keys.=20 =20 In order to avoid problems in case of disputes in the future it is=20 necessary to preserve a digitally signed document, as well as=20 certificates, revocations lists, OCSP responses and time stamps, = even=20 if these elements are not included in the signed document itself. =20 Preservation may be achieved by periodic review of evidence. Upon=20 review, updated evidence may be obtained and stored or additional=20 cryptographic mechanisms may be applied, e.g. a new timestamp=20 obtained possibly using a stronger algorithm. =20 =20 By periodically inspecting and acting upon stored evidence, it is=20 possible to generate a cryptographically protected history for a = data item that contains no periods of time during which an algorithm was=20 thought to be weak, an authority thought to be compromised, etc.=20 =20 =20 3.2 Long-term Archive Service=20 =20 A Long-term Archive Service is to be designed to solve essential=20 parts of these problems by providing a specialized service:=20 =20 - The Long-term Archive Service is to store archived data objects=20 over a long, optionally undefined, period of time. Recovery methods, = redundant storage and disaster management and other measures have to = guarantee the availability of the data objects.=20 =20 Wallace Expires July 2004 [Page 5] =0C Long-term archive service requirements January 2004=20 - The Long-term Archive Service provides material needed to prove = the=20 existence and integrity of data objects for users as well as in=20 court. These means especially are time-stamps, periodically=20 generated during the archiving period of the data objects. = Additional=20 verification data, to verify these time-stamps after a long period = of=20 time (CRLS, OCSP responses and certificates) need also be provided. = =20 - The Long-term Archive Service provides means to preserve the value = of evidence of the archived data objects that are signed. These = means=20 are also time-stamps but with regard to possible special legal=20 requirements for the use as mechanism for the renewal of signatures. = =20 By using these means a signature application can verify that a=20 document, which contains signatures, existed before algorithms got=20 weak or certificates got invalid.=20 =20 A Long-term Archive Service is to not be designed to solve all=20 thinkable problems of long-term-verification of digital signatures. = It does not provide data necessary to verify signatures which are=20 part of the archived data object itself. This has to be done by=20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20 Protocol) or DVCS (Data Validation and Certification Server). This=20 is done, in part, so the archive service can operate without=20 knowledge of numerous signed data formats, document formats, etc. = It=20 also does not provide any means to integrate verification data in=20 data objects and verify embedded signatures. This has to be done on = the basis of other specifications, like RFC 3029 and with regard to=20 specifications of document formats. Of course it is recommended to=20 use such specifications together with a Long-term Archive Service.=20 =20 Several application scenarios providing one or more of these basic=20 service features are to be supported, including:=20 =20 - Archive service assuring long-term Non-Repudiation =20 =20 Long-term Archive Service stores data objects like signed or=20 unsigned documents for identified and authenticated users. It=20 generates time stamps for these data objects and obtains necessary=20 verification data over a given time or until a request of deletion = by=20 this authorized user is sent.=20 =20 - Pure long-term non-repudiation Service=20 =20 Long-term Archive Service only guarantees non-repudiation of=20 existence of data. It periodically generates time stamps and = obtains=20 additional verification data for a given period of time. It stores=20 data objects (e.g. documents, but also relevant parts of documents=20 containing signatures) locally only for the purpose of non- repudiation. It is not a document-archive for users and therefore=20 does not provide retrieval of documents and no deletion of data=20 objects. Therefore it does not need any access control.=20 =20 Wallace Expires July 2004 [Page 6] =0C Long-term archive service requirements January 2004=20 =20 3.3 Instances and overall architecture=20 =20 =20 The basic functions of a Long-term Archive Service are realized by=20 several instances:=20 =20 =20 +-------------+=20 | |=20 | User |=20 | |=20 +-------------+=20 |=20 ----------- Long-term Archive Protocol=20 |=20 +-------------+=20 | |=20 | TAA |=20 | |=20 +-------------+=20 |=20 ----------- Time Stamp Protocol=20 |=20 +-------------+=20 | |=20 | TSA |=20 | |=20 +-------------+=20 =20 Users transfer the data objects that shall be archived at the = Trusted=20 Archive Authority (TAA) using their application of choice. After=20 that, the user or application can request archive packages = containing=20 the stored data objects and the associated evidence record. This is = done by using the Long-term Archive Service Protocol and the data=20 format of archive package to be specified. The TAA stores the=20 documents, and obtains necessary verification data, especially time=20 stamps consulting a Time Stamp Authority using a special Protocol,=20 especially Time Stamp Protocol (RFC 3161). TAA also uses other=20 protocols (e.g. SCVP) to get additional verification data necessary=20 to verify generated time-stamps.=20 =20 A TAA may also provide the functions of a TSA, but separation must = be=20 possible. A TAA may store the archived data objects locally or may=20 use external archive services.=20 =20 Long-term Archive Service may allow for relays using Long-term=20 Archive Protocol. The use of external archive services may be also=20 possible. But Relaying must be transparent to the client. =20 =20 Wallace Expires July 2004 [Page 7] =0C Long-term archive service requirements January 2004=20 A TAA may be a server within an enterprise network communicating = with=20 local archive servers and other applications or an external service=20 accessible via internet.=20 =20 =20 4. Long-term Archive Service functional and quality requirements=20 =20 A Long-term Archive Service MUST provide following basic functions:=20 =20 - Accept data objects or groups of data objects for preservation; = =20 - Store submitted data objects for a given period of time;=20 =20 - Generate, store and maintain evidence records (i.e. by=20 periodically obtaining timestamps) for data objects submitted for=20 preservation;=20 =20 - Collect and store additional verification data necessary to=20 verify evidence records;=20 =20 - Provide archive packages containing archived data, evidence=20 record or both;=20 =20 - Provide service according to a long-term archive policy;=20 - The archive service MUST be able to provide evidence about the policies that have been used at any time. =20 - Be able to provide archive packages even if the storage,=20 software or processing technology changes during the lifetime of an=20 archived data object;=20 =20 - Be able to provide an acknowledgement that a data object = existed=20 at a certain time, as an alternative, if user is not able to=20 interpret the evidence record;=20 =20 - Operate per an archive policy, which at least determines = quality=20 of time-stamps and conditions for there renewal and etc;=20 =20 - If data objects are not stored by the Long-term-Archive-Service = itself, there must exist mechanisms to make these data objects later available to the service if necessary in case of renewal of time-stamps. A long-term archive service must be able to work efficiently even = for=20 large amounts of archived data objects. In order to limit expenses, = costs and dependency on high performance, time-stamp services, the=20 number of necessary time stamps MUST be minimized and a time stamp=20 should include a large number of signatures and documents;=20 =20 =20 =20 =20 Wallace Expires July 2004 [Page 8] =0C Long-term archive service requirements January 2004=20 =20 Necessity to access stored archived data object SHOULD be minimized. = =20 It SHOULD only be necessary access to the archived data objects only = if the archived data objects are requested by users or if applied=20 hash algorithms become insecure. =20 =20 A Long-term Archive Service may implement additional features, such=20 as validation of data objects, if they are signed documents.=20 5. Long-term Archive Service data structure requirements=20 =20 Standardization of data structures and processing procedures for an=20 archive package will simplify the job of TAAs and enable = verification=20 by any user.=20 =20 The data structure for archive package should include the archived=20 data objects and the evidence record. Archived data objects may be=20 included as part of the archive package so that it is possible to=20 request only the evidence record.=20 =20 The data structure for the evidence record itself should have the=20 following properties:=20 =20 - It MUST be possible to include all timestamps necessary to=20 verify the existence of the archived data objects.=20 =20 - The timestamp data structure SHOULD be defined in such a way=20 that it is possible to provide evidence for many archived data=20 objects in an efficient way.=20 =20 - It SHOULD be possible to provide evidence for groups of = archived=20 data objects. For example, it should be possible to archive a=20 document file and a signature file together such that they get the=20 same evidence record.=20 =20 - Where groups of data objects are submitted, non-repudiation=20 proof MUST still be available for each archived data object=20 separately.=20 =20 - The deletion of archived data objects MUST NOT put the=20 provability of other archived data at risk.=20 =20 - It SHOULD be possible to create timestamps without the need to=20 access the archived data objects. The access to the archived data=20 SHOULD only be necessary if the security suitability of employed = hash=20 algorithm is menaced.=20 =20 - All hash algorithms applied to archived data over time SHOULD = be=20 identified in a single location to facilitate single pass=20 verification.=20 =20 - It SHOULD be possible to package all evidence along with the=20 archived data objects in a single data item or to package evidence=20 =20 Wallace Expires July 2004 [Page 9] =0C Long-term archive service requirements January 2004=20 and archived data objects in separate items.=20 =20 - It SHOULD be possible to provide evidence for encrypted = archived=20 data objects. It SHOULD be possible to integrate information for = the=20 reconstruction of the archived data objects of the unencrypted data=20 objects (key, algorithm, etc.).=20 =20 - It SHOULD be possible to integrate additional information for=20 the verification of timestamps within the evidence record or the=20 archived data object itself such as certificates and revocation=20 information, the security suitability of applied algorithms and = trust=20 anchors. =20 =20 =20 6. Long-term Archive Service Protocol requirements=20 =20 Standardization of a protocol for interactions with a Long-term=20 Archive Service is desirable. The protocol should have the = following=20 properties:=20 =20 - The protocol MUST define interactions with a Long-term Archive=20 Service including, at a minimum: submission of data or groups of=20 data for preservation, retrieval of archive packages and deletion=20 of archived data and associated evidence records. =20 - The protocol MUST provide a response indicating successful=20 submission or deletion of data. The acknowledgement of successful=20 submission SHOULD permit a submitter to verify that the correct data = was received by the service for preservation, e.g. the=20 acknowledgement could include an index, a signature or a timestamp=20 obtained for the archived data object.=20 =20 - The protocol MUST response an index to retrieve the archive=20 package. It also should be possible to retrieve archive packages by = using hash values of the archived data objects.=20 - The protocol SHOULD support some basic Metadata (Mime-Type, key = words,etc.), i.e. the client should be able to provide metadata=20 along with the archived data to facilitate future search operations=20 based on the metadata.=20 =20 - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an = error.=20 =20 - A Long-term Archive Service MUST provide an indication of the=20 long-term archive policy under which the service operates.=20 =20 - The protocol MUST prevent replay attacks. =20 - The protocol SHOULD permit encryption of data before submission = in such a way that there exists non-repudiation evidence for the=20 unencrypted data.=20 =20 Wallace Expires July 2004 [Page 10] =0C Long-term archive service requirements January 2004=20 - The protocol SHOULD provide means of associating submitted data = objects with previously submitted data objects, i.e. to facilitate=20 retrieval based on aggregation of objects over time.=20 - The protocol SHOULD provide means for specifying a point in = time=20 at which an archived data object need no longer be preserved. It=20 also should be possible to extend the archiving period.=20 =20 - The protocol SHOULD provide the submission of evidence records=20 previously generated by a different TAA.=20 - The format for the acknowledgements MUST allow the=20 identification of the archiving provider.=20 - The format for the acknowledgements MUST allow (at least from the creating archiving provider) the identification of the=20 participating client. - Responses must uniquely reference corresponding requests - It should be possible to sign requests and responses. It is=20 recommended that in particular acknowledgements are signed. - Deletion must be authenticated.=20 =20 - The archive service MUST be able to provide evidence about the policies that have been used at any time - The protocol SHOULD be as simple to use as possible.=20 =20 Means to enable accountability, access control, confidentiality of=20 communication between applications and TAA need additional=20 precautions (like SSL) that are outside the scope of these=20 requirements.=20 7. Security Considerations=20 =20 Where non-standard formats are used or proprietary processing is=20 employed, verification of signatures on or in archived data may=20 require the availability of specific applications or tools.=20 =20 Certificate revocation could retroactively invalidate previously=20 verified signatures. Measures may be implemented to support such=20 claims by an alleged signer, e.g. collection of revocation=20 information after a grace period during which compromise can be=20 reported or preservation of subsequent revocation information. =20 =20 Access control mechanisms associated with data stored by a TAA = should=20 consider the lifespan of the data object. For example, the=20 credentials of an entity that submitted data to an archive may not = be=20 available or valid when the data needs to be retrieved.=20 Wallace Expires July 2004 [Page 11] =0C Long-term archive service requirements January 2004=20 To achieve accountability, local means should be employed to ensure that all data is inserted in chronological order, e.g. by using write-once media. Similarly, methods should be deployed to ensure that all deletions are detectable. =20 =20 8. Acknowledgements=20 =20 Thanks to Peter Sylvester for sharing information from the=20 OpenEvidence project.=20 =20 =20 9. Normative References=20 =20 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision=20 3", BCP 9, RFC 2026, October 1996.=20 =20 [RFC2028] Bradner, S. and R. Hovey, "The Organizations Involved in=20 the IETF Standards Process", BCP 11, RFC 2028, October=20 1996.=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 [RFC3029] Adams, C., Sylvester, P., Zolotarev, M. and R.=20 Zuccherato, "Internet X.509 Public Key Infrastructure=20 Data Validation and Certification Server Protocols", RFC=20 3029, August 2001.=20 =20 [RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,=20 "Internet X.509 Public Key Infrastructure Time-Stamp=20 Protocol (TSP)", RFC 3161, August 2001.=20 =20 =20 Wallace Expires July 2004 [Page 12] = =0C Long-term archive service requirements January 2004=20 10. Authors' Addresses=20 =20 Carl Wallace=20 Orion Security Solutions=20 Suite 300=20 1489 Chain Bridge Road=20 McLean, VA 22101=20 E-Mail : cwallace@orionsec.com=20 =20 Ralf Brandner=20 Otto-Hahn-Str. 3 =20 D-69190 Walldorf, Germany=20 E-Mail: ralf.brandner@intercomponentware.com=20 Ulrich Pordesch=20 Fraunhofer Gesellschaft=20 Institute Secure Telecooperation=20 Dolivostrasse 15=20 D-64293 Darmstadt, Germany=20 E-Mail: ulrich.pordesch@sit.fraunhofer.de=20 Wallace Expires July 2004 [Page 13] ------_=_NextPart_000_01C3D933.398CBCB0-- From owner-ietf-ltans Tue Jan 13 08:59:29 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DGxTib050400; Tue, 13 Jan 2004 08:59:29 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DGxTnP050399; Tue, 13 Jan 2004 08:59:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0DGxNib050388 for ; Tue, 13 Jan 2004 08:59:23 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 17249 invoked from network); 13 Jan 2004 16:54:23 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:23 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15667-10 for ; Tue, 13 Jan 2004 17:54:23 +0100 (CET) Received: (qmail 17239 invoked from network); 13 Jan 2004 16:54:22 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:22 -0000 From: "A. Jerman Blazic" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D Date: Tue, 13 Jan 2004 17:59:14 +0100 Message-ID: <00ac01c3d9f6$92db8cb0$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C3D9FE.F49FF4B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> X-Virus-Scanned: by amavisd-new at e5.ijs.si 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_00AD_01C3D9FE.F49FF4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tobias and others =20 First of all, I am pleased LTANS did produce one of the first discussable drafts. =20 In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management". I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... =20 Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. =20 User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems... =20 On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy? =20 Hope this will trigger some discussion... =20 Regards =20 Aleksej -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, January 12, 2004 6:41 PM To: 'ietf-ltans@imc.org' Subject: Initial requirements for long-term archive I-D=20 Importance: High Hello,=20 Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D "=20 (first milestone, unfortunately 6 weeks behind schedule)=20 <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data structures and protocol) will be targeting to fulfill the discussed requirements. The initial drafts for these 2 documents are also behind schedule but initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind:=20 - discuss the different sections for the document individually=20 - if possible list the chapter you want to change and the old and the new text to make it easier for the others to follow the discussion and for the editor. At the moment there are even topics for dicusiion open from the writing of the initial paper.=20 Best regards=20 Tobias=20 Tobias Gondrom=20 Senior Software Architect=20 Engineering=20 IXOS Software AG=20 Technopark Neukeferloh=20 Bretonischer Ring 12=20 D-85630 Grasbrunn/M=FCnchen=20 E-Mail: Tobias.Gondrom@ixos.de=20 WWW: http://www.ixos.com=20 Tel: +49-89-4629-1816=20 Fax: +49-89-4629-33-1816=20 This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------=_NextPart_000_00AD_01C3D9FE.F49FF4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first = discussable=20 drafts.
 
In the first place I do have some views on the = general document=20 structure, which is very "Trusted Archive Protocol" oriented. In my = view, one=20 has to distinguish two main logical parts of the archive, which is = protocol=20 interaction mechanisms, i.e. trusted archive protocol or a point of = user's=20 interaction with an archive. The other is archive itself and integrated=20 mechanisms for assuring object validity over defined or undefined period = of time=20 (I do distinguish at least two measures of archiving period, although=20 e-archiving is tightly related to needs/requirements/obligations on = content=20 archiving, so many "time-frame" definitions are possible) in combination = with=20 archived object "management". I guess data structures are trying to = focus on=20 later but conservation mechanisms seems like missing or at least no = indirect linkage to additional specifications are mentioned, of course = if there=20 are some (XAdES??)....
 
Next, in the document (page 4) = redundant storage,=20 disaster recovery, etc. are mentioned. Data storage mechanisms = should be=20 out of the scope of the e-archive, since back-up mechanisms and systems = are=20 something which one can find on, let's say, "lower" infrastructure=20 layer and should be dealt as = is.
 
User authentication is another problem in = wide scale=20 deployment of archive services. Bearing in mind that privacy is one of = the (more=20 and more) important factor in open infrastructure, confidentiality is = even more=20 important in case of formal content handling (contracts, invoices!!).=20 Furthermore, DVCS exposes the content to authority at least, and has = serious=20 confidentiality problems...
 
On page 5 and 6, TAA is presented as a = document storage=20 service, which in certain case doesn't have to. My personal view is, = that=20 archiving does not mean only archiving service but extended = functionality of=20 existing document warehouses or management systems. In this case, TAA is = a=20 service maintaining only archiving related data and not content by = itself,=20 i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means = single=20 point of interaction for many content related services. Do we really = need such=20 content redundancy?
 
Hope this will trigger some=20 discussion...
 
Regards
 
Aleksej
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Tobias Gondrom
Sent: Monday, January 12, 2004 = 6:41=20 PM
To: 'ietf-ltans@imc.org'
Subject: Initial = requirements=20 for long-term archive I-D
Importance: = High

Hello,

Thanks to Carl, Uli and Ralf we = finished the=20
"Initial requirements for long-term archive = I-D=20 "
(first milestone,=20 unfortunately 6 weeks behind schedule)
<<draft-ietf-ltans-reqs-01.txt>> =

I would like to encourage now the = discussion for=20 this draft on the mailing-list as fast as possible as the following = standards=20 (data structures and protocol)  will be targeting to fulfill the=20 discussed requirements. The initial drafts for these 2 documents are = also=20 behind schedule but initial documents shall be available for = discussion end of=20 january.

Please keep best practices for the = discussion in=20 mind:
- discuss the different = sections for=20 the document individually
- if = possible=20 list the chapter you want to change and the old and the new text to = make it=20 easier for the others to follow the discussion and for the = editor.

At the moment there are even topics for = dicusiion=20 open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG =
Technopark Neukeferloh
Bretonischer=20 Ring 12
D-85630 = Grasbrunn/M=FCnchen=20

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com =
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain = confidential=20 and/or privileged information. If you are not the intended recipient = or have=20 received this eMail in error, please notify the sender immediately and = destroy=20 this eMail. Any use, disclosure or distribution of the material in = this eMail=20 is strictly forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich=20 gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind = oder diese=20 eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und=20 vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder=20 Weitergabe ist nicht gestattet.

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0-- From owner-ietf-ltans Tue Jan 27 09:11:50 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RHBoi2040670; Tue, 27 Jan 2004 09:11: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 i0RHBocJ040667; Tue, 27 Jan 2004 09:11:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.89.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RHBlEd040642 for ; Tue, 27 Jan 2004 09:11:48 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i0RHBaeX018377; Tue, 27 Jan 2004 18:11:41 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 18:12:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5308@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej Date: Tue, 27 Jan 2004 18:11:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4F8.A54F3600" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E4F8.A54F3600 Content-Type: text/plain Dear Aleksej, Dear Tobias and others First of all, I am pleased LTANS did produce one of the first discussable drafts. Thanks. The same for me. In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management". Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself). I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored. Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand) User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems... I see the authentication problem quite similar and have at the moment not the optimal solution for it. :( On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied. On the other hand how can one achieve authentication across very long times spans of decades ? Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.) [see also page 9 bottom: "protocol should permit encryption of data before submission..." ] On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy? It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5] Hope this will trigger some discussion... Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....) For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list. Regards Tobias ------_=_NextPart_001_01C3E4F8.A54F3600 Content-Type: text/html Message
Dear Aleksej,
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first discussable drafts.
 
Thanks. The same for me.
In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time  (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management".  
Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself).
I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... 
For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored.
 
Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. 
 
Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand)
User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems...
 
I see the authentication problem quite similar and have at the moment not the optimal solution for it. :(
On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied.
On the other hand how can one achieve authentication across very long times spans of decades ?
 
Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.)
[see also page 9 bottom: "protocol should permit encryption of data before submission..." ]
 On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy?
It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5]
Hope this will trigger some discussion...
 
Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....)
 
For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list.
 
Regards
 
    Tobias
 
------_=_NextPart_001_01C3E4F8.A54F3600-- From owner-ietf-ltans Tue Jan 27 10:20:31 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIKU6N046948; Tue, 27 Jan 2004 10:20: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 i0RIKUfD046947; Tue, 27 Jan 2004 10:20:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIKQXe046936 for ; Tue, 27 Jan 2004 10:20:29 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0RIKLqC019146 for ; Tue, 27 Jan 2004 19:20:21 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 19:20:42 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? Date: Tue, 27 Jan 2004 19:20:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E502.40D91650" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E502.40D91650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA: This name "Trusted" is somehow confusing for me. For me "Trusted" = implies that the archive is a somehow trusted third party that needs some = evalutions by some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous). Of course the documents have to be stored and it has to be taken care = that the needed steps of resigning are taken but all this is normal = business. For that I would prefer if we could change the names from : "Trusted Archiving" to "Archiving"=20 And from: "Trusted Archive Authority" to "Archive Authority" or = "Archive Service" Best regards Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/M=FCnchen E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com =20 Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C3E502.40D91650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Initial requirements for long-term archive I-D - wording: = Trusted archiving ?

Hello,

I would like to discuss in section 2 = "Terminology" the name "Trusted Archiving" and = TAA:

This name "Trusted" is = somehow confusing for me. For me "Trusted" implies that the = archive is a somehow trusted third party that needs some evalutions by = some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the = trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous).

Of course the documents have to be = stored and it has to be taken care that the needed steps of resigning = are taken but all this is normal business.

For that I would prefer if we could = change the names from :

"Trusted Archiving" to = "Archiving"
And from: "Trusted Archive = Authority" to "Archive Authority" or "Archive = Service"

Best regards

        Tobias




Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may = contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the sender immediately and destroy this eMail. Any use, disclosure or = distribution of the material in this eMail is strictly = forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie bitte sofort den Absender und vernichten Sie diese = eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe = ist nicht gestattet.

------_=_NextPart_001_01C3E502.40D91650-- From owner-ietf-ltans Tue Jan 27 10:33:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIXv62047866; Tue, 27 Jan 2004 10:33:57 -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 i0RIXvnq047865; Tue, 27 Jan 2004 10:33:57 -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.8) with ESMTP id i0RIXtmf047856 for ; Tue, 27 Jan 2004 10:33:55 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA19930; Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIXoN05349; Tue, 27 Jan 2004 19:33:50 +0100 (MET) Date: Tue, 27 Jan 2004 19:33:50 +0100 (MET) From: Peter Sylvester Message-Id: <200401271833.i0RIXoN05349@chandon.edelweb.fr> To: aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej 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: As suggested, I just take a subpart of the messages and add some centimes in a brain storming way. > User authentication is another problem in wide scale deployment of archive > services. Bearing in mind that privacy is one of the (more and more) > important factor in open infrastructure, confidentiality is even more > important in case of formal content handling (contracts, invoices!!). > Furthermore, DVCS exposes the content to authority at least, and has serious > confidentiality problems... If you think about a chain of a notary that validates formal content and then needs to store the data at some external service, there is no formal way to ensure either encryption or splitting so that the assertions from the backend service can be matched with the statement from the notary. Needs some work ... > I see the authentication problem quite similar and have at the moment not > the optimal solution for it. :( User authentication doesn't seem for me a particular problem for the archive service, it may or may not be a problem for any large scale service. That's why I think we should not try and mandate a particular way but allow for different techniques, including: - Access control on the transport level (e.g. SSL). - Signatures in order to keep some proof. - asynchronous staged processing for certain operations where requests need to be confirmed by someone else. The meaning of 'Optimal' depends on the goals. > On the one side you have to be able to store data and with this the > retrieval has to authenticated and access control has somehow to be applied. > > On the other hand how can one achieve authentication across very long times > spans of decades ? Isn't Authentication 'at distance' but not 'in time'. But we talk about authorisation? It may be necessary to handle in some way particular roles like 'a judge/relevant authority' and then the access control may require some 'entitlement'. This entity from the fiscal service is entitled to access to data from company identified by XXX'. how these meachnisms are implement now or in future is not in our scope, I think what remains is that the exchanged and stored information contain sufficient 'metadata' indicating to whom the belong using good identifiers. Either a client should explicitely set some identifiers in requests, which need then matched against the authenticated client id, or they are added by the server based on the client id or maybe additional parameters in the request. > Confidentiality is something that will be probably one of the very important > issues when independent Archive Providers want to offe this service to end > users and smaller companies. (One mechanism I could imagine is that the > users are submitting encrypted data/documents and solve most of there urgent > problems with that.) To what degree do you trust your provider of the operating system and the machine processor to not have a backdoor in the system which will be activated when things happen in a environment of a 'competitor'. Encryption may be a solution for short term, otherwise in real paranoia you need to physically split the data and store then at places where you are reasonably sure that the operators cannot cheat together without leaving some trace. There are also various possible combinations of in/out-sourcing. what seems important is that the provider/operator of the service has an auditable system in a very large sense. From owner-ietf-ltans Tue Jan 27 10:42:02 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIg2cr048474; Tue, 27 Jan 2004 10:42:02 -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 i0RIg2d5048473; Tue, 27 Jan 2004 10:42:02 -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.8) with ESMTP id i0RIfw4g048464 for ; Tue, 27 Jan 2004 10:42:01 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA19969; Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIfv105360; Tue, 27 Jan 2004 19:41:57 +0100 (MET) Date: Tue, 27 Jan 2004 19:41:57 +0100 (MET) From: Peter Sylvester Message-Id: <200401271841.i0RIfv105360@chandon.edelweb.fr> To: ietf-ltans@imc.org, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > This name "Trusted" is somehow confusing for me. For me "Trusted" implies > that the archive is a somehow trusted third party that needs some evalutions > by some government authority. I don't think that such is necessary. All the > mechanisms to ensure the integrity of the data can be based on the > trustworthyness of the TSP (that has to be a trusted third party as changing > e.g. the time of the server would be disasterous). You loose integrity of data when you loose the data. I guess you need to trust that the archive service 'does its best'. From owner-ietf-ltans Tue Jan 27 11:10:37 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJAbdr050374; Tue, 27 Jan 2004 11:10:37 -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 i0RJAbPT050373; Tue, 27 Jan 2004 11:10:37 -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.8) with ESMTP id i0RJAXto050366 for ; Tue, 27 Jan 2004 11:10:34 -0800 (PST) (envelope-from paul-andre.pays@edelweb.fr) Received: from edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA20324; Tue, 27 Jan 2004 20:10:32 +0100 (MET) Received: from edelweb.fr (pap2002.edelweb.fr [193.51.14.21]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 20:10:32 +0100 (MET) Message-ID: <4016B7B3.8090605@edelweb.fr> Date: Tue, 27 Jan 2004 20:10:43 +0100 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? References: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070309030606060405030308" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070309030606060405030308 Content-Type: multipart/alternative; boundary="------------080302060304000808090501" This is a multi-part message in MIME format. --------------080302060304000808090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable My 2 cts, * on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party=20 (no capital letters, but 100% independant from B). * on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "*trusted archiving*" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party". In short, I feel confortable with today terminology as long as a=20 glossary is provided which explains the semantic attached to each of=20 these terms (for example along the line of my above understanding), and=20 pinpoints the fact that the actual official nature (appropriately=20 separate archival service in some cases, effective trusted third party=20 in others) is completely context dependant. The context is the legal=20 context with the requirements for "evidence creation". LTANS should focus on technical solutions and not on these "legal"=20 environments. I you consider that the term "trusted" conveys too much third party=20 meening, I would accept "reliable archive" as long as it is explained=20 that reliable is not only related technical reliability but also=20 includes the appropriate independance (buwinesswise and legaly wise) -- PAP Tobias Gondrom wrote: > Hello, > > I would like to discuss in section 2 "Terminology" the name "Trusted=20 > Archiving" and TAA: > > This name "Trusted" is somehow confusing for me. For me "Trusted"=20 > implies that the archive is a somehow trusted third party that needs=20 > some evalutions by some government authority. I don't think that such=20 > is necessary. All the mechanisms to ensure the integrity of the data=20 > can be based on the trustworthyness of the TSP (that has to be a=20 > trusted third party as changing e.g. the time of the server would be=20 > disasterous). > > Of course the documents have to be stored and it has to be taken care=20 > that the needed steps of resigning are taken but all this is normal=20 > business. > > For that I would prefer if we could change the names from : > > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or=20 > "Archive Service" > > Best regards > > Tobias > > > > > Tobias Gondrom > Senior Software Architect > Engineering > > *IXOS Software AG* > Technopark Neukeferloh > Bretonischer Ring 12 > D-85630 Grasbrunn/M=FCnchen > > E-Mail:_ __Tobias.Gondrom@ixos.de_ > WWW:_ __http://www.ixos.com_ > Tel: +49-89-4629-1816 > Fax: +49-89-4629-33-1816 > > This eMail may contain confidential and/or privileged information. If=20 > you are not the intended recipient or have received this eMail in=20 > error, please notify the sender immediately and destroy this eMail.=20 > Any use, disclosure or distribution of the material in this eMail is=20 > strictly forbidden. > > Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte=20 > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese=20 > eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den=20 > Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung,=20 > Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. > --=20 Paul-Andr=E9 PAYS pays@edelweb.fr ou papays@on-x.com Directeur EdelWeb & P=F4le S=E9curit=E9 Groupe ON-X http://www.edelweb.fr/ http://www.on-x.com/ tel: +33 1 40 99 29 55 fax : +33 1 40 99 03 30 ----- Pour v=E9rifier la signature : https://www.openevidence.org/OEROOT-ca.der= --------------080302060304000808090501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My 2 cts,

  • on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party  (no capital letters, but 100% independant from B).
  • on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "trusted archiving" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party".
In short, I feel confortable with today terminology as long as a glossary is provided which explains the semantic attached to each of these terms (for example along the line of my above understanding), and pinpoints the fact that the actual official nature (appropriately separate archival service in some cases, effective trusted third party in others) is completely context dependant. The context is the legal context with the requirements for "evidence creation".
LTANS should focus on technical solutions and not on these "legal" environments.
I you consider that the term "trusted" conveys too much third party meening, I would accept "reliable archive" as long as it is explained that reliable is not only related technical reliability but also includes the appropriate independance (buwinesswise and legaly wise)

-- PAP


Tobias Gondrom wrote:
RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ?

Hello,

I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA:

This name "Trusted" is somehow confusing for me. For me "Trusted" implies that the archive is a somehow trusted third party that needs some evalutions by some government authority. I don't think that such is necessary. All the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as changing e.g. the time of the server would be disasterous).

Of course the documents have to be stored and it has to be taken care that the needed steps of resigning are taken but all this is normal business.

For that I would prefer if we could change the names from :

"Trusted Archiving" to "Archiving"
And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service"

Best regards

        Tobias




Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/München

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden.

Diese eMail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielfältigung oder Weitergabe ist nicht gestattet.


-- 
Paul-André PAYS                 pays@edelweb.fr   ou  papays@on-x.com
Directeur 			EdelWeb & Pôle Sécurité Groupe ON-X
http://www.edelweb.fr/          http://www.on-x.com/
tel: +33 1 40 99 29 55          fax : +33 1 40 99 03 30
-----
Pour vérifier la signature : https://www.openevidence.org/OEROOT-ca.der
--------------080302060304000808090501-- --------------ms070309030606060405030308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCC AvgwggHgoAMCAQICBD7XZsYwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCV1cxFTATBgNV BAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGljaXBhbnRzIEF1dGhvcml0eTAeFw0w MzA1MzAxNDEyMzJaFw0wNDEwMTExNDEyMzJaMCgxCzAJBgNVBAYTAk5OMRkwFwYDVQQDFBBQ YXVsLUFuZHLDqSBQQVlTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtYu5hSua01K5B b63LMSSr/Tr2MQKjDRzEojvW/6tckP0sjJu7pOOCEvXca8EMUNRT4wF5ss/hOA2Mhn9gQsya kdimzAhLyX/2DxwXESlCCIC9JNPK3H9YZPSTspY4922XPR9np5brErHjw9B9ll474YLg1abi 5xpq+HQ2D/pcgQIDAQABo4GQMIGNMCUGA1UdEQQeMByBGnBhdWwtYW5kcmUucGF5c0BlZGVs d2ViLmZyMDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwBIYcaHR0cHM6Ly93d3cub3BlbmV2 aWRlbmNlLm9yZzALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MA0GCSqGSIb3DQEBBAUAA4IBAQCzdZBQHrV+iuyxyP7YSVCsUKgOhXKwYfV1BKl+1bJvw11L rZzUmGaPrg0BUm3ETqrtEzvMq7yXkPUfRaDoEy0pmbRszvDPGjNKaGrP3/JaH9bXJtKxC1er 8ewCxCNcXH4mZwUhITUyHUoA6cSoShcW/elhbGQWhVnsxUHy82A4cFOH/G4lhVE9/tpnLOKS S1jmuW08Ic8/o4VUKeJlv3z7+Q+lyYQpbSpKs/N3qiAz7yhbeWU6GAOaX+iY9tTm2T1wXK69 72uqZbp31sxAlFjs/2q7FGk2FCwb/Pst20aUM4dDauK+vi5FV9XokI80YH/IpMxO+T+o+sPu Zh4TnrohMIIC+DCCAeCgAwIBAgIEPtdmxjANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJX VzEVMBMGA1UEChMMT3BlbkV2aWRlbmNlMR8wHQYDVQQDExZQYXJ0aWNpcGFudHMgQXV0aG9y aXR5MB4XDTAzMDUzMDE0MTIzMloXDTA0MTAxMTE0MTIzMlowKDELMAkGA1UEBhMCTk4xGTAX BgNVBAMUEFBhdWwtQW5kcsOpIFBBWVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK1i 7mFK5rTUrkFvrcsxJKv9OvYxAqMNHMSiO9b/q1yQ/SyMm7uk44IS9dxrwQxQ1FPjAXmyz+E4 DYyGf2BCzJqR2KbMCEvJf/YPHBcRKUIIgL0k08rcf1hk9JOyljj3bZc9H2enlusSsePD0H2W XjvhguDVpuLnGmr4dDYP+lyBAgMBAAGjgZAwgY0wJQYDVR0RBB4wHIEacGF1bC1hbmRyZS5w YXlzQGVkZWx3ZWIuZnIwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzAEhhxodHRwczovL3d3 dy5vcGVuZXZpZGVuY2Uub3JnMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwDQYJKoZIhvcNAQEEBQADggEBALN1kFAetX6K7LHI/thJUKxQqA6FcrBh9XUE qX7Vsm/DXUutnNSYZo+uDQFSbcROqu0TO8yrvJeQ9R9FoOgTLSmZtGzO8M8aM0poas/f8lof 1tcm0rELV6vx7ALEI1xcfiZnBSEhNTIdSgDpxKhKFxb96WFsZBaFWezFQfLzYDhwU4f8biWF UT3+2mcs4pJLWOa5bTwhzz+jhVQp4mW/fPv5D6XJhCltKkqz83eqIDPvKFt5ZToYA5pf6Jj2 1ObZPXBcrr3va6plunfWzECUWOz/arsUaTYULBv8+y3bRpQzh0Nq4r6+LkVX1eiQjzRgf8ik zE75P6j6w+5mHhOeuiEwggNAMIICKKADAgECAgcQIHgomHZRMA0GCSqGSIb3DQEBBAUAMDgx CzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxEjAQBgNVBAMTCUF1dGhvcml0 eTAeFw0wMjA1MDcxNDQ4MjFaFw0xMjA1MDQxNDQ4MjFaMEUxCzAJBgNVBAYTAldXMRUwEwYD VQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRZ0ovIMoH0rNd3Kh5108NViqZ3OkpU4Ze 1EkvwSEMab+tpLKPxijhM8fHW89W1ZvCRPfNvGyliDavK/rwp2EeeB0POTBjxjuHkYsFjFgE pAU2qpiikptBd0K5HvtYDksIapCTbzBB5/77Kh+X8g7NxETqt7rZDTnns0VmJrJGI/6m8GUP FEPV0ulDwOEk4uutdPE4vNkadAbe8OrBVhMgVs5M0Y6/wCYDt7tzu3dUWi6cws7PQiFFjEI1 N0LHaR7kcODOOoJSNG6WuQmRQRZGRQqYsE9316DpEqEOYpXjxLtj9TI1HmrYtJjeDRdNM7qV MgCdhhMc6DjqD+9pf0yFAgMBAAGjQjBAMA8GA1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBSwGAKKzw/hQilrVrPW1UxszLdAWzANBgkqhkiG9w0BAQQFAAOCAQEA +D1M7ixKqQ7eN3HsXl9+dULna7sMZ07/7AnGgHjIltM7oelpftJUwW2/zHUaTxy9sxSXiKTr fuTxwvNOANQN6BM1h0EJxSqYiKyRzzxYCohmfgllStIU3U3Q+mCvaUma5FLhzBfkfOk/VtFy 6jK+6WqUluftBtx7/gXmvA8fbtcxcvTJ80rQHM+bR26VQhPwVXUP7k5ED8EBVee2TUa/117B 6lFQAL3V4XJuRVUJ+UMUAJBc7VN/eJfPOOpTn3l+gMuhoSZP+oLEXG1+eTK/ht8kjo+jXZPV Op+G0tVXibWmepsTHj+ahH6b7u4/Zbe6V2M4H2L+rhRahM0/7BwUtzGCAmYwggJiAgEBME0w RTELMAkGA1UEBhMCV1cxFTATBgNVBAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGlj aXBhbnRzIEF1dGhvcml0eQIEPtdmxjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAxMjcxOTEwNDNaMCMGCSqGSIb3DQEJBDEW BBSqJJNNrvysQxk0a+YUja1A/S0FRzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBc BgkrBgEEAYI3EAQxTzBNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2Ux HzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwXgYLKoZIhvcNAQkQAgsx T6BNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBh cnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwDQYJKoZIhvcNAQEBBQAEgYA23Zr7+yEn/2Ql UIPx2Icq0GIMPvsdHY5xCs8LA+P+knQUqRjhyDFjmxjUl+69gLe4IExuOES2URkooFTX+B3R u/KoDSDKcoX2YpET9iyE/7rOmf3To1NG7yXprl5rK0NMarM+UEiVDWm4Pj7UavU9vbW0Q1+S BOkMq64g602iWQAAAAAAAA== --------------ms070309030606060405030308-- From owner-ietf-ltans Tue Jan 27 11:22:44 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJMicq051109; Tue, 27 Jan 2004 11:22: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 i0RJMibK051108; Tue, 27 Jan 2004 11:22:44 -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.8) with ESMTP id i0RJMcZC051101 for ; Tue, 27 Jan 2004 11:22:39 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-141-156-225-56.res.east.verizon.net [141.156.225.56]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0RJMdh2025494; Tue, 27 Jan 2004 14:22:39 -0500 From: "Carl Wallace" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Tue, 27 Jan 2004 14:22:40 -0500 Message-ID: <002401c3e50a$ee8f0590$6601a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > For that I would prefer if we could change the names from : > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service" The word "trusted" provides a hint that something more than simple storage of the data is going on (even if the actual trust is in the TSA). Also, an Archive Authority must be trusted if it is providing trust anchor information. From owner-ietf-ltans Wed Jan 28 05:25:24 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDPOdW028250; Wed, 28 Jan 2004 05:25:24 -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 i0SDPO43028249; Wed, 28 Jan 2004 05:25:24 -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.8) with ESMTP id i0SDPMel028234 for ; Wed, 28 Jan 2004 05:25:23 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id OAA04449; Wed, 28 Jan 2004 14:25:05 +0100 (MET) Message-ID: <4017B89E.4010801@sit.fraunhofer.de> Date: Wed, 28 Jan 2004 14:26:54 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl Wallace CC: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ? References: <002401c3e50a$ee8f0590$6601a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl Wallace wrote: >>For that I would prefer if we could change the names from : >>"Trusted Archiving" to "Archiving" >>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive > > Service" > > The word "trusted" provides a hint that something more than simple storage > of the data is going on (even if the actual trust is in the TSA). Also, an I agree. The differentiation between a simple archive service (only document storage) and an archive service that obtains evidence of document existence is important. > Archive Authority must be trusted if it is providing trust anchor > information. I am not sure I follow this point. What would this trust anchor information be? Regards, Brian From owner-ietf-ltans Wed Jan 28 05:41:14 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDfEr1029083; Wed, 28 Jan 2004 05:41:14 -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 i0SDfERi029081; Wed, 28 Jan 2004 05:41:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDfBKT029074 for ; Wed, 28 Jan 2004 05:41:12 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDf3aL025070; Wed, 28 Jan 2004 14:41:04 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:41:26 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5319@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - Confidentiality Date: Wed, 28 Jan 2004 14:41:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Confidentiality is something that will be probably one of the very > > important issues when independent Archive Providers want to offe this > > service to end users and smaller companies. (One mechanism I could > > imagine is that the users are submitting encrypted data/documents and > > solve most of there urgent problems with that.) > > To what degree do you trust your provider of the operating > system and the machine processor to not have a backdoor in > the system which will be activated when things happen in a > environment of a 'competitor'. My personal answer would be to trust only things that can be evaluated and that are actually evaluated (e.g. source from LINUX, large community working with Windows and ISV-Firewalls). In general I would say that customers rely on the reputation of a system, on results of independent tests (including hackers and audits) and some of the promises of the provider. > Encryption may be a solution for short term, otherwise in > real paranoia you need to physically split the data and store > then at places where you are reasonably sure that the > operators cannot cheat together without leaving some trace. > There are also various possible combinations of > in/out-sourcing. what seems important is that the > provider/operator of the service has an auditable system in a > very large sense. Maybe Peter is right and you simply have to trust your provider. :-/ (at least you have a contract and probably pay your provider for the service and the provider could gain some additional trust by independent audits) Still I am very sure we have to provide the ability to store (and provide evidence for) encrypted data. For many people this will be the first way to trust an external provider. (And in some countries it might also be forbidden to let the data even only theoretically be accessible to other persons) From owner-ietf-ltans Wed Jan 28 05:53:54 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDrseD030452; Wed, 28 Jan 2004 05:53: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 i0SDrsle030451; Wed, 28 Jan 2004 05:53:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDrpfL030445 for ; Wed, 28 Jan 2004 05:53:52 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDrjOB025703; Wed, 28 Jan 2004 14:53:46 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:54:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D531A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Wed, 28 Jan 2004 14:54:02 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As suggested, I just take a subpart of the messages and add > some centimes in a brain storming way. > > > User authentication is another problem in wide scale deployment of > > archive services. Bearing in mind that privacy is one of the (more and > > more) important factor in open infrastructure, confidentiality is even > > more important in case of formal content handling (contracts, > > invoices!!). > > > Furthermore, DVCS exposes the content to authority at least, and has > > serious confidentiality problems... > > If you think about a chain of a notary that validates formal > content and then needs to store the data at some external > service, there is no formal way to ensure either encryption > or splitting so that the assertions from the backend service > can be matched with the statement from the > notary. Needs some work ... > > > I see the authentication problem quite similar and have at the moment > > not the optimal solution for it. :( > > User authentication doesn't seem for me a particular problem > for the archive service, it may or may not be a problem for > any large scale service. > > That's why I think we should not try and mandate a > particular way but allow for different techniques, including: > > - Access control on the transport level (e.g. SSL). > - Signatures in order to keep some proof. > - asynchronous staged processing for certain operations > where requests need to be confirmed by someone else. > > The meaning of 'Optimal' depends on the goals. I agree with you Peter. Seems to be better to allow authentication but we don't need to specify the used technique so that different services are free to implement what fits best. > > On the one side you have to be able to store data and with this the > > retrieval has to authenticated and access control has somehow to be > > applied. > > > > On the other hand how can one achieve authentication across very long > > times spans of decades ? > > Isn't Authentication 'at distance' but not 'in time'. Basically I see a problem concerning the time too. The methods of authentification may change during the lifetime of a document (even more than once). And with that you might get problems. Let's e.g. say you archived a contract about your newly bought house or something and used at the beginning user/password authentication. For the next 20 years you are basically probably not interested in the document and might even forget your password, although you still have the URL of the document with all the evidence records. In the future maybe even user/password authentication is no longer accepted by the server so you need something different - but what is important for the system: are you the same person that stored the document 20 years ago ? > But we talk about authorisation? It may be necessary to handle in > some way particular roles > like 'a judge/relevant authority' and then the access control > may require some 'entitlement'. This entity from the fiscal > service is entitled to access to data from company identified > by XXX'. how these meachnisms are implement now or in future > is not in our scope, I think what remains is that the > exchanged and stored information contain sufficient > 'metadata' indicating to whom the belong using good identifiers. > Either a client should explicitely set some identifiers in > requests, which need then matched against the authenticated > client id, or they are added by the server based on the > client id or maybe additional parameters in the request. Authorisation: In my understanding authorisation comes after some kind of authentication (i.e. at first you know the identity of the other and then you think about to allow him access to the data). A role based access control seems feasable and hopefully not to complicated. (Maybe added with some sercret (document id ?) generated at the time of storage.) The "judge/relevant authority" is of course on. A second one will be the user who stored the data. (Of course he wants to be able to receive the evidence and maybe even the data he stored.) Small remark: If the trusted archive does not provide the data itself to normal requests, the authorisation topic might be easy, as I think the retrieval of evidence to a document might not be a security issue. The request for evidence could contain either the data or a hash-value of the data (as long as the hash-algorithm is still secure). From owner-ietf-ltans Wed Jan 28 06:16:05 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEG58c031639; Wed, 28 Jan 2004 06:16: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 i0SEG5MW031638; Wed, 28 Jan 2004 06:16:05 -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.8) with ESMTP id i0SEG3qO031631 for ; Wed, 28 Jan 2004 06:16:03 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-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 i0SEG4h2021817; Wed, 28 Jan 2004 09:16:04 -0500 From: "Carl Wallace" To: "'Brian Hunter'" Cc: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Wed, 28 Jan 2004 09:15:59 -0500 Message-ID: <000701c3e5a9$43b7ab50$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4017B89E.4010801@sit.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SEG4qO031632 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Archive Authority must be trusted if it is providing trust > anchor > information. > > I am not sure I follow this point. What would this trust anchor > information be? When verifying signatures that accrue over time, trust anchors may be necessary that are not active at the time of verification. An archive could serve as a repository for past trust anchors. An archive acting in this capacity would need to be trusted. From owner-ietf-ltans Wed Jan 28 06:52:26 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEqQTk034198; Wed, 28 Jan 2004 06:52:26 -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 i0SEqQE0034197; Wed, 28 Jan 2004 06:52:26 -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.8) with ESMTP id i0SEqO9r034191 for ; Wed, 28 Jan 2004 06:52:24 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA29343; Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0SEqMK07506; Wed, 28 Jan 2004 15:52:22 +0100 (MET) Date: Wed, 28 Jan 2004 15:52:22 +0100 (MET) From: Peter Sylvester Message-Id: <200401281452.i0SEqMK07506@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > > > Isn't Authentication 'at distance' but not 'in time'. > > Basically I see a problem concerning the time too. The methods of > authentification may change during the lifetime of a document (even more > than once). And with that you might get problems. > Let's e.g. say you archived a contract about your newly bought house or > something and used at the beginning user/password authentication. For the > next 20 years you are basically probably not interested in the document and > might even forget your password, although you still have the URL of the > document with all the evidence records. In the future maybe even > user/password authentication is no longer accepted by the server so you need > something different > - but what is important for the system: are you the same person that stored > the document 20 years ago ? Even with user/password you don't make a proof that you are the person that stored, only that some accesses who knows these values. There is a difference betwenn identification and authentication. The 'user' is not your 'identification', but an means for authentication. You long term identification are the data on your birth certificate; thus, when you register to such a service, you have probably always to provide some information about who you are, a copy of your national id card or whatever. This identification (potentially in an anonymous form) is then associated by the provider with some authentication method: You get a user/password. 20 years later (and even earlier) you should be able to provide the same identification information (or better, the the id of your grandparents) to access. > > Authorisation: > In my understanding authorisation comes after some kind of authentication > (i.e. at first you know the identity of the other and then you think about > to allow him access to the data). > A role based access control seems feasable and hopefully not to complicated. > (Maybe added with some sercret (document id ?) generated at the time of > storage.) > > The "judge/relevant authority" is of course on. > A second one will be the user who stored the data. (Of course he wants to be > able to receive the evidence and maybe even the data he stored.) You almost never have the situation that some data only belongs to one person durng a long period in time. The most simplistic authorisation model which just has a 1=1 correspondance is not sufficient. You can die at any moment, you can delegate your power to someone else at any time etc. > Small remark: If the trusted archive does not provide the data itself to > normal requests, the authorisation topic might be easy, as I think the > retrieval of evidence to a document might not be a security issue. The > request for evidence could contain either the data or a hash-value of the > data (as long as the hash-algorithm is still secure). A not so small response :-) A request to an archiver may live the following way: - someone has archived data and received an attestions that contains the relevant metadata like: "Person XYZ has archived a contract between A, B, C concerning xxx at date D in the city of L conforming to law ZZZ and application degree GGG etc. The concerned parties are fiscally related to FFF. The content of the document has the hash H1 with hashes h2 to Hn for the chapters 2 to n", all that (most likely), digitally signed by the archive provider at the moment you receive it. - the digital signature can be confirmed with a hash link to a published daily hash next day or there is an ability to present the attestation to the archive provider asking whether this attestation is a good one by looking at his archive log. - If the relying parties can't agree, or when this is a fiscal control, etc a service needs to return the data. For this case one cannot depend on the good will of the initial client if the archived data are not in favor of his claim. Thus, a judge or even the other party may access. This may bring us to a requieremnt where the initial archiver should be able to indicate "identification information" of all the potential concerned relying parties. This identification information can be persons or companies, but also "done at Paris" in order to indicate that a judge in some court in Paris may access. (If hash algs are not secure, you still have physical copies that are dated.) From owner-ietf-ltans Thu Jan 29 02:20:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TAKREd094158; Thu, 29 Jan 2004 02:20:27 -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 i0TAKRMp094157; Thu, 29 Jan 2004 02:20:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0TAKPIW094138 for ; Thu, 29 Jan 2004 02:20:25 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 19210 invoked from network); 29 Jan 2004 10:14:44 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:44 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 17829-09 for ; Thu, 29 Jan 2004 11:14:25 +0100 (CET) Received: (qmail 19176 invoked from network); 29 Jan 2004 10:14:25 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:25 -0000 From: "A. Jerman Blazic" To: "'Peter Sylvester'" , Cc: Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Thu, 29 Jan 2004 11:21:58 +0100 Message-ID: <006301c3e651$b9e1ac60$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200401281452.i0SEqMK07506@chandon.edelweb.fr> Importance: Normal X-Virus-Scanned: by amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > > > Isn't Authentication 'at distance' but not 'in time'. > > > > Basically I see a problem concerning the time too. The methods of > > authentification may change during the lifetime of a document (even > > more than once). And with that you might get problems. > Let's e.g. say > > you archived a contract about your newly bought house or > something and > > used at the beginning user/password authentication. For the next 20 > > years you are basically probably not interested in the document and > > might even forget your password, although you still have the URL of > > the document with all the evidence records. In the future > maybe even > > user/password authentication is no longer accepted by the server so > > you need something different > > - but what is important for the system: are you the same > person that > > stored the document 20 years ago ? > > Even with user/password you don't make a proof that you are > the person that stored, only that some accesses who knows > these values. > > There is a difference betwenn identification and authentication. > > The 'user' is not your 'identification', but an means for > authentication. You long term identification are the data on > your birth certificate; thus, when you register to such a > service, you have probably always to provide some information > about who you are, a copy of your national id card or whatever. > > This identification (potentially in an anonymous form) is then > associated by the provider with some authentication method: > You get a user/password. 20 years later (and even earlier) you > should be able to provide the same identification information > (or better, the the id of your grandparents) to access. I agree with peter completely. I also think one needs to clarify what procedures are we discussing about. Authorization is something that gives you power (or not) to access or use something. While identification is something else. So in case of archival services authorization is seen through rights to use the service or not (and of course the level of usage). However we still must keep the fact in mind that whatever we are archiving always belongs to somebody (something??). So the major question is: who has the rights to access the archived item? And after that: how do we identify the person with the acess rights? I think this should be clarified before we can even discuss the operational steages of the service. My wiev is, that this two main functions might be separated (although tightly corelated to the service), i.e. an authority identifying subjects in an open environment or mapping the rights to a subject. For example, as Peter stated, if I put something in the archive on behalf of my company, who will access the same archive once I change my job? Where are the connections between former and present employee? Aleksej > > > > Authorisation: > > In my understanding authorisation comes after some kind of > authentication > > (i.e. at first you know the identity of the other and then > you think about > > to allow him access to the data). > > > A role based access control seems feasable and hopefully not to > > complicated. (Maybe added with some sercret (document id ?) > generated > > at the time of > > storage.) > > > > The "judge/relevant authority" is of course on. > > A second one will be the user who stored the data. (Of > course he wants to be > > able to receive the evidence and maybe even the data he stored.) > > You almost never have the situation that some data only > belongs to one person durng a long period in time. The most > simplistic authorisation model which just has a 1=1 > correspondance is not sufficient. You can die at any moment, > you can delegate your power to someone else at any time etc. > > > Small remark: If the trusted archive does not provide the > data itself > > to normal requests, the authorisation topic might be easy, > as I think > > the retrieval of evidence to a document might not be a > security issue. > > The request for evidence could contain either the data or a > hash-value > > of the data (as long as the hash-algorithm is still secure). > > A not so small response :-) > > A request to an archiver may live the following way: > > - someone has archived data and received an attestions that > contains the relevant metadata like: > "Person XYZ has archived a contract between A, B, C concerning xxx > at date D in the city of L conforming to law ZZZ and application > degree GGG etc. The concerned parties are fiscally related to FFF. > > The content of the document has the hash H1 with hashes h2 to Hn > for the chapters 2 to n", > all that (most likely), digitally signed by the archive provider > at the moment you receive it. > > - the digital signature can be confirmed with a hash link to > a published daily hash next day or there is an ability to present > the attestation to the archive provider asking whether this > attestation > is a good one by looking at his archive log. > > - If the relying parties can't agree, > or when this is a fiscal control, etc > a service needs to return the data. For this case > one cannot depend on the good will of the initial > client if the archived data are not in favor of his > claim. Thus, a judge or even the other party may > access. This may bring us to a requieremnt where > the initial archiver should be able to indicate > "identification information" of all the > potential concerned relying parties. This > identification information can be persons or > companies, but also "done at Paris" in order > to indicate that a judge in some court in Paris > may access. > > (If hash algs are not secure, you still have physical copies > that are dated.) > > > > > From owner-ietf-ltans Thu Jan 29 03:36:42 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBaf2s001784; Thu, 29 Jan 2004 03:36:41 -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 i0TBafPB001783; Thu, 29 Jan 2004 03:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gilmore.ael.be (gilmore.ael.be [158.64.60.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBadhG001766 for ; Thu, 29 Jan 2004 03:36:39 -0800 (PST) (envelope-from adulau@foo.be) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id 3CCFB17347F; Thu, 29 Jan 2004 12:39:02 +0100 (CET) Received: by gilmore.ael.be (Postfix, from userid 519) id B814417347F; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id B258E17F402; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Date: Thu, 29 Jan 2004 12:39:01 +0100 (CET) From: Alexandre Dulaunoy X-X-Sender: adulau-conos@gilmore.ael.be To: "A. Jerman Blazic" Cc: "'Peter Sylvester'" , , Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication In-Reply-To: <006301c3e651$b9e1ac60$1b018ac1@arthur> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=7.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,WEIRD_PORT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004, A. Jerman Blazic wrote: > > This identification (potentially in an anonymous form) is then > > associated by the provider with some authentication method: > > You get a user/password. 20 years later (and even earlier) you > > should be able to provide the same identification information > > (or better, the the id of your grandparents) to access. > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. Yes, you are right. Just for an example, the freearchive.org is setting up and the authorization is working on two methods : - An open approach (as we gather free works) with a manual verification of the work (on the legal (if the work is free) and technical side (if the work permits a long-term storage)). - An authenticated approach where the manual verification is bypassed as the submission is coming from trusted sources (can be people or other digital repositories with an OAI or alike interface). On the two methods, an unique ID is generated by the repository for tracking the life of the digital work. Freearchive is a specific case where all work are frees and can be distributed without any restrictions. I think, this approach is well-known in various public domain digital libraries. I don't know if you can take this easily in the draft document. For the operational stages that seem more complicated to explain. Thanks a lot for your work, adulau -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov From owner-ietf-ltans Thu Jan 29 04:08:43 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TC8hSW004505; Thu, 29 Jan 2004 04:08: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 i0TC8hTo004504; Thu, 29 Jan 2004 04:08: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.8) with ESMTP id i0TC8fXc004489 for ; Thu, 29 Jan 2004 04:08:42 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA10061; Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0TC8Yt10628; Thu, 29 Jan 2004 13:08:34 +0100 (MET) Date: Thu, 29 Jan 2004 13:08:34 +0100 (MET) From: Peter Sylvester Message-Id: <200401291208.i0TC8Yt10628@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). Yes, and it seems that the question is to what degree the payload data are ... let's labelled or tainted with identification, types, roles, locations, etc. Such information need to be grouped in several categories depending on at least three interested parties: - the client itself, delegation of rights to employees or roles - the service (to distinguish groups of users, accounting, etc - other relying parties and external authorities (fiscal identification, locality, jurisdiction, ...) > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. There are many things which seems out of scope of this group. I am not sure whether one has to develop more than containers and type indications for identification data can be provided by/for a requester and for information can be associated to the request and response payloads so that these can be input for some decision making service using things like XACML SAML ... > My wiev is, that this two main functions might be separated (although > tightly corelated to the service), i.e. an authority identifying > subjects in an open environment or mapping the rights to a subject. For > example, as Peter stated, if I put something in the archive on behalf of > my company, who will access the same archive once I change my job? Where > are the connections between former and present employee? Just to remind another point: The authorition decision may not be possible 'on line' (as in many real life cases), thus a request to retrieve or validate cannot necessarily be answered immediately and may need manual intervention. Such a delay is not a problem, since it may be necessary to retrieve some disk from a bunker or else. Peter From owner-ietf-ltans Sat Jan 31 11:39:40 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJde1Z088984; Sat, 31 Jan 2004 11:39:40 -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 i0VJdeYB088983; Sat, 31 Jan 2004 11:39:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJdZSW088965 for ; Sat, 31 Jan 2004 11:39:38 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg1.isp.t-mobile.cz [62.141.25.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VJdX49002556 for ; Sat, 31 Jan 2004 20:39:47 +0100 (MET) From: To: Subject: My objections to the submitted draft Date: Sat, 31 Jan 2004 20:35:25 +0100 Message-ID: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C3E839.CF120370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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_0046_01C3E839.CF120370 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >. > 2. Terminology > . > Timestamp: A signed confirmation generated by a Time Stamping > Authority (TSA) that a data item existed at a certain time. > [RFC3161] specifies a good structure for timestamps and a protocol > for communicating with a Timestamp Authority (TSA). It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps based on the linking hash principle. If we bind time stamp based on linking hash to the archived document, we could give to the court not one but two independent evidences of the document validity. I.e. digital signatures of archived documents would be added with nonsigned attribute - the enhanced time stamp based on other cryptographical principle - the linking hash. The base difference between time stamps based on linking hashes and those acc. to the RFC3161 is the fact that the time stamps based on the RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time stamps based on linking hashes expire when the used hash algorithm proves to be too week, which represents incomparably longer time. . > 3.2 Long-term Archive Service > > A Long-term Archive Service is to be designed to solve essential > parts of these problems by providing a specialized service: > > - The Long-term Archive Service is to store archived data objects > over a long, optionally undefined, period of time. . No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and canceling order which exactly defines the archiving time for every particular document type. (In most countries, it has been already legislated in 19th century.) But many of documents are archived permanently. This is the most complicated problem and the main aim of LTANS should be to solve problems of permanent archiving of digitally signed or timestamped documents. > - The Long-term Archive Service provides material needed to prove the > existence and integrity of data objects for users as well as in > court. The preceding sentence is not consistent with the following sentence: > A Long-term Archive Service is to not be designed to solve all > thinkable problems of long-term-verification of digital signatures. > It does not provide data necessary to verify signatures which are > part of the archived data object itself. This has to be done by > verifiers using PKI-Services like SCVP (Simple Certificate Validation > Protocol) or DVCS (Data Validation and Certification Server). How could the TAA give the evidence about the existence and integrity of a document without the data necessary for the verification of such evidence!? I think that we can discuss many things which the TAA standard should order or recommend, but it is no doubt that the TAA is obliged to give to a user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some type of data store. > This is done, in part, so the archive service can operate without > knowledge of numerous signed data formats, document formats, etc. It > also does not provide any means to integrate verification data in > data objects and verify embedded signatures. This has to be done on > the basis of other specifications, like RFC 3029 and with regard to > specifications of document formats. Of course it is recommended to > use such specifications together with a Long-term Archive Service. In this article of the draft, we can see that it is necessary to separate the draft work into several parallel standards. I.g. it is necessary either to make the RFC3029 into a form of an official standard or to define formats of archiving data. We cannot run the TAA without format specifications. The archive can accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to take care for the archived data formats. Let us have the following example: we have a record of important government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! The suggested draft does not take care about migration and emulation of archived documents. ------ The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. It does not take care for document cataloging, searching of documents, viewing of documents in undistorted form and document canceling. But document canceling seems to be very important archive functionality - it does not mean only destroying of the particular document but in some cases also export of the canceled document into another archive. ---- I am afraid that the submitted draft is only the idea of IT people how to archive documents and it should be discussed with real archivists which have their own idea about archiving. The archivists have a different approach and to create a useful digital archive we should listen to them. We must always keep in mind that the digital archive should offer al least the same services as the paper or parchment archive. Unfortunately the real archivist will decide about law and orders which will enable to replace paper archives with digital ones. Libor ------=_NextPart_000_0046_01C3E839.CF120370 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Zpráva

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.

 

>=20 2. Terminology

>=20 …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It is=20 a bit foolish to build everything on the “classical“ time = stamp.  Realize that the time stamp is = also only=20 a digitally signed structure… I do not understand why this draft = does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it is = not=20 more open to time stamps based on the linking hash principle. If we bind = time=20 stamp based on linking hash to the archived document, we could give to = the court=20 not one but two independent evidences of the document=20 validity.

 

I.e.=20 digital signatures of archived documents would be added with = nonsigned  attribute – the enhanced = time stamp=20 based on other cryptographical principle – the linking hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 expire = with=20 the expiration of their Time Stamping Authority certificate which issued = them=20 (see that we face exactly the same problem we faced in case of digital=20 signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, which=20 represents incomparably longer time.  

…   =20

>=20 3.2    Long-term = Archive=20 Service

>    =20

>   =20 A Long-term Archive Service is to be designed to solve essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>   -=20 The Long-term Archive Service is to store archived data objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for = undefined=20 time period. Every organization has its archiving and canceling order = which=20 exactly defines the archiving time for every particular document type. = (In most=20 countries, it has been already legislated in 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most complicated = problem=20 and the main aim of LTANS should be to solve problems of permanent = archiving of=20 digitally signed or timestamped documents.  

 

>   =20 - The Long-term Archive Service provides material needed to prove = the=20

>   =20 existence and integrity of data objects for users as well as in=20

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital = signatures.  =

>   =20 It does not provide data necessary to verify signatures which are =

>   =20 part of the archived data object itself.  This has to be done by=20

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document=20 without the data necessary for the verification of such evidence!? I = think that=20 we can discuss many things which the TAA standard should order or = recommend, but=20 it is no doubt that the TAA is obliged to give to a user all the = required data=20 necessary for existence and integrity proof of the appropriate document. = Without=20 this function the TAA would be only some type of data=20 store.

 

>   =20 This is done, in part, so the archive service can operate without =

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It =

>   =20 also does not provide any means to integrate verification data in =

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with regard = to=20

>   =20 specifications of document formats. =20 Of course it is recommended to =

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the draft=20 work into several parallel standards. I.g. it is necessary either to = make the=20 RFC3029 into a form of an official standard or to define formats of = archiving=20 data.

 

We=20 cannot run the TAA without format specifications. The archive can accept = only=20 data it can guarantee to be able to view them in undistorted form during = the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important government = meeting=20 stored in the MS Word 3.0. Such document should be archived permanently, = but=20 what to do with the document in MS Word 3.0 format (even now you = probably will=20 have a trouble to view it without distortion!) Obviously, the TAA could = not=20 accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According to=20 this draft, the archive only accepts and returns documents. It does not = take=20 care for document cataloging, searching of documents, viewing of = documents in=20 undistorted form and document = canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I am=20 afraid that the submitted draft is only the idea of IT people how to = archive=20 documents and it should be discussed with real archivists which have = their own=20 idea about archiving. The archivists have a different approach and to = create a=20 useful digital archive we should listen to them.=20

 

We must always keep in mind that the digital = archive=20 should offer al least the same services as the paper or parchment = archive.=20

 

Unfortunately the real archivist will decide = about law=20 and orders which will enable to replace paper archives with digital=20 ones.

 

Libor

------=_NextPart_000_0046_01C3E839.CF120370-- From owner-ietf-ltans Sat Jan 31 13:14:41 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEeUi093678; Sat, 31 Jan 2004 13:14:40 -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 i0VLEeiK093677; Sat, 31 Jan 2004 13:14:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEcJY093666 for ; Sat, 31 Jan 2004 13:14:39 -0800 (PST) (envelope-from marta.vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsh1.isp.t-mobile.cz [62.141.24.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VLF949003358 for ; Sat, 31 Jan 2004 22:15:11 +0100 (MET) From: "Marta.Vohnoutova@pvt.cz" To: Subject: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 22:11:00 +0100 Message-ID: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3E847.226C49B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_0001_01C3E847.226C49B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I am reading the archiving conference very carefuly and I hope that my idea abou attribute certification usage could be useful for your long term archiving standard creation. Identification of a user accessing the archive is interesting problem. But I think it is solved in the RFC-3281 and it is not necessary to specify it more. We should use the RFC-3281 which is of "Standard Track" category. It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree of this structure. It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive will be different (third party archiving service, specialized archive for company or for notaries etc.) Realize that the person storing the document into the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the document into an archive. The archived invoice is owned not by the accountant but by the company. The accountant cannot e.g. delete the invoice in the archive. During the archiving lifetime of the document, an inspection of a state tax office can come. Another company employee must pick up the invoice copy from the archive and submit it for the inspection. When the archived invoice lifetime is over, the invoice must be cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is in bankruptcy, it is required to archive documents later) or put the document for the permanent archiving (e.g. invoice for crown jewelry.) Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's certificate. The conclusion is: we can issue attribute certificates for (in this case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one day because the people roles and access rights can change quickly. The permanent bind of a concrete role to a concrete person does not exist. Cordially Marta Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_0001_01C3E847.226C49B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zpráva
Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I think = it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should use=20 the RFC-3281 which is of „Standard Track“ category. It would = be enough to solve=20 the structure of archived documents because the attribute certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries=20 etc.) Realize that the person storing the document into the archive is = rarely=20 the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant marks=20 the archiving time in the invoice and stores the document into an = archive. The=20 archived invoice is owned not by the accountant but by the company. The=20 accountant cannot e.g. delete the invoice in the archive.=20

 

During the archiving lifetime of the document, = an=20 inspection of a state tax office can come. Another company employee must = pick up=20 the invoice copy from the archive and submit it for the inspection.=20

 

When=20 the archived invoice lifetime is over, the invoice must be cancelled = (destroyed)=20 from the archive. And again another person of the company is responsible = for=20 canceling. This person must decide whether to cancel document or whether = to=20 archive it later (for example, if the company is in bankruptcy, it is = required=20 to archive documents later) or put the document for the permanent = archiving=20 (e.g. invoice for crown = jewelry…)

 

Attribute certificate can vary in time = according to e.g.=20 changes in some database of clients of archive. They are bound with the = user’s=20 certificate. The conclusion is: we can issue attribute certificates for = (in this=20 case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate (view=20 right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day because = the=20 people roles and access rights can change quickly. The permanent bind of = a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta Vohnoutova=20 PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_0001_01C3E847.226C49B0-- From owner-ietf-ltans Sat Jan 31 18:19:55 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112JtM7012474; Sat, 31 Jan 2004 18:19:55 -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 i112Jthm012473; Sat, 31 Jan 2004 18:19:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jste012463 for ; Sat, 31 Jan 2004 18:19:54 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102193611100elag3e>; Sun, 1 Feb 2004 02:19:39 +0000 From: "Santosh Chokhani" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3E83F.EEF911F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> 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_000A_01C3E83F.EEF911F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marta: =20 There does not seem to be any benefit gained by using the attribute certificate format for archived data. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Marta.Vohnoutova@pvt.cz Sent: Saturday, January 31, 2004 4:11 PM To: ietf-ltans@imc.org Subject: Role of attribute certificates in long-term archiving Hi all, I am reading the archiving conference very carefuly and I hope that my = idea abou attribute certification usage could be useful for your long term archiving standard creation. =20 Identification of a user accessing the archive is interesting problem. = But I think it is solved in the RFC-3281 and it is not necessary to specify = it more. We should use the RFC-3281 which is of "Standard Track" category. = It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree = of this structure. =20 It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive = will be different (third party archiving service, specialized archive for = company or for notaries etc.) Realize that the person storing the document into = the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the = document into an archive. The archived invoice is owned not by the accountant but = by the company. The accountant cannot e.g. delete the invoice in the = archive.=20 =20 During the archiving lifetime of the document, an inspection of a state = tax office can come. Another company employee must pick up the invoice copy = from the archive and submit it for the inspection.=20 =20 When the archived invoice lifetime is over, the invoice must be = cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is = in bankruptcy, it is required to archive documents later) or put the = document for the permanent archiving (e.g. invoice for crown jewelry.) =20 Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's = certificate. The conclusion is: we can issue attribute certificates for (in this = case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute = certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one = day because the people roles and access rights can change quickly. The = permanent bind of a concrete role to a concrete person does not exist. =20 Cordially Marta =20 Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_000A_01C3E83F.EEF911F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Marta:
 
There=20 does not seem to be any benefit gained by using the attribute = certificate format=20 for archived data.
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Marta.Vohnoutova@pvt.cz
Sent: Saturday, = January 31,=20 2004 4:11 PM
To: ietf-ltans@imc.org
Subject: Role = of=20 attribute certificates in long-term archiving

Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I = think it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should=20 use the RFC-3281 which is of „Standard Track“ category. It = would be enough to=20 solve the structure of archived documents because the attribute = certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries etc.) Realize that the person storing the document into the = archive=20 is rarely the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant=20 marks the archiving time in the invoice and stores the document into = an=20 archive. The archived invoice is owned not by the accountant but by = the=20 company. The accountant cannot e.g. delete the invoice in the archive. =

 

During the archiving lifetime of the = document, an=20 inspection of a state tax office can come. Another company employee = must pick=20 up the invoice copy from the archive and submit it for the inspection. =

 

When the archived invoice lifetime is over, = the invoice=20 must be cancelled (destroyed) from the archive. And again another = person of=20 the company is responsible for canceling. This person must decide = whether to=20 cancel document or whether to archive it later (for example, if the = company is=20 in bankruptcy, it is required to archive documents later) or put the = document=20 for the permanent archiving (e.g. invoice for crown=20 jewelry…)

 

Attribute certificate can vary in time = according to=20 e.g. changes in some database of clients of archive. They are bound = with the=20 user’s certificate. The conclusion is: we can issue attribute = certificates for=20 (in this case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate=20 (view right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day = because the=20 people roles and access rights can change quickly. The permanent bind = of a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta=20 Vohnoutova PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_000A_01C3E83F.EEF911F0-- From owner-ietf-ltans Sat Jan 31 18:19:57 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jv1v012483; Sat, 31 Jan 2004 18:19:57 -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 i112Jvo5012481; Sat, 31 Jan 2004 18:19:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jstf012463 for ; Sat, 31 Jan 2004 18:19:56 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102194411100elag4e>; Sun, 1 Feb 2004 02:19:44 +0000 From: "Santosh Chokhani" To: Subject: RE: My objections to the submitted draft Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3E83F.F2461A10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> 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_000F_01C3E83F.F2461A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Libor: =20 See my responses in line -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Libor.Dostalek@pvt.cz Sent: Saturday, January 31, 2004 2:35 PM To: ietf-ltans@imc.org Subject: My objections to the submitted draft Hi,=20 I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >.=20 =20 > 2. Terminology > . > Timestamp: A signed confirmation generated by a Time Stamping=20 > Authority (TSA) that a data item existed at a certain time. =20 > [RFC3161] specifies a good structure for timestamps and a protocol=20 > for communicating with a Timestamp Authority (TSA). =20 =20 It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I = do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps = based on the linking hash principle. If we bind time stamp based on linking = hash to the archived document, we could give to the court not one but two independent evidences of the document validity. [Santosh Chokhani] There may be some patent related concerns regarding = the linked time stamp (Surety in US).=20 =20 I.e. digital signatures of archived documents would be added with = nonsigned attribute - the enhanced time stamp based on other cryptographical = principle - the linking hash. =20 =20 The base difference between time stamps based on linking hashes and = those acc. to the RFC3161 is the fact that the time stamps based on the = RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time = stamps based on linking hashes expire when the used hash algorithm proves to be = too week, which represents incomparably longer time. =20 . =20 > 3.2 Long-term Archive Service=20 > =20 > A Long-term Archive Service is to be designed to solve essential=20 > parts of these problems by providing a specialized service:=20 > =20 > - The Long-term Archive Service is to store archived data objects=20 > over a long, optionally undefined, period of time. . =20 No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and = canceling order which exactly defines the archiving time for every particular = document type. (In most countries, it has been already legislated in 19th = century.) =20 But many of documents are archived permanently. This is the most = complicated problem and the main aim of LTANS should be to solve problems of = permanent archiving of digitally signed or timestamped documents. =20 [Santosh Chokhani] I think LTANS is trying to solve that problem=20 =20 > - The Long-term Archive Service provides material needed to prove = the=20 > existence and integrity of data objects for users as well as in=20 > court. =20 =20 The preceding sentence is not consistent with the following sentence: =20 > A Long-term Archive Service is to not be designed to solve all=20 > thinkable problems of long-term-verification of digital signatures. = =20 > It does not provide data necessary to verify signatures which are=20 > part of the archived data object itself. This has to be done by=20 > verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20 > Protocol) or DVCS (Data Validation and Certification Server).=20 =20 How could the TAA give the evidence about the existence and integrity of = a document without the data necessary for the verification of such = evidence!? [Santosh Chokhani] The party who archives the data is responsible for providing all the evidence that it might need. Thus, if some one wants = to archive digital signatures or digital signatures and SCVP responses, = they need to include the signed document, signed SCVP responses and SCVP = trust anchor in order to obtain these from the TAA at a later time and = demonstrate the signature was valid at some time in the past. =20 I think that we can discuss many things which the TAA standard should = order or recommend, but it is no doubt that the TAA is obliged to give to a = user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some = type of data store. [Santosh Chokhani] I think TAA needs to play back what the user = submitted and ensure the integrity of the user submission. If the data happens to = be signed data, the user can submit relevant trust anchors, certificates, = and revocation information to demonstrate the signature was valid when = applied. But, TAA need not gather all this; neither does TAA need to be limited = to archive signed data.=20 =20 > This is done, in part, so the archive service can operate without=20 > knowledge of numerous signed data formats, document formats, etc. = It=20 > also does not provide any means to integrate verification data in=20 > data objects and verify embedded signatures. This has to be done on = > the basis of other specifications, like RFC 3029 and with regard to = > specifications of document formats. Of course it is recommended to = > use such specifications together with a Long-term Archive Service.=20 =20 In this article of the draft, we can see that it is necessary to = separate the draft work into several parallel standards. I.g. it is necessary = either to make the RFC3029 into a form of an official standard or to define = formats of archiving data. =20 We cannot run the TAA without format specifications. The archive can = accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to = take care for the archived data formats. =20 =20 Let us have the following example: we have a record of important = government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format = (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! =20 =20 The suggested draft does not take care about migration and emulation of archived documents. =20 ------ =20 The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. = It does not take care for document cataloging, searching of documents, = viewing of documents in undistorted form and document canceling. =20 But document canceling seems to be very important archive functionality = - it does not mean only destroying of the particular document but in some = cases also export of the canceled document into another archive. =20 =20 ---- I am afraid that the submitted draft is only the idea of IT people how = to archive documents and it should be discussed with real archivists which = have their own idea about archiving. The archivists have a different approach = and to create a useful digital archive we should listen to them.=20 =20 We must always keep in mind that the digital archive should offer al = least the same services as the paper or parchment archive.=20 =20 Unfortunately the real archivist will decide about law and orders which = will enable to replace paper archives with digital ones. =20 Libor ------=_NextPart_000_000F_01C3E83F.F2461A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Libor:
 
See my=20 responses in line
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Libor.Dostalek@pvt.cz
Sent: Saturday, January = 31, 2004=20 2:35 PM
To: ietf-ltans@imc.org
Subject: My = objections to=20 the submitted draft

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.=20

 

> 2. = Terminology

> = …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain = time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It=20 is a bit foolish to build everything on the “classical“ = time stamp.  Realize that the time stamp = is also=20 only a digitally signed structure… I do not understand why this = draft does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it = is not=20 more open to time stamps based on the linking hash principle. If we = bind time=20 stamp based on linking hash to the archived document, we could give to = the=20 court not one but two independent evidences of the document=20 validity.
[Santosh = Chokhani] There may=20 be some patent related concerns regarding the linked time stamp = (Surety in=20 US). 

 

I.e. digital signatures of archived documents = would be=20 added with nonsigned  = attribute –=20 the enhanced time stamp based on other cryptographical principle = – the linking=20 hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 = expire with=20 the expiration of their Time Stamping Authority certificate which = issued them=20 (see that we face exactly the same problem we faced in case of digital = signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, = which=20 represents incomparably longer time.  

…   =20

> 3.2    Long-term = Archive Service=20

>    =20

>   =20 A Long-term Archive Service is to be designed to solve = essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>  =20 - The Long-term Archive Service is to store archived data = objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for=20 undefined time period. Every organization has its archiving and = canceling=20 order which exactly defines the archiving time for every particular = document=20 type. (In most countries, it has been already legislated in = 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most = complicated=20 problem and the main aim of LTANS should be to solve problems of = permanent=20 archiving of digitally signed or timestamped documents.  
[Santosh Chokhani] I think = LTANS is=20 trying to solve that=20 problem 

 

>   =20 - The Long-term Archive Service provides material needed to = prove the=20

>   =20 existence and integrity of data objects for users as well as in =

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital=20 signatures. =20

>   =20 It does not provide data necessary to verify signatures which = are=20

>   =20 part of the archived data object itself.  This has to be done by=20

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document without the data necessary for the verification of such=20 evidence!?
[Santosh Chokhani] The party who archives the data is = responsible=20 for providing all the evidence that it might need.  Thus, if some = one=20 wants to archive digital signatures or digital signatures and SCVP = responses,=20 they need to include the signed document, signed SCVP responses and = SCVP trust=20 anchor in order to obtain these from the TAA at a later time and = demonstrate=20 the signature was valid at some time in the=20 past.

 

I=20 think that we can discuss many things which the TAA standard should = order or=20 recommend, but it is no doubt that the TAA is obliged to give to a = user all=20 the required data necessary for existence and integrity proof of the=20 appropriate document. Without this function the TAA would be only some = type of=20 data store.
[Santosh = Chokhani] I think=20 TAA needs to play back what the user submitted and ensure the = integrity of the=20 user submission.  If the data happens to be signed data, the user = can=20 submit relevant trust anchors, certificates, and revocation = information to=20 demonstrate the signature was valid when applied.  But, TAA = need not=20 gather all this; neither does TAA need to be limited to archive signed = data. 

 

>   =20 This is done, in part, so the archive service can operate = without=20

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It=20

>   =20 also does not provide any means to integrate verification data = in=20

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with = regard to=20

>   =20 specifications of document formats.  Of course it is recommended = to=20

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the=20 draft work into several parallel standards. I.g. it is necessary = either to=20 make the RFC3029 into a form of an official standard or to define = formats of=20 archiving data.

 

We=20 cannot run the TAA without format specifications. The archive can = accept only=20 data it can guarantee to be able to view them in undistorted form = during the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important = government=20 meeting stored in the MS Word 3.0. Such document should be archived=20 permanently, but what to do with the document in MS Word 3.0 format = (even now=20 you probably will have a trouble to view it without distortion!) = Obviously,=20 the TAA could not accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According=20 to this draft, the archive only accepts and returns documents. It does = not=20 take care for document cataloging, searching of documents, viewing of=20 documents in undistorted form and document=20 canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I=20 am afraid that the submitted draft is only the idea of IT people how = to=20 archive documents and it should be discussed with real archivists = which have=20 their own idea about archiving. The archivists have a different = approach and=20 to create a useful digital archive we should listen to them.

 

We must always keep in mind = that the=20 digital archive should offer al least the same services as the paper = or=20 parchment archive.

 

Unfortunately the real = archivist will=20 decide about law and orders which will enable to replace paper = archives with=20 digital ones.

 

Libor

------=_NextPart_000_000F_01C3E83F.F2461A10-- From owner-ietf-ltans Sat Jan 31 22:38:39 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116cdW3040712; Sat, 31 Jan 2004 22:38:39 -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 i116cdK1040711; Sat, 31 Jan 2004 22:38:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116caVm040620 for ; Sat, 31 Jan 2004 22:38:37 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116cm49013489 for ; Sun, 1 Feb 2004 07:38:51 +0100 (MET) From: To: Subject: RE: My objections to the submitted draft Date: Sun, 1 Feb 2004 07:34:38 +0100 Message-ID: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Santosh Chokhani] There may be some patent related concerns regarding the linked time stamp (Surety in US). Why uses the submitted draft only time stmps based on RFC-3161? . > > 3.2 Long-term Archive Service > > > > A Long-term Archive Service is to be designed to solve essential > > parts of these problems by providing a specialized service: > > > > - The Long-term Archive Service is to store archived data objects > > over a long, optionally undefined, period of time. . > No reasonable company or organization will not archive its documents for > undefined time period. Every organization has its archiving and > canceling order which exactly defines the archiving time for every > particular document type. (In most countries, it has been already > legislated in 19th century.) > But many of documents are archived permanently. This is the most > complicated problem and the main aim of LTANS should be to solve > problems of permanent archiving of digitally signed or timestamped > documents. [Santosh Chokhani] I think LTANS is trying to solve that problem I am afraid it is not fully true. See the following example: Let us have a signed documnet archived for 200 yers. All signatures of this document are based on RSA algortithm with 1K keys. It means that every two years all the signatures are renewed. The problem is that I have chain of 100 timestamps (based on RFC-3161). Libor From owner-ietf-ltans Sat Jan 31 22:57:27 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vRZQ049104; Sat, 31 Jan 2004 22:57:27 -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 i116vR3b049103; Sat, 31 Jan 2004 22:57:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vPl9049030 for ; Sat, 31 Jan 2004 22:57:26 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116w349019043 for ; Sun, 1 Feb 2004 07:58:08 +0100 (MET) From: To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sun, 1 Feb 2004 07:53:53 +0100 Message-ID: <000101c3e890$306f48c0$314c18ac@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Marta: > > There does not seem to be any benefit gained by using the attribute certificate format > for archived data. I think the digital archive must have at least the same features as classical stone archive. My personal expirience is if you want to explore some old documents in archive you must first prove your identity, explain your purpose why you need these documents, and based on this the appropriate permitions for the specific part of archive is given to you. Analogically in digital world, you can prove your identity with certificate and attributte certificate represents appropriate permitions given to you. Identity of person who put document into archive 50 years ago could be irrelevant. Marta From owner-ietf-ltans Sat Jan 31 23:59:19 2004 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xJtB070227; Sat, 31 Jan 2004 23:59:19 -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 i117xJ84070225; Sat, 31 Jan 2004 23:59:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xHuE070212 for ; Sat, 31 Jan 2004 23:59:18 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust250.tnt59.dfw5.da.uu.net ([67.203.43.250] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AnCVQ-0003iw-00; Sun, 01 Feb 2004 02:59:01 -0500 Message-ID: <401CCC88.597001E9@ix.netcom.com> Date: Sun, 01 Feb 2004 01:53:15 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Libor.Dostalek@pvt.cz CC: ietf-ltans@imc.org, Mark milone Subject: Re: My objections to the submitted draft References: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> 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: Libor and all, Your point below is well taken and has been and is being discussed on other venues/forums regarding legal documents or those that may be of some legal interest. Many have very long term life. RFC 3161 failed to recognize these factors, even though they were discussed at the time RFC 3161 was under consideration. Hence it's revision would seem to be in order... Libor.Dostalek@pvt.cz wrote: > [Santosh Chokhani] There may be some patent related concerns regarding > the linked time stamp (Surety in US). > > Why uses the submitted draft only time stmps based on RFC-3161? > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > No reasonable company or organization will not archive its documents > for > > undefined time period. Every organization has its archiving and > > canceling order which exactly defines the archiving time for every > > particular document type. (In most countries, it has been already > > legislated in 19th century.) > > > But many of documents are archived permanently. This is the most > > complicated problem and the main aim of LTANS should be to solve > > problems of permanent archiving of digitally signed or timestamped > > documents. > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > I am afraid it is not fully true. See the following example: > Let us have a signed documnet archived for 200 yers. All signatures > of this document are based on RSA algortithm with 1K keys. It means > that every two years all the signatures are renewed. The problem is > that I have chain of 100 timestamps (based on RFC-3161). > > Libor Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xJtB070227; Sat, 31 Jan 2004 23:59:19 -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 i117xJ84070225; Sat, 31 Jan 2004 23:59:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i117xHuE070212 for ; Sat, 31 Jan 2004 23:59:18 -0800 (PST) (envelope-from jwkckid1@ix.netcom.com) Received: from 1cust250.tnt59.dfw5.da.uu.net ([67.203.43.250] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1AnCVQ-0003iw-00; Sun, 01 Feb 2004 02:59:01 -0500 Message-ID: <401CCC88.597001E9@ix.netcom.com> Date: Sun, 01 Feb 2004 01:53:15 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Libor.Dostalek@pvt.cz CC: ietf-ltans@imc.org, Mark milone Subject: Re: My objections to the submitted draft References: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> 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: Libor and all, Your point below is well taken and has been and is being discussed on other venues/forums regarding legal documents or those that may be of some legal interest. Many have very long term life. RFC 3161 failed to recognize these factors, even though they were discussed at the time RFC 3161 was under consideration. Hence it's revision would seem to be in order... Libor.Dostalek@pvt.cz wrote: > [Santosh Chokhani] There may be some patent related concerns regarding > the linked time stamp (Surety in US). > > Why uses the submitted draft only time stmps based on RFC-3161? > > . > > > 3.2 Long-term Archive Service > > > > > > A Long-term Archive Service is to be designed to solve essential > > > parts of these problems by providing a specialized service: > > > > > > - The Long-term Archive Service is to store archived data objects > > > over a long, optionally undefined, period of time. . > > No reasonable company or organization will not archive its documents > for > > undefined time period. Every organization has its archiving and > > canceling order which exactly defines the archiving time for every > > particular document type. (In most countries, it has been already > > legislated in 19th century.) > > > But many of documents are archived permanently. This is the most > > complicated problem and the main aim of LTANS should be to solve > > problems of permanent archiving of digitally signed or timestamped > > documents. > > [Santosh Chokhani] I think LTANS is trying to solve that problem > > I am afraid it is not fully true. See the following example: > Let us have a signed documnet archived for 200 yers. All signatures > of this document are based on RSA algortithm with 1K keys. It means > that every two years all the signatures are renewed. The problem is > that I have chain of 100 timestamps (based on RFC-3161). > > Libor Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vRZQ049104; Sat, 31 Jan 2004 22:57:27 -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 i116vR3b049103; Sat, 31 Jan 2004 22:57:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116vPl9049030 for ; Sat, 31 Jan 2004 22:57:26 -0800 (PST) (envelope-from Marta.Vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116w349019043 for ; Sun, 1 Feb 2004 07:58:08 +0100 (MET) From: To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sun, 1 Feb 2004 07:53:53 +0100 Message-ID: <000101c3e890$306f48c0$314c18ac@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Marta: > > There does not seem to be any benefit gained by using the attribute certificate format > for archived data. I think the digital archive must have at least the same features as classical stone archive. My personal expirience is if you want to explore some old documents in archive you must first prove your identity, explain your purpose why you need these documents, and based on this the appropriate permitions for the specific part of archive is given to you. Analogically in digital world, you can prove your identity with certificate and attributte certificate represents appropriate permitions given to you. Identity of person who put document into archive 50 years ago could be irrelevant. Marta Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116cdW3040712; Sat, 31 Jan 2004 22:38:39 -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 i116cdK1040711; Sat, 31 Jan 2004 22:38:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i116caVm040620 for ; Sat, 31 Jan 2004 22:38:37 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg128.isp.t-mobile.cz [62.141.25.128]) by click.cz (8.12.9/8.12.9) with ESMTP id i116cm49013489 for ; Sun, 1 Feb 2004 07:38:51 +0100 (MET) From: To: Subject: RE: My objections to the submitted draft Date: Sun, 1 Feb 2004 07:34:38 +0100 Message-ID: <000001c3e88d$7e1eb400$314c18ac@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [Santosh Chokhani] There may be some patent related concerns regarding the linked time stamp (Surety in US). Why uses the submitted draft only time stmps based on RFC-3161? . > > 3.2 Long-term Archive Service > > > > A Long-term Archive Service is to be designed to solve essential > > parts of these problems by providing a specialized service: > > > > - The Long-term Archive Service is to store archived data objects > > over a long, optionally undefined, period of time. . > No reasonable company or organization will not archive its documents for > undefined time period. Every organization has its archiving and > canceling order which exactly defines the archiving time for every > particular document type. (In most countries, it has been already > legislated in 19th century.) > But many of documents are archived permanently. This is the most > complicated problem and the main aim of LTANS should be to solve > problems of permanent archiving of digitally signed or timestamped > documents. [Santosh Chokhani] I think LTANS is trying to solve that problem I am afraid it is not fully true. See the following example: Let us have a signed documnet archived for 200 yers. All signatures of this document are based on RSA algortithm with 1K keys. It means that every two years all the signatures are renewed. The problem is that I have chain of 100 timestamps (based on RFC-3161). Libor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jv1v012483; Sat, 31 Jan 2004 18:19:57 -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 i112Jvo5012481; Sat, 31 Jan 2004 18:19:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jstf012463 for ; Sat, 31 Jan 2004 18:19:56 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102194411100elag4e>; Sun, 1 Feb 2004 02:19:44 +0000 From: "Santosh Chokhani" To: Subject: RE: My objections to the submitted draft Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000e01c3e869$db1c2210$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3E83F.F2461A10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> 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_000F_01C3E83F.F2461A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Libor: =20 See my responses in line -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Libor.Dostalek@pvt.cz Sent: Saturday, January 31, 2004 2:35 PM To: ietf-ltans@imc.org Subject: My objections to the submitted draft Hi,=20 I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >.=20 =20 > 2. Terminology > . > Timestamp: A signed confirmation generated by a Time Stamping=20 > Authority (TSA) that a data item existed at a certain time. =20 > [RFC3161] specifies a good structure for timestamps and a protocol=20 > for communicating with a Timestamp Authority (TSA). =20 =20 It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I = do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps = based on the linking hash principle. If we bind time stamp based on linking = hash to the archived document, we could give to the court not one but two independent evidences of the document validity. [Santosh Chokhani] There may be some patent related concerns regarding = the linked time stamp (Surety in US).=20 =20 I.e. digital signatures of archived documents would be added with = nonsigned attribute - the enhanced time stamp based on other cryptographical = principle - the linking hash. =20 =20 The base difference between time stamps based on linking hashes and = those acc. to the RFC3161 is the fact that the time stamps based on the = RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time = stamps based on linking hashes expire when the used hash algorithm proves to be = too week, which represents incomparably longer time. =20 . =20 > 3.2 Long-term Archive Service=20 > =20 > A Long-term Archive Service is to be designed to solve essential=20 > parts of these problems by providing a specialized service:=20 > =20 > - The Long-term Archive Service is to store archived data objects=20 > over a long, optionally undefined, period of time. . =20 No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and = canceling order which exactly defines the archiving time for every particular = document type. (In most countries, it has been already legislated in 19th = century.) =20 But many of documents are archived permanently. This is the most = complicated problem and the main aim of LTANS should be to solve problems of = permanent archiving of digitally signed or timestamped documents. =20 [Santosh Chokhani] I think LTANS is trying to solve that problem=20 =20 > - The Long-term Archive Service provides material needed to prove = the=20 > existence and integrity of data objects for users as well as in=20 > court. =20 =20 The preceding sentence is not consistent with the following sentence: =20 > A Long-term Archive Service is to not be designed to solve all=20 > thinkable problems of long-term-verification of digital signatures. = =20 > It does not provide data necessary to verify signatures which are=20 > part of the archived data object itself. This has to be done by=20 > verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20 > Protocol) or DVCS (Data Validation and Certification Server).=20 =20 How could the TAA give the evidence about the existence and integrity of = a document without the data necessary for the verification of such = evidence!? [Santosh Chokhani] The party who archives the data is responsible for providing all the evidence that it might need. Thus, if some one wants = to archive digital signatures or digital signatures and SCVP responses, = they need to include the signed document, signed SCVP responses and SCVP = trust anchor in order to obtain these from the TAA at a later time and = demonstrate the signature was valid at some time in the past. =20 I think that we can discuss many things which the TAA standard should = order or recommend, but it is no doubt that the TAA is obliged to give to a = user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some = type of data store. [Santosh Chokhani] I think TAA needs to play back what the user = submitted and ensure the integrity of the user submission. If the data happens to = be signed data, the user can submit relevant trust anchors, certificates, = and revocation information to demonstrate the signature was valid when = applied. But, TAA need not gather all this; neither does TAA need to be limited = to archive signed data.=20 =20 > This is done, in part, so the archive service can operate without=20 > knowledge of numerous signed data formats, document formats, etc. = It=20 > also does not provide any means to integrate verification data in=20 > data objects and verify embedded signatures. This has to be done on = > the basis of other specifications, like RFC 3029 and with regard to = > specifications of document formats. Of course it is recommended to = > use such specifications together with a Long-term Archive Service.=20 =20 In this article of the draft, we can see that it is necessary to = separate the draft work into several parallel standards. I.g. it is necessary = either to make the RFC3029 into a form of an official standard or to define = formats of archiving data. =20 We cannot run the TAA without format specifications. The archive can = accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to = take care for the archived data formats. =20 =20 Let us have the following example: we have a record of important = government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format = (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! =20 =20 The suggested draft does not take care about migration and emulation of archived documents. =20 ------ =20 The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. = It does not take care for document cataloging, searching of documents, = viewing of documents in undistorted form and document canceling. =20 But document canceling seems to be very important archive functionality = - it does not mean only destroying of the particular document but in some = cases also export of the canceled document into another archive. =20 =20 ---- I am afraid that the submitted draft is only the idea of IT people how = to archive documents and it should be discussed with real archivists which = have their own idea about archiving. The archivists have a different approach = and to create a useful digital archive we should listen to them.=20 =20 We must always keep in mind that the digital archive should offer al = least the same services as the paper or parchment archive.=20 =20 Unfortunately the real archivist will decide about law and orders which = will enable to replace paper archives with digital ones. =20 Libor ------=_NextPart_000_000F_01C3E83F.F2461A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Libor:
 
See my=20 responses in line
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Libor.Dostalek@pvt.cz
Sent: Saturday, January = 31, 2004=20 2:35 PM
To: ietf-ltans@imc.org
Subject: My = objections to=20 the submitted draft

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.=20

 

> 2. = Terminology

> = …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain = time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It=20 is a bit foolish to build everything on the “classical“ = time stamp.  Realize that the time stamp = is also=20 only a digitally signed structure… I do not understand why this = draft does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it = is not=20 more open to time stamps based on the linking hash principle. If we = bind time=20 stamp based on linking hash to the archived document, we could give to = the=20 court not one but two independent evidences of the document=20 validity.
[Santosh = Chokhani] There may=20 be some patent related concerns regarding the linked time stamp = (Surety in=20 US). 

 

I.e. digital signatures of archived documents = would be=20 added with nonsigned  = attribute –=20 the enhanced time stamp based on other cryptographical principle = – the linking=20 hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 = expire with=20 the expiration of their Time Stamping Authority certificate which = issued them=20 (see that we face exactly the same problem we faced in case of digital = signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, = which=20 represents incomparably longer time.  

…   =20

> 3.2    Long-term = Archive Service=20

>    =20

>   =20 A Long-term Archive Service is to be designed to solve = essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>  =20 - The Long-term Archive Service is to store archived data = objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for=20 undefined time period. Every organization has its archiving and = canceling=20 order which exactly defines the archiving time for every particular = document=20 type. (In most countries, it has been already legislated in = 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most = complicated=20 problem and the main aim of LTANS should be to solve problems of = permanent=20 archiving of digitally signed or timestamped documents.  
[Santosh Chokhani] I think = LTANS is=20 trying to solve that=20 problem 

 

>   =20 - The Long-term Archive Service provides material needed to = prove the=20

>   =20 existence and integrity of data objects for users as well as in =

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital=20 signatures. =20

>   =20 It does not provide data necessary to verify signatures which = are=20

>   =20 part of the archived data object itself.  This has to be done by=20

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document without the data necessary for the verification of such=20 evidence!?
[Santosh Chokhani] The party who archives the data is = responsible=20 for providing all the evidence that it might need.  Thus, if some = one=20 wants to archive digital signatures or digital signatures and SCVP = responses,=20 they need to include the signed document, signed SCVP responses and = SCVP trust=20 anchor in order to obtain these from the TAA at a later time and = demonstrate=20 the signature was valid at some time in the=20 past.

 

I=20 think that we can discuss many things which the TAA standard should = order or=20 recommend, but it is no doubt that the TAA is obliged to give to a = user all=20 the required data necessary for existence and integrity proof of the=20 appropriate document. Without this function the TAA would be only some = type of=20 data store.
[Santosh = Chokhani] I think=20 TAA needs to play back what the user submitted and ensure the = integrity of the=20 user submission.  If the data happens to be signed data, the user = can=20 submit relevant trust anchors, certificates, and revocation = information to=20 demonstrate the signature was valid when applied.  But, TAA = need not=20 gather all this; neither does TAA need to be limited to archive signed = data. 

 

>   =20 This is done, in part, so the archive service can operate = without=20

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It=20

>   =20 also does not provide any means to integrate verification data = in=20

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with = regard to=20

>   =20 specifications of document formats.  Of course it is recommended = to=20

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the=20 draft work into several parallel standards. I.g. it is necessary = either to=20 make the RFC3029 into a form of an official standard or to define = formats of=20 archiving data.

 

We=20 cannot run the TAA without format specifications. The archive can = accept only=20 data it can guarantee to be able to view them in undistorted form = during the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important = government=20 meeting stored in the MS Word 3.0. Such document should be archived=20 permanently, but what to do with the document in MS Word 3.0 format = (even now=20 you probably will have a trouble to view it without distortion!) = Obviously,=20 the TAA could not accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According=20 to this draft, the archive only accepts and returns documents. It does = not=20 take care for document cataloging, searching of documents, viewing of=20 documents in undistorted form and document=20 canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I=20 am afraid that the submitted draft is only the idea of IT people how = to=20 archive documents and it should be discussed with real archivists = which have=20 their own idea about archiving. The archivists have a different = approach and=20 to create a useful digital archive we should listen to them.

 

We must always keep in mind = that the=20 digital archive should offer al least the same services as the paper = or=20 parchment archive.

 

Unfortunately the real = archivist will=20 decide about law and orders which will enable to replace paper = archives with=20 digital ones.

 

Libor

------=_NextPart_000_000F_01C3E83F.F2461A10-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112JtM7012474; Sat, 31 Jan 2004 18:19:55 -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 i112Jthm012473; Sat, 31 Jan 2004 18:19:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i112Jste012463 for ; Sat, 31 Jan 2004 18:19:54 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani (169.washington-43rh15rt.dc.dial-access.att.net[12.77.65.169]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004020102193611100elag3e>; Sun, 1 Feb 2004 02:19:39 +0000 From: "Santosh Chokhani" To: Subject: RE: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 21:19:35 -0500 Message-ID: <000901c3e869$d7cf19f0$a9414d0c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C3E83F.EEF911F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> 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_000A_01C3E83F.EEF911F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marta: =20 There does not seem to be any benefit gained by using the attribute certificate format for archived data. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Marta.Vohnoutova@pvt.cz Sent: Saturday, January 31, 2004 4:11 PM To: ietf-ltans@imc.org Subject: Role of attribute certificates in long-term archiving Hi all, I am reading the archiving conference very carefuly and I hope that my = idea abou attribute certification usage could be useful for your long term archiving standard creation. =20 Identification of a user accessing the archive is interesting problem. = But I think it is solved in the RFC-3281 and it is not necessary to specify = it more. We should use the RFC-3281 which is of "Standard Track" category. = It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree = of this structure. =20 It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive = will be different (third party archiving service, specialized archive for = company or for notaries etc.) Realize that the person storing the document into = the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the = document into an archive. The archived invoice is owned not by the accountant but = by the company. The accountant cannot e.g. delete the invoice in the = archive.=20 =20 During the archiving lifetime of the document, an inspection of a state = tax office can come. Another company employee must pick up the invoice copy = from the archive and submit it for the inspection.=20 =20 When the archived invoice lifetime is over, the invoice must be = cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is = in bankruptcy, it is required to archive documents later) or put the = document for the permanent archiving (e.g. invoice for crown jewelry.) =20 Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's = certificate. The conclusion is: we can issue attribute certificates for (in this = case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute = certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one = day because the people roles and access rights can change quickly. The = permanent bind of a concrete role to a concrete person does not exist. =20 Cordially Marta =20 Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_000A_01C3E83F.EEF911F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Marta:
 
There=20 does not seem to be any benefit gained by using the attribute = certificate format=20 for archived data.
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Marta.Vohnoutova@pvt.cz
Sent: Saturday, = January 31,=20 2004 4:11 PM
To: ietf-ltans@imc.org
Subject: Role = of=20 attribute certificates in long-term archiving

Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I = think it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should=20 use the RFC-3281 which is of „Standard Track“ category. It = would be enough to=20 solve the structure of archived documents because the attribute = certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries etc.) Realize that the person storing the document into the = archive=20 is rarely the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant=20 marks the archiving time in the invoice and stores the document into = an=20 archive. The archived invoice is owned not by the accountant but by = the=20 company. The accountant cannot e.g. delete the invoice in the archive. =

 

During the archiving lifetime of the = document, an=20 inspection of a state tax office can come. Another company employee = must pick=20 up the invoice copy from the archive and submit it for the inspection. =

 

When the archived invoice lifetime is over, = the invoice=20 must be cancelled (destroyed) from the archive. And again another = person of=20 the company is responsible for canceling. This person must decide = whether to=20 cancel document or whether to archive it later (for example, if the = company is=20 in bankruptcy, it is required to archive documents later) or put the = document=20 for the permanent archiving (e.g. invoice for crown=20 jewelry…)

 

Attribute certificate can vary in time = according to=20 e.g. changes in some database of clients of archive. They are bound = with the=20 user’s certificate. The conclusion is: we can issue attribute = certificates for=20 (in this case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate=20 (view right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day = because the=20 people roles and access rights can change quickly. The permanent bind = of a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta=20 Vohnoutova PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_000A_01C3E83F.EEF911F0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEeUi093678; Sat, 31 Jan 2004 13:14:40 -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 i0VLEeiK093677; Sat, 31 Jan 2004 13:14:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLEcJY093666 for ; Sat, 31 Jan 2004 13:14:39 -0800 (PST) (envelope-from marta.vohnoutova@pvt.cz) Received: from cbuwdostalek2 (gprsh1.isp.t-mobile.cz [62.141.24.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VLF949003358 for ; Sat, 31 Jan 2004 22:15:11 +0100 (MET) From: "Marta.Vohnoutova@pvt.cz" To: Subject: Role of attribute certificates in long-term archiving Date: Sat, 31 Jan 2004 22:11:00 +0100 Message-ID: <000001c3e83e$c0a4d470$bb3918ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3E847.226C49B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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_0001_01C3E847.226C49B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I am reading the archiving conference very carefuly and I hope that my idea abou attribute certification usage could be useful for your long term archiving standard creation. Identification of a user accessing the archive is interesting problem. But I think it is solved in the RFC-3281 and it is not necessary to specify it more. We should use the RFC-3281 which is of "Standard Track" category. It would be enough to solve the structure of archived documents because the attribute certificates (RFC-3281) will be always bound to some subtree of this structure. It would be difficult to find out something what is more suitable for attribute certificate usage than the long-term archiving. Any archive will be different (third party archiving service, specialized archive for company or for notaries etc.) Realize that the person storing the document into the archive is rarely the real document owner. One example: invoice. According to the company internal orders, an accountant marks the archiving time in the invoice and stores the document into an archive. The archived invoice is owned not by the accountant but by the company. The accountant cannot e.g. delete the invoice in the archive. During the archiving lifetime of the document, an inspection of a state tax office can come. Another company employee must pick up the invoice copy from the archive and submit it for the inspection. When the archived invoice lifetime is over, the invoice must be cancelled (destroyed) from the archive. And again another person of the company is responsible for canceling. This person must decide whether to cancel document or whether to archive it later (for example, if the company is in bankruptcy, it is required to archive documents later) or put the document for the permanent archiving (e.g. invoice for crown jewelry.) Attribute certificate can vary in time according to e.g. changes in some database of clients of archive. They are bound with the user's certificate. The conclusion is: we can issue attribute certificates for (in this case): - Accountant (rights for invoice archiving) - Manager (rights for picking invoices up from the archive to inspect them) - Officer responsible for document canceling - In case of open document we can have also an attribute certificate (view right) for all who sign the commitment not to abuse the document Attribute certificate are very flexible and can be issued for e.g. one day because the people roles and access rights can change quickly. The permanent bind of a concrete role to a concrete person does not exist. Cordially Marta Marta Vohnoutova PVT a.s. Czech Republic marta.vohnoutova@pvt.cz ------=_NextPart_000_0001_01C3E847.226C49B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zpráva
Hi=20 all,
I am = reading the=20 archiving conference very carefuly and I hope that my idea abou = attribute=20 certification usage could be useful for your long term archiving = standard=20 creation.
 

Identification of =20 a user accessing the archive is interesting problem. But I think = it is=20 solved in the RFC-3281 and it is not necessary to specify it more. We = should use=20 the RFC-3281 which is of „Standard Track“ category. It would = be enough to solve=20 the structure of archived documents because the attribute certificates=20 (RFC-3281) will be always bound to some subtree of this=20 structure.

 

It=20 would be difficult to find out something what is more suitable for = attribute=20 certificate usage than the long-term archiving. Any archive will be = different=20 (third party archiving service, specialized archive for company or for = notaries=20 etc.) Realize that the person storing the document into the archive is = rarely=20 the real document owner.

One=20 example: invoice. According to the company internal orders, an = accountant marks=20 the archiving time in the invoice and stores the document into an = archive. The=20 archived invoice is owned not by the accountant but by the company. The=20 accountant cannot e.g. delete the invoice in the archive.=20

 

During the archiving lifetime of the document, = an=20 inspection of a state tax office can come. Another company employee must = pick up=20 the invoice copy from the archive and submit it for the inspection.=20

 

When=20 the archived invoice lifetime is over, the invoice must be cancelled = (destroyed)=20 from the archive. And again another person of the company is responsible = for=20 canceling. This person must decide whether to cancel document or whether = to=20 archive it later (for example, if the company is in bankruptcy, it is = required=20 to archive documents later) or put the document for the permanent = archiving=20 (e.g. invoice for crown = jewelry…)

 

Attribute certificate can vary in time = according to e.g.=20 changes in some database of clients of archive. They are bound with the = user’s=20 certificate. The conclusion is: we can issue attribute certificates for = (in this=20 case):

-        =20 Accountant (rights for invoice=20 archiving)

-        =20 Manager (rights for picking invoices up from the archive to = inspect=20 them)

-        =20 Officer responsible for document=20 canceling

-        =20 In case of open document we can have also an attribute = certificate (view=20 right) for all who sign the commitment not to abuse the=20 document

Attribute=20 certificate are very flexible and can be issued for e.g. one day because = the=20 people roles and access rights can change quickly. The permanent bind of = a=20 concrete role to a concrete person does not exist.

 

Cordially=20 Marta

 

Marta Vohnoutova=20 PVT a.s. Czech Republic

marta.vohnoutova@pvt.cz

------=_NextPart_000_0001_01C3E847.226C49B0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJde1Z088984; Sat, 31 Jan 2004 11:39:40 -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 i0VJdeYB088983; Sat, 31 Jan 2004 11:39:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from click.cz (black.click.cz [62.141.0.10]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VJdZSW088965 for ; Sat, 31 Jan 2004 11:39:38 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 (gprsg1.isp.t-mobile.cz [62.141.25.1]) by click.cz (8.12.9/8.12.9) with ESMTP id i0VJdX49002556 for ; Sat, 31 Jan 2004 20:39:47 +0100 (MET) From: To: Subject: My objections to the submitted draft Date: Sat, 31 Jan 2004 20:35:25 +0100 Message-ID: <004501c3e831$6d4d9b70$1f0318ac@pvt.cz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C3E839.CF120370" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal 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_0046_01C3E839.CF120370 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I have several things in the submitted draft which are unclear to me. To have a Berger orientation I put here also the unclear parts of the draft marked with the leading >. > 2. Terminology > . > Timestamp: A signed confirmation generated by a Time Stamping > Authority (TSA) that a data item existed at a certain time. > [RFC3161] specifies a good structure for timestamps and a protocol > for communicating with a Timestamp Authority (TSA). It is a bit foolish to build everything on the "classical" time stamp. Realize that the time stamp is also only a digitally signed structure. I do not understand why this draft does not mention the time stamp acc. to RFC3161 only as eventuality and why it is not more open to time stamps based on the linking hash principle. If we bind time stamp based on linking hash to the archived document, we could give to the court not one but two independent evidences of the document validity. I.e. digital signatures of archived documents would be added with nonsigned attribute - the enhanced time stamp based on other cryptographical principle - the linking hash. The base difference between time stamps based on linking hashes and those acc. to the RFC3161 is the fact that the time stamps based on the RFC3161 expire with the expiration of their Time Stamping Authority certificate which issued them (see that we face exactly the same problem we faced in case of digital signature, what this draft should solve), while time stamps based on linking hashes expire when the used hash algorithm proves to be too week, which represents incomparably longer time. . > 3.2 Long-term Archive Service > > A Long-term Archive Service is to be designed to solve essential > parts of these problems by providing a specialized service: > > - The Long-term Archive Service is to store archived data objects > over a long, optionally undefined, period of time. . No reasonable company or organization will not archive its documents for undefined time period. Every organization has its archiving and canceling order which exactly defines the archiving time for every particular document type. (In most countries, it has been already legislated in 19th century.) But many of documents are archived permanently. This is the most complicated problem and the main aim of LTANS should be to solve problems of permanent archiving of digitally signed or timestamped documents. > - The Long-term Archive Service provides material needed to prove the > existence and integrity of data objects for users as well as in > court. The preceding sentence is not consistent with the following sentence: > A Long-term Archive Service is to not be designed to solve all > thinkable problems of long-term-verification of digital signatures. > It does not provide data necessary to verify signatures which are > part of the archived data object itself. This has to be done by > verifiers using PKI-Services like SCVP (Simple Certificate Validation > Protocol) or DVCS (Data Validation and Certification Server). How could the TAA give the evidence about the existence and integrity of a document without the data necessary for the verification of such evidence!? I think that we can discuss many things which the TAA standard should order or recommend, but it is no doubt that the TAA is obliged to give to a user all the required data necessary for existence and integrity proof of the appropriate document. Without this function the TAA would be only some type of data store. > This is done, in part, so the archive service can operate without > knowledge of numerous signed data formats, document formats, etc. It > also does not provide any means to integrate verification data in > data objects and verify embedded signatures. This has to be done on > the basis of other specifications, like RFC 3029 and with regard to > specifications of document formats. Of course it is recommended to > use such specifications together with a Long-term Archive Service. In this article of the draft, we can see that it is necessary to separate the draft work into several parallel standards. I.g. it is necessary either to make the RFC3029 into a form of an official standard or to define formats of archiving data. We cannot run the TAA without format specifications. The archive can accept only data it can guarantee to be able to view them in undistorted form during the whole archiving time. It is not possible for the TAA not to take care for the archived data formats. Let us have the following example: we have a record of important government meeting stored in the MS Word 3.0. Such document should be archived permanently, but what to do with the document in MS Word 3.0 format (even now you probably will have a trouble to view it without distortion!) Obviously, the TAA could not accept such document! The suggested draft does not take care about migration and emulation of archived documents. ------ The lifetime of the archived document is also not solved in this draft. According to this draft, the archive only accepts and returns documents. It does not take care for document cataloging, searching of documents, viewing of documents in undistorted form and document canceling. But document canceling seems to be very important archive functionality - it does not mean only destroying of the particular document but in some cases also export of the canceled document into another archive. ---- I am afraid that the submitted draft is only the idea of IT people how to archive documents and it should be discussed with real archivists which have their own idea about archiving. The archivists have a different approach and to create a useful digital archive we should listen to them. We must always keep in mind that the digital archive should offer al least the same services as the paper or parchment archive. Unfortunately the real archivist will decide about law and orders which will enable to replace paper archives with digital ones. Libor ------=_NextPart_000_0046_01C3E839.CF120370 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Zpráva

Hi, 

I have several things in the = submitted draft=20 which are unclear to me. To have a Berger orientation I put here also = the=20 unclear parts of the draft marked with the leading >.

 

>=20 2. Terminology

>=20 …

>   =20 Timestamp: A signed confirmation generated by a Time Stamping=20

>   =20 Authority (TSA) that a data item existed at a certain time.  =

>   =20 [RFC3161] specifies a good structure for timestamps and a = protocol=20

>   =20 for communicating with a Timestamp Authority (TSA).  =

 

It is=20 a bit foolish to build everything on the “classical“ time = stamp.  Realize that the time stamp is = also only=20 a digitally signed structure… I do not understand why this draft = does not=20 mention the time stamp acc. to RFC3161 only as eventuality and why it is = not=20 more open to time stamps based on the linking hash principle. If we bind = time=20 stamp based on linking hash to the archived document, we could give to = the court=20 not one but two independent evidences of the document=20 validity.

 

I.e.=20 digital signatures of archived documents would be added with = nonsigned  attribute – the enhanced = time stamp=20 based on other cryptographical principle – the linking hash.  =20

 

The=20 base difference between time stamps based on linking hashes and those = acc. to=20 the RFC3161 is the fact that the time stamps based on the RFC3161 expire = with=20 the expiration of their Time Stamping Authority certificate which issued = them=20 (see that we face exactly the same problem we faced in case of digital=20 signature, what this draft should solve), while time stamps based on = linking=20 hashes expire when the used hash algorithm proves to be too week, which=20 represents incomparably longer time.  

…   =20

>=20 3.2    Long-term = Archive=20 Service

>    =20

>   =20 A Long-term Archive Service is to be designed to solve essential=20

>   =20 parts of these problems by providing a specialized service:=20

>    =20

>   -=20 The Long-term Archive Service is to store archived data objects=20

>   =20 over a long, optionally undefined, period of time…=20 .

 

No=20 reasonable company or organization will not archive its documents for = undefined=20 time period. Every organization has its archiving and canceling order = which=20 exactly defines the archiving time for every particular document type. = (In most=20 countries, it has been already legislated in 19th=20 century.)

 

But=20 many of documents are archived permanently. This is the most complicated = problem=20 and the main aim of LTANS should be to solve problems of permanent = archiving of=20 digitally signed or timestamped documents.  

 

>   =20 - The Long-term Archive Service provides material needed to prove = the=20

>   =20 existence and integrity of data objects for users as well as in=20

>   =20 court. =20

 

The=20 preceding sentence is not consistent with the following=20 sentence:

 

>   =20 A Long-term Archive Service is to not be designed to solve all=20

>   =20 thinkable problems of long-term-verification of digital = signatures.  =

>   =20 It does not provide data necessary to verify signatures which are =

>   =20 part of the archived data object itself.  This has to be done by=20

>   =20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20

>   =20 Protocol) or DVCS (Data Validation and Certification Server).=20

 

How=20 could the TAA give the evidence about the existence and integrity of a = document=20 without the data necessary for the verification of such evidence!? I = think that=20 we can discuss many things which the TAA standard should order or = recommend, but=20 it is no doubt that the TAA is obliged to give to a user all the = required data=20 necessary for existence and integrity proof of the appropriate document. = Without=20 this function the TAA would be only some type of data=20 store.

 

>   =20 This is done, in part, so the archive service can operate without =

>   =20 knowledge of numerous signed data formats, document formats, = etc.  It =

>   =20 also does not provide any means to integrate verification data in =

>  =20 data objects and verify embedded signatures.  This has to be done on=20

>   =20 the basis of other specifications, like RFC 3029 and with regard = to=20

>   =20 specifications of document formats. =20 Of course it is recommended to =

>   =20 use such specifications together with a Long-term Archive = Service.=20

 

In=20 this article of the draft, we can see that it is necessary to separate = the draft=20 work into several parallel standards. I.g. it is necessary either to = make the=20 RFC3029 into a form of an official standard or to define formats of = archiving=20 data.

 

We=20 cannot run the TAA without format specifications. The archive can accept = only=20 data it can guarantee to be able to view them in undistorted form during = the=20 whole archiving time. It is not possible for the TAA not to take care = for the=20 archived data formats. =20

 

Let=20 us have the following example: we have a record of important government = meeting=20 stored in the MS Word 3.0. Such document should be archived permanently, = but=20 what to do with the document in MS Word 3.0 format (even now you = probably will=20 have a trouble to view it without distortion!) Obviously, the TAA could = not=20 accept such document! =20

 

The=20 suggested draft does not take care about migration and emulation of = archived=20 documents.

 

------

 

The=20 lifetime of the archived document is also not solved in this draft. = According to=20 this draft, the archive only accepts and returns documents. It does not = take=20 care for document cataloging, searching of documents, viewing of = documents in=20 undistorted form and document = canceling.

 

But=20 document canceling seems to be very important archive functionality = – it does=20 not mean only destroying of the particular document but in some cases = also=20 export of the canceled document into another archive.  =

 

----

I am=20 afraid that the submitted draft is only the idea of IT people how to = archive=20 documents and it should be discussed with real archivists which have = their own=20 idea about archiving. The archivists have a different approach and to = create a=20 useful digital archive we should listen to them.=20

 

We must always keep in mind that the digital = archive=20 should offer al least the same services as the paper or parchment = archive.=20

 

Unfortunately the real archivist will decide = about law=20 and orders which will enable to replace paper archives with digital=20 ones.

 

Libor

------=_NextPart_000_0046_01C3E839.CF120370-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TC8hSW004505; Thu, 29 Jan 2004 04:08: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 i0TC8hTo004504; Thu, 29 Jan 2004 04:08: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.8) with ESMTP id i0TC8fXc004489 for ; Thu, 29 Jan 2004 04:08:42 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA10061; Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 29 Jan 2004 13:08:36 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0TC8Yt10628; Thu, 29 Jan 2004 13:08:34 +0100 (MET) Date: Thu, 29 Jan 2004 13:08:34 +0100 (MET) From: Peter Sylvester Message-Id: <200401291208.i0TC8Yt10628@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). Yes, and it seems that the question is to what degree the payload data are ... let's labelled or tainted with identification, types, roles, locations, etc. Such information need to be grouped in several categories depending on at least three interested parties: - the client itself, delegation of rights to employees or roles - the service (to distinguish groups of users, accounting, etc - other relying parties and external authorities (fiscal identification, locality, jurisdiction, ...) > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. There are many things which seems out of scope of this group. I am not sure whether one has to develop more than containers and type indications for identification data can be provided by/for a requester and for information can be associated to the request and response payloads so that these can be input for some decision making service using things like XACML SAML ... > My wiev is, that this two main functions might be separated (although > tightly corelated to the service), i.e. an authority identifying > subjects in an open environment or mapping the rights to a subject. For > example, as Peter stated, if I put something in the archive on behalf of > my company, who will access the same archive once I change my job? Where > are the connections between former and present employee? Just to remind another point: The authorition decision may not be possible 'on line' (as in many real life cases), thus a request to retrieve or validate cannot necessarily be answered immediately and may need manual intervention. Such a delay is not a problem, since it may be necessary to retrieve some disk from a bunker or else. Peter Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBaf2s001784; Thu, 29 Jan 2004 03:36:41 -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 i0TBafPB001783; Thu, 29 Jan 2004 03:36:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from gilmore.ael.be (gilmore.ael.be [158.64.60.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TBadhG001766 for ; Thu, 29 Jan 2004 03:36:39 -0800 (PST) (envelope-from adulau@foo.be) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id 3CCFB17347F; Thu, 29 Jan 2004 12:39:02 +0100 (CET) Received: by gilmore.ael.be (Postfix, from userid 519) id B814417347F; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gilmore.ael.be (Postfix) with ESMTP id B258E17F402; Thu, 29 Jan 2004 12:39:01 +0100 (CET) Date: Thu, 29 Jan 2004 12:39:01 +0100 (CET) From: Alexandre Dulaunoy X-X-Sender: adulau-conos@gilmore.ael.be To: "A. Jerman Blazic" Cc: "'Peter Sylvester'" , , Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication In-Reply-To: <006301c3e651$b9e1ac60$1b018ac1@arthur> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.3 required=7.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,WEIRD_PORT version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004, A. Jerman Blazic wrote: > > This identification (potentially in an anonymous form) is then > > associated by the provider with some authentication method: > > You get a user/password. 20 years later (and even earlier) you > > should be able to provide the same identification information > > (or better, the the id of your grandparents) to access. > > I agree with peter completely. I also think one needs to clarify what > procedures are we discussing about. Authorization is something that > gives you power (or not) to access or use something. While > identification is something else. So in case of archival services > authorization is seen through rights to use the service or not (and of > course the level of usage). However we still must keep the fact in mind > that whatever we are archiving always belongs to somebody (something??). > So the major question is: who has the rights to access the archived > item? And after that: how do we identify the person with the acess > rights? I think this should be clarified before we can even discuss the > operational steages of the service. Yes, you are right. Just for an example, the freearchive.org is setting up and the authorization is working on two methods : - An open approach (as we gather free works) with a manual verification of the work (on the legal (if the work is free) and technical side (if the work permits a long-term storage)). - An authenticated approach where the manual verification is bypassed as the submission is coming from trusted sources (can be people or other digital repositories with an OAI or alike interface). On the two methods, an unique ID is generated by the repository for tracking the life of the digital work. Freearchive is a specific case where all work are frees and can be distributed without any restrictions. I think, this approach is well-known in various public domain digital libraries. I don't know if you can take this easily in the draft document. For the operational stages that seem more complicated to explain. Thanks a lot for your work, adulau -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TAKREd094158; Thu, 29 Jan 2004 02:20:27 -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 i0TAKRMp094157; Thu, 29 Jan 2004 02:20:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0TAKPIW094138 for ; Thu, 29 Jan 2004 02:20:25 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 19210 invoked from network); 29 Jan 2004 10:14:44 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:44 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 17829-09 for ; Thu, 29 Jan 2004 11:14:25 +0100 (CET) Received: (qmail 19176 invoked from network); 29 Jan 2004 10:14:25 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 29 Jan 2004 10:14:25 -0000 From: "A. Jerman Blazic" To: "'Peter Sylvester'" , Cc: Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Thu, 29 Jan 2004 11:21:58 +0100 Message-ID: <006301c3e651$b9e1ac60$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200401281452.i0SEqMK07506@chandon.edelweb.fr> Importance: Normal X-Virus-Scanned: by amavisd-new at e5.ijs.si Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > > > Isn't Authentication 'at distance' but not 'in time'. > > > > Basically I see a problem concerning the time too. The methods of > > authentification may change during the lifetime of a document (even > > more than once). And with that you might get problems. > Let's e.g. say > > you archived a contract about your newly bought house or > something and > > used at the beginning user/password authentication. For the next 20 > > years you are basically probably not interested in the document and > > might even forget your password, although you still have the URL of > > the document with all the evidence records. In the future > maybe even > > user/password authentication is no longer accepted by the server so > > you need something different > > - but what is important for the system: are you the same > person that > > stored the document 20 years ago ? > > Even with user/password you don't make a proof that you are > the person that stored, only that some accesses who knows > these values. > > There is a difference betwenn identification and authentication. > > The 'user' is not your 'identification', but an means for > authentication. You long term identification are the data on > your birth certificate; thus, when you register to such a > service, you have probably always to provide some information > about who you are, a copy of your national id card or whatever. > > This identification (potentially in an anonymous form) is then > associated by the provider with some authentication method: > You get a user/password. 20 years later (and even earlier) you > should be able to provide the same identification information > (or better, the the id of your grandparents) to access. I agree with peter completely. I also think one needs to clarify what procedures are we discussing about. Authorization is something that gives you power (or not) to access or use something. While identification is something else. So in case of archival services authorization is seen through rights to use the service or not (and of course the level of usage). However we still must keep the fact in mind that whatever we are archiving always belongs to somebody (something??). So the major question is: who has the rights to access the archived item? And after that: how do we identify the person with the acess rights? I think this should be clarified before we can even discuss the operational steages of the service. My wiev is, that this two main functions might be separated (although tightly corelated to the service), i.e. an authority identifying subjects in an open environment or mapping the rights to a subject. For example, as Peter stated, if I put something in the archive on behalf of my company, who will access the same archive once I change my job? Where are the connections between former and present employee? Aleksej > > > > Authorisation: > > In my understanding authorisation comes after some kind of > authentication > > (i.e. at first you know the identity of the other and then > you think about > > to allow him access to the data). > > > A role based access control seems feasable and hopefully not to > > complicated. (Maybe added with some sercret (document id ?) > generated > > at the time of > > storage.) > > > > The "judge/relevant authority" is of course on. > > A second one will be the user who stored the data. (Of > course he wants to be > > able to receive the evidence and maybe even the data he stored.) > > You almost never have the situation that some data only > belongs to one person durng a long period in time. The most > simplistic authorisation model which just has a 1=1 > correspondance is not sufficient. You can die at any moment, > you can delegate your power to someone else at any time etc. > > > Small remark: If the trusted archive does not provide the > data itself > > to normal requests, the authorisation topic might be easy, > as I think > > the retrieval of evidence to a document might not be a > security issue. > > The request for evidence could contain either the data or a > hash-value > > of the data (as long as the hash-algorithm is still secure). > > A not so small response :-) > > A request to an archiver may live the following way: > > - someone has archived data and received an attestions that > contains the relevant metadata like: > "Person XYZ has archived a contract between A, B, C concerning xxx > at date D in the city of L conforming to law ZZZ and application > degree GGG etc. The concerned parties are fiscally related to FFF. > > The content of the document has the hash H1 with hashes h2 to Hn > for the chapters 2 to n", > all that (most likely), digitally signed by the archive provider > at the moment you receive it. > > - the digital signature can be confirmed with a hash link to > a published daily hash next day or there is an ability to present > the attestation to the archive provider asking whether this > attestation > is a good one by looking at his archive log. > > - If the relying parties can't agree, > or when this is a fiscal control, etc > a service needs to return the data. For this case > one cannot depend on the good will of the initial > client if the archived data are not in favor of his > claim. Thus, a judge or even the other party may > access. This may bring us to a requieremnt where > the initial archiver should be able to indicate > "identification information" of all the > potential concerned relying parties. This > identification information can be persons or > companies, but also "done at Paris" in order > to indicate that a judge in some court in Paris > may access. > > (If hash algs are not secure, you still have physical copies > that are dated.) > > > > > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEqQTk034198; Wed, 28 Jan 2004 06:52:26 -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 i0SEqQE0034197; Wed, 28 Jan 2004 06:52:26 -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.8) with ESMTP id i0SEqO9r034191 for ; Wed, 28 Jan 2004 06:52:24 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA29343; Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 28 Jan 2004 15:52:23 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0SEqMK07506; Wed, 28 Jan 2004 15:52:22 +0100 (MET) Date: Wed, 28 Jan 2004 15:52:22 +0100 (MET) From: Peter Sylvester Message-Id: <200401281452.i0SEqMK07506@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication 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: > > > > Isn't Authentication 'at distance' but not 'in time'. > > Basically I see a problem concerning the time too. The methods of > authentification may change during the lifetime of a document (even more > than once). And with that you might get problems. > Let's e.g. say you archived a contract about your newly bought house or > something and used at the beginning user/password authentication. For the > next 20 years you are basically probably not interested in the document and > might even forget your password, although you still have the URL of the > document with all the evidence records. In the future maybe even > user/password authentication is no longer accepted by the server so you need > something different > - but what is important for the system: are you the same person that stored > the document 20 years ago ? Even with user/password you don't make a proof that you are the person that stored, only that some accesses who knows these values. There is a difference betwenn identification and authentication. The 'user' is not your 'identification', but an means for authentication. You long term identification are the data on your birth certificate; thus, when you register to such a service, you have probably always to provide some information about who you are, a copy of your national id card or whatever. This identification (potentially in an anonymous form) is then associated by the provider with some authentication method: You get a user/password. 20 years later (and even earlier) you should be able to provide the same identification information (or better, the the id of your grandparents) to access. > > Authorisation: > In my understanding authorisation comes after some kind of authentication > (i.e. at first you know the identity of the other and then you think about > to allow him access to the data). > A role based access control seems feasable and hopefully not to complicated. > (Maybe added with some sercret (document id ?) generated at the time of > storage.) > > The "judge/relevant authority" is of course on. > A second one will be the user who stored the data. (Of course he wants to be > able to receive the evidence and maybe even the data he stored.) You almost never have the situation that some data only belongs to one person durng a long period in time. The most simplistic authorisation model which just has a 1=1 correspondance is not sufficient. You can die at any moment, you can delegate your power to someone else at any time etc. > Small remark: If the trusted archive does not provide the data itself to > normal requests, the authorisation topic might be easy, as I think the > retrieval of evidence to a document might not be a security issue. The > request for evidence could contain either the data or a hash-value of the > data (as long as the hash-algorithm is still secure). A not so small response :-) A request to an archiver may live the following way: - someone has archived data and received an attestions that contains the relevant metadata like: "Person XYZ has archived a contract between A, B, C concerning xxx at date D in the city of L conforming to law ZZZ and application degree GGG etc. The concerned parties are fiscally related to FFF. The content of the document has the hash H1 with hashes h2 to Hn for the chapters 2 to n", all that (most likely), digitally signed by the archive provider at the moment you receive it. - the digital signature can be confirmed with a hash link to a published daily hash next day or there is an ability to present the attestation to the archive provider asking whether this attestation is a good one by looking at his archive log. - If the relying parties can't agree, or when this is a fiscal control, etc a service needs to return the data. For this case one cannot depend on the good will of the initial client if the archived data are not in favor of his claim. Thus, a judge or even the other party may access. This may bring us to a requieremnt where the initial archiver should be able to indicate "identification information" of all the potential concerned relying parties. This identification information can be persons or companies, but also "done at Paris" in order to indicate that a judge in some court in Paris may access. (If hash algs are not secure, you still have physical copies that are dated.) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEG58c031639; Wed, 28 Jan 2004 06:16: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 i0SEG5MW031638; Wed, 28 Jan 2004 06:16:05 -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.8) with ESMTP id i0SEG3qO031631 for ; Wed, 28 Jan 2004 06:16:03 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (dpvc-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 i0SEG4h2021817; Wed, 28 Jan 2004 09:16:04 -0500 From: "Carl Wallace" To: "'Brian Hunter'" Cc: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Wed, 28 Jan 2004 09:15:59 -0500 Message-ID: <000701c3e5a9$43b7ab50$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4017B89E.4010801@sit.fraunhofer.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SEG4qO031632 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Archive Authority must be trusted if it is providing trust > anchor > information. > > I am not sure I follow this point. What would this trust anchor > information be? When verifying signatures that accrue over time, trust anchors may be necessary that are not active at the time of verification. An archive could serve as a repository for past trust anchors. An archive acting in this capacity would need to be trusted. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDrseD030452; Wed, 28 Jan 2004 05:53: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 i0SDrsle030451; Wed, 28 Jan 2004 05:53:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDrpfL030445 for ; Wed, 28 Jan 2004 05:53:52 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDrjOB025703; Wed, 28 Jan 2004 14:53:46 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:54:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D531A@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - authentication Date: Wed, 28 Jan 2004 14:54:02 +0100 Importance: low X-Priority: 5 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As suggested, I just take a subpart of the messages and add > some centimes in a brain storming way. > > > User authentication is another problem in wide scale deployment of > > archive services. Bearing in mind that privacy is one of the (more and > > more) important factor in open infrastructure, confidentiality is even > > more important in case of formal content handling (contracts, > > invoices!!). > > > Furthermore, DVCS exposes the content to authority at least, and has > > serious confidentiality problems... > > If you think about a chain of a notary that validates formal > content and then needs to store the data at some external > service, there is no formal way to ensure either encryption > or splitting so that the assertions from the backend service > can be matched with the statement from the > notary. Needs some work ... > > > I see the authentication problem quite similar and have at the moment > > not the optimal solution for it. :( > > User authentication doesn't seem for me a particular problem > for the archive service, it may or may not be a problem for > any large scale service. > > That's why I think we should not try and mandate a > particular way but allow for different techniques, including: > > - Access control on the transport level (e.g. SSL). > - Signatures in order to keep some proof. > - asynchronous staged processing for certain operations > where requests need to be confirmed by someone else. > > The meaning of 'Optimal' depends on the goals. I agree with you Peter. Seems to be better to allow authentication but we don't need to specify the used technique so that different services are free to implement what fits best. > > On the one side you have to be able to store data and with this the > > retrieval has to authenticated and access control has somehow to be > > applied. > > > > On the other hand how can one achieve authentication across very long > > times spans of decades ? > > Isn't Authentication 'at distance' but not 'in time'. Basically I see a problem concerning the time too. The methods of authentification may change during the lifetime of a document (even more than once). And with that you might get problems. Let's e.g. say you archived a contract about your newly bought house or something and used at the beginning user/password authentication. For the next 20 years you are basically probably not interested in the document and might even forget your password, although you still have the URL of the document with all the evidence records. In the future maybe even user/password authentication is no longer accepted by the server so you need something different - but what is important for the system: are you the same person that stored the document 20 years ago ? > But we talk about authorisation? It may be necessary to handle in > some way particular roles > like 'a judge/relevant authority' and then the access control > may require some 'entitlement'. This entity from the fiscal > service is entitled to access to data from company identified > by XXX'. how these meachnisms are implement now or in future > is not in our scope, I think what remains is that the > exchanged and stored information contain sufficient > 'metadata' indicating to whom the belong using good identifiers. > Either a client should explicitely set some identifiers in > requests, which need then matched against the authenticated > client id, or they are added by the server based on the > client id or maybe additional parameters in the request. Authorisation: In my understanding authorisation comes after some kind of authentication (i.e. at first you know the identity of the other and then you think about to allow him access to the data). A role based access control seems feasable and hopefully not to complicated. (Maybe added with some sercret (document id ?) generated at the time of storage.) The "judge/relevant authority" is of course on. A second one will be the user who stored the data. (Of course he wants to be able to receive the evidence and maybe even the data he stored.) Small remark: If the trusted archive does not provide the data itself to normal requests, the authorisation topic might be easy, as I think the retrieval of evidence to a document might not be a security issue. The request for evidence could contain either the data or a hash-value of the data (as long as the hash-algorithm is still secure). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDfEr1029083; Wed, 28 Jan 2004 05:41:14 -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 i0SDfERi029081; Wed, 28 Jan 2004 05:41:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDfBKT029074 for ; Wed, 28 Jan 2004 05:41:12 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0SDf3aL025070; Wed, 28 Jan 2004 14:41:04 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Wed, 28 Jan 2004 14:41:26 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5319@muc-mail5.ixos.de> From: Tobias Gondrom To: "'Peter Sylvester'" , aljosa@e5.ijs.si Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej - Confidentiality Date: Wed, 28 Jan 2004 14:41:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Confidentiality is something that will be probably one of the very > > important issues when independent Archive Providers want to offe this > > service to end users and smaller companies. (One mechanism I could > > imagine is that the users are submitting encrypted data/documents and > > solve most of there urgent problems with that.) > > To what degree do you trust your provider of the operating > system and the machine processor to not have a backdoor in > the system which will be activated when things happen in a > environment of a 'competitor'. My personal answer would be to trust only things that can be evaluated and that are actually evaluated (e.g. source from LINUX, large community working with Windows and ISV-Firewalls). In general I would say that customers rely on the reputation of a system, on results of independent tests (including hackers and audits) and some of the promises of the provider. > Encryption may be a solution for short term, otherwise in > real paranoia you need to physically split the data and store > then at places where you are reasonably sure that the > operators cannot cheat together without leaving some trace. > There are also various possible combinations of > in/out-sourcing. what seems important is that the > provider/operator of the service has an auditable system in a > very large sense. Maybe Peter is right and you simply have to trust your provider. :-/ (at least you have a contract and probably pay your provider for the service and the provider could gain some additional trust by independent audits) Still I am very sure we have to provide the ability to store (and provide evidence for) encrypted data. For many people this will be the first way to trust an external provider. (And in some countries it might also be forbidden to let the data even only theoretically be accessible to other persons) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDPOdW028250; Wed, 28 Jan 2004 05:25:24 -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 i0SDPO43028249; Wed, 28 Jan 2004 05:25:24 -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.8) with ESMTP id i0SDPMel028234 for ; Wed, 28 Jan 2004 05:25:23 -0800 (PST) (envelope-from brian.hunter@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-rogerrabbit [141.12.35.140]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id OAA04449; Wed, 28 Jan 2004 14:25:05 +0100 (MET) Message-ID: <4017B89E.4010801@sit.fraunhofer.de> Date: Wed, 28 Jan 2004 14:26:54 +0100 From: Brian Hunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl Wallace CC: "'Tobias Gondrom'" , ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ? References: <002401c3e50a$ee8f0590$6601a8c0@hq.orionsec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl Wallace wrote: >>For that I would prefer if we could change the names from : >>"Trusted Archiving" to "Archiving" >>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive > > Service" > > The word "trusted" provides a hint that something more than simple storage > of the data is going on (even if the actual trust is in the TSA). Also, an I agree. The differentiation between a simple archive service (only document storage) and an archive service that obtains evidence of document existence is important. > Archive Authority must be trusted if it is providing trust anchor > information. I am not sure I follow this point. What would this trust anchor information be? Regards, Brian Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJMicq051109; Tue, 27 Jan 2004 11:22: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 i0RJMibK051108; Tue, 27 Jan 2004 11:22:44 -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.8) with ESMTP id i0RJMcZC051101 for ; Tue, 27 Jan 2004 11:22:39 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-141-156-225-56.res.east.verizon.net [141.156.225.56]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0RJMdh2025494; Tue, 27 Jan 2004 14:22:39 -0500 From: "Carl Wallace" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ? Date: Tue, 27 Jan 2004 14:22:40 -0500 Message-ID: <002401c3e50a$ee8f0590$6601a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > For that I would prefer if we could change the names from : > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service" The word "trusted" provides a hint that something more than simple storage of the data is going on (even if the actual trust is in the TSA). Also, an Archive Authority must be trusted if it is providing trust anchor information. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJAbdr050374; Tue, 27 Jan 2004 11:10:37 -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 i0RJAbPT050373; Tue, 27 Jan 2004 11:10:37 -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.8) with ESMTP id i0RJAXto050366 for ; Tue, 27 Jan 2004 11:10:34 -0800 (PST) (envelope-from paul-andre.pays@edelweb.fr) Received: from edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA20324; Tue, 27 Jan 2004 20:10:32 +0100 (MET) Received: from edelweb.fr (pap2002.edelweb.fr [193.51.14.21]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 20:10:32 +0100 (MET) Message-ID: <4016B7B3.8090605@edelweb.fr> Date: Tue, 27 Jan 2004 20:10:43 +0100 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? References: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> In-Reply-To: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070309030606060405030308" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070309030606060405030308 Content-Type: multipart/alternative; boundary="------------080302060304000808090501" This is a multi-part message in MIME format. --------------080302060304000808090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable My 2 cts, * on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party=20 (no capital letters, but 100% independant from B). * on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "*trusted archiving*" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party". In short, I feel confortable with today terminology as long as a=20 glossary is provided which explains the semantic attached to each of=20 these terms (for example along the line of my above understanding), and=20 pinpoints the fact that the actual official nature (appropriately=20 separate archival service in some cases, effective trusted third party=20 in others) is completely context dependant. The context is the legal=20 context with the requirements for "evidence creation". LTANS should focus on technical solutions and not on these "legal"=20 environments. I you consider that the term "trusted" conveys too much third party=20 meening, I would accept "reliable archive" as long as it is explained=20 that reliable is not only related technical reliability but also=20 includes the appropriate independance (buwinesswise and legaly wise) -- PAP Tobias Gondrom wrote: > Hello, > > I would like to discuss in section 2 "Terminology" the name "Trusted=20 > Archiving" and TAA: > > This name "Trusted" is somehow confusing for me. For me "Trusted"=20 > implies that the archive is a somehow trusted third party that needs=20 > some evalutions by some government authority. I don't think that such=20 > is necessary. All the mechanisms to ensure the integrity of the data=20 > can be based on the trustworthyness of the TSP (that has to be a=20 > trusted third party as changing e.g. the time of the server would be=20 > disasterous). > > Of course the documents have to be stored and it has to be taken care=20 > that the needed steps of resigning are taken but all this is normal=20 > business. > > For that I would prefer if we could change the names from : > > "Trusted Archiving" to "Archiving" > And from: "Trusted Archive Authority" to "Archive Authority" or=20 > "Archive Service" > > Best regards > > Tobias > > > > > Tobias Gondrom > Senior Software Architect > Engineering > > *IXOS Software AG* > Technopark Neukeferloh > Bretonischer Ring 12 > D-85630 Grasbrunn/M=FCnchen > > E-Mail:_ __Tobias.Gondrom@ixos.de_ > WWW:_ __http://www.ixos.com_ > Tel: +49-89-4629-1816 > Fax: +49-89-4629-33-1816 > > This eMail may contain confidential and/or privileged information. If=20 > you are not the intended recipient or have received this eMail in=20 > error, please notify the sender immediately and destroy this eMail.=20 > Any use, disclosure or distribution of the material in this eMail is=20 > strictly forbidden. > > Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte=20 > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese=20 > eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den=20 > Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung,=20 > Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. > --=20 Paul-Andr=E9 PAYS pays@edelweb.fr ou papays@on-x.com Directeur EdelWeb & P=F4le S=E9curit=E9 Groupe ON-X http://www.edelweb.fr/ http://www.on-x.com/ tel: +33 1 40 99 29 55 fax : +33 1 40 99 03 30 ----- Pour v=E9rifier la signature : https://www.openevidence.org/OEROOT-ca.der= --------------080302060304000808090501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My 2 cts,

  • on one hand I agree with you the archive need not (in all cases) be operated by a third party (a separate legal entity with official gov'tal evaluation and possibly certification), it only requires the level of "separation of power" appropriate for the specific evidence creation context and requirements. When I say it only requires the appropriate independance, this should be understood as a very strong statement in many environments. For example in B2C transactions, because i) you can't expect the C(onsumer) side to reliably "archive" its own documents or "data certificates" on its Information System made of a single home PC, and ii) the "entity" owning the archive has the technical ability and power to "delete" these "evidences" and pretend these never existed; in this case it really has to be an independant party  (no capital letters, but 100% independant from B).
  • on the other hand -my understanding- this archive service must be completely reliable so that the concerned entities can "trust" it. Thus for me, "trusted archiving" is i) equivalent to "reliable archival service" (in a given context) and does not mean (necessarily) "Third Party".
In short, I feel confortable with today terminology as long as a glossary is provided which explains the semantic attached to each of these terms (for example along the line of my above understanding), and pinpoints the fact that the actual official nature (appropriately separate archival service in some cases, effective trusted third party in others) is completely context dependant. The context is the legal context with the requirements for "evidence creation".
LTANS should focus on technical solutions and not on these "legal" environments.
I you consider that the term "trusted" conveys too much third party meening, I would accept "reliable archive" as long as it is explained that reliable is not only related technical reliability but also includes the appropriate independance (buwinesswise and legaly wise)

-- PAP


Tobias Gondrom wrote:
RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ?

Hello,

I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA:

This name "Trusted" is somehow confusing for me. For me "Trusted" implies that the archive is a somehow trusted third party that needs some evalutions by some government authority. I don't think that such is necessary. All the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as changing e.g. the time of the server would be disasterous).

Of course the documents have to be stored and it has to be taken care that the needed steps of resigning are taken but all this is normal business.

For that I would prefer if we could change the names from :

"Trusted Archiving" to "Archiving"
And from: "Trusted Archive Authority" to "Archive Authority" or "Archive Service"

Best regards

        Tobias




Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/München

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden.

Diese eMail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielfältigung oder Weitergabe ist nicht gestattet.


-- 
Paul-André PAYS                 pays@edelweb.fr   ou  papays@on-x.com
Directeur 			EdelWeb & Pôle Sécurité Groupe ON-X
http://www.edelweb.fr/          http://www.on-x.com/
tel: +33 1 40 99 29 55          fax : +33 1 40 99 03 30
-----
Pour vérifier la signature : https://www.openevidence.org/OEROOT-ca.der
--------------080302060304000808090501-- --------------ms070309030606060405030308 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPDCC AvgwggHgoAMCAQICBD7XZsYwDQYJKoZIhvcNAQEEBQAwRTELMAkGA1UEBhMCV1cxFTATBgNV BAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGljaXBhbnRzIEF1dGhvcml0eTAeFw0w MzA1MzAxNDEyMzJaFw0wNDEwMTExNDEyMzJaMCgxCzAJBgNVBAYTAk5OMRkwFwYDVQQDFBBQ YXVsLUFuZHLDqSBQQVlTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtYu5hSua01K5B b63LMSSr/Tr2MQKjDRzEojvW/6tckP0sjJu7pOOCEvXca8EMUNRT4wF5ss/hOA2Mhn9gQsya kdimzAhLyX/2DxwXESlCCIC9JNPK3H9YZPSTspY4922XPR9np5brErHjw9B9ll474YLg1abi 5xpq+HQ2D/pcgQIDAQABo4GQMIGNMCUGA1UdEQQeMByBGnBhdWwtYW5kcmUucGF5c0BlZGVs d2ViLmZyMDgGCCsGAQUFBwEBBCwwKjAoBggrBgEFBQcwBIYcaHR0cHM6Ly93d3cub3BlbmV2 aWRlbmNlLm9yZzALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MA0GCSqGSIb3DQEBBAUAA4IBAQCzdZBQHrV+iuyxyP7YSVCsUKgOhXKwYfV1BKl+1bJvw11L rZzUmGaPrg0BUm3ETqrtEzvMq7yXkPUfRaDoEy0pmbRszvDPGjNKaGrP3/JaH9bXJtKxC1er 8ewCxCNcXH4mZwUhITUyHUoA6cSoShcW/elhbGQWhVnsxUHy82A4cFOH/G4lhVE9/tpnLOKS S1jmuW08Ic8/o4VUKeJlv3z7+Q+lyYQpbSpKs/N3qiAz7yhbeWU6GAOaX+iY9tTm2T1wXK69 72uqZbp31sxAlFjs/2q7FGk2FCwb/Pst20aUM4dDauK+vi5FV9XokI80YH/IpMxO+T+o+sPu Zh4TnrohMIIC+DCCAeCgAwIBAgIEPtdmxjANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJX VzEVMBMGA1UEChMMT3BlbkV2aWRlbmNlMR8wHQYDVQQDExZQYXJ0aWNpcGFudHMgQXV0aG9y aXR5MB4XDTAzMDUzMDE0MTIzMloXDTA0MTAxMTE0MTIzMlowKDELMAkGA1UEBhMCTk4xGTAX BgNVBAMUEFBhdWwtQW5kcsOpIFBBWVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK1i 7mFK5rTUrkFvrcsxJKv9OvYxAqMNHMSiO9b/q1yQ/SyMm7uk44IS9dxrwQxQ1FPjAXmyz+E4 DYyGf2BCzJqR2KbMCEvJf/YPHBcRKUIIgL0k08rcf1hk9JOyljj3bZc9H2enlusSsePD0H2W XjvhguDVpuLnGmr4dDYP+lyBAgMBAAGjgZAwgY0wJQYDVR0RBB4wHIEacGF1bC1hbmRyZS5w YXlzQGVkZWx3ZWIuZnIwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzAEhhxodHRwczovL3d3 dy5vcGVuZXZpZGVuY2Uub3JnMAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwDQYJKoZIhvcNAQEEBQADggEBALN1kFAetX6K7LHI/thJUKxQqA6FcrBh9XUE qX7Vsm/DXUutnNSYZo+uDQFSbcROqu0TO8yrvJeQ9R9FoOgTLSmZtGzO8M8aM0poas/f8lof 1tcm0rELV6vx7ALEI1xcfiZnBSEhNTIdSgDpxKhKFxb96WFsZBaFWezFQfLzYDhwU4f8biWF UT3+2mcs4pJLWOa5bTwhzz+jhVQp4mW/fPv5D6XJhCltKkqz83eqIDPvKFt5ZToYA5pf6Jj2 1ObZPXBcrr3va6plunfWzECUWOz/arsUaTYULBv8+y3bRpQzh0Nq4r6+LkVX1eiQjzRgf8ik zE75P6j6w+5mHhOeuiEwggNAMIICKKADAgECAgcQIHgomHZRMA0GCSqGSIb3DQEBBAUAMDgx CzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxEjAQBgNVBAMTCUF1dGhvcml0 eTAeFw0wMjA1MDcxNDQ4MjFaFw0xMjA1MDQxNDQ4MjFaMEUxCzAJBgNVBAYTAldXMRUwEwYD VQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRZ0ovIMoH0rNd3Kh5108NViqZ3OkpU4Ze 1EkvwSEMab+tpLKPxijhM8fHW89W1ZvCRPfNvGyliDavK/rwp2EeeB0POTBjxjuHkYsFjFgE pAU2qpiikptBd0K5HvtYDksIapCTbzBB5/77Kh+X8g7NxETqt7rZDTnns0VmJrJGI/6m8GUP FEPV0ulDwOEk4uutdPE4vNkadAbe8OrBVhMgVs5M0Y6/wCYDt7tzu3dUWi6cws7PQiFFjEI1 N0LHaR7kcODOOoJSNG6WuQmRQRZGRQqYsE9316DpEqEOYpXjxLtj9TI1HmrYtJjeDRdNM7qV MgCdhhMc6DjqD+9pf0yFAgMBAAGjQjBAMA8GA1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBSwGAKKzw/hQilrVrPW1UxszLdAWzANBgkqhkiG9w0BAQQFAAOCAQEA +D1M7ixKqQ7eN3HsXl9+dULna7sMZ07/7AnGgHjIltM7oelpftJUwW2/zHUaTxy9sxSXiKTr fuTxwvNOANQN6BM1h0EJxSqYiKyRzzxYCohmfgllStIU3U3Q+mCvaUma5FLhzBfkfOk/VtFy 6jK+6WqUluftBtx7/gXmvA8fbtcxcvTJ80rQHM+bR26VQhPwVXUP7k5ED8EBVee2TUa/117B 6lFQAL3V4XJuRVUJ+UMUAJBc7VN/eJfPOOpTn3l+gMuhoSZP+oLEXG1+eTK/ht8kjo+jXZPV Op+G0tVXibWmepsTHj+ahH6b7u4/Zbe6V2M4H2L+rhRahM0/7BwUtzGCAmYwggJiAgEBME0w RTELMAkGA1UEBhMCV1cxFTATBgNVBAoTDE9wZW5FdmlkZW5jZTEfMB0GA1UEAxMWUGFydGlj aXBhbnRzIEF1dGhvcml0eQIEPtdmxjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDAxMjcxOTEwNDNaMCMGCSqGSIb3DQEJBDEW BBSqJJNNrvysQxk0a+YUja1A/S0FRzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDBc BgkrBgEEAYI3EAQxTzBNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2Ux HzAdBgNVBAMTFlBhcnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwXgYLKoZIhvcNAQkQAgsx T6BNMEUxCzAJBgNVBAYTAldXMRUwEwYDVQQKEwxPcGVuRXZpZGVuY2UxHzAdBgNVBAMTFlBh cnRpY2lwYW50cyBBdXRob3JpdHkCBD7XZsYwDQYJKoZIhvcNAQEBBQAEgYA23Zr7+yEn/2Ql UIPx2Icq0GIMPvsdHY5xCs8LA+P+knQUqRjhyDFjmxjUl+69gLe4IExuOES2URkooFTX+B3R u/KoDSDKcoX2YpET9iyE/7rOmf3To1NG7yXprl5rK0NMarM+UEiVDWm4Pj7UavU9vbW0Q1+S BOkMq64g602iWQAAAAAAAA== --------------ms070309030606060405030308-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIg2cr048474; Tue, 27 Jan 2004 10:42:02 -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 i0RIg2d5048473; Tue, 27 Jan 2004 10:42:02 -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.8) with ESMTP id i0RIfw4g048464 for ; Tue, 27 Jan 2004 10:42:01 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA19969; Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:41:58 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIfv105360; Tue, 27 Jan 2004 19:41:57 +0100 (MET) Date: Tue, 27 Jan 2004 19:41:57 +0100 (MET) From: Peter Sylvester Message-Id: <200401271841.i0RIfv105360@chandon.edelweb.fr> To: ietf-ltans@imc.org, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > This name "Trusted" is somehow confusing for me. For me "Trusted" implies > that the archive is a somehow trusted third party that needs some evalutions > by some government authority. I don't think that such is necessary. All the > mechanisms to ensure the integrity of the data can be based on the > trustworthyness of the TSP (that has to be a trusted third party as changing > e.g. the time of the server would be disasterous). You loose integrity of data when you loose the data. I guess you need to trust that the archive service 'does its best'. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIXv62047866; Tue, 27 Jan 2004 10:33:57 -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 i0RIXvnq047865; Tue, 27 Jan 2004 10:33:57 -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.8) with ESMTP id i0RIXtmf047856 for ; Tue, 27 Jan 2004 10:33:55 -0800 (PST) (envelope-from Peter.Sylvester@EdelWeb.fr) Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA19930; Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 27 Jan 2004 19:33:51 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0RIXoN05349; Tue, 27 Jan 2004 19:33:50 +0100 (MET) Date: Tue, 27 Jan 2004 19:33:50 +0100 (MET) From: Peter Sylvester Message-Id: <200401271833.i0RIXoN05349@chandon.edelweb.fr> To: aljosa@e5.ijs.si, tobias.gondrom@ixos.de Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej 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: As suggested, I just take a subpart of the messages and add some centimes in a brain storming way. > User authentication is another problem in wide scale deployment of archive > services. Bearing in mind that privacy is one of the (more and more) > important factor in open infrastructure, confidentiality is even more > important in case of formal content handling (contracts, invoices!!). > Furthermore, DVCS exposes the content to authority at least, and has serious > confidentiality problems... If you think about a chain of a notary that validates formal content and then needs to store the data at some external service, there is no formal way to ensure either encryption or splitting so that the assertions from the backend service can be matched with the statement from the notary. Needs some work ... > I see the authentication problem quite similar and have at the moment not > the optimal solution for it. :( User authentication doesn't seem for me a particular problem for the archive service, it may or may not be a problem for any large scale service. That's why I think we should not try and mandate a particular way but allow for different techniques, including: - Access control on the transport level (e.g. SSL). - Signatures in order to keep some proof. - asynchronous staged processing for certain operations where requests need to be confirmed by someone else. The meaning of 'Optimal' depends on the goals. > On the one side you have to be able to store data and with this the > retrieval has to authenticated and access control has somehow to be applied. > > On the other hand how can one achieve authentication across very long times > spans of decades ? Isn't Authentication 'at distance' but not 'in time'. But we talk about authorisation? It may be necessary to handle in some way particular roles like 'a judge/relevant authority' and then the access control may require some 'entitlement'. This entity from the fiscal service is entitled to access to data from company identified by XXX'. how these meachnisms are implement now or in future is not in our scope, I think what remains is that the exchanged and stored information contain sufficient 'metadata' indicating to whom the belong using good identifiers. Either a client should explicitely set some identifiers in requests, which need then matched against the authenticated client id, or they are added by the server based on the client id or maybe additional parameters in the request. > Confidentiality is something that will be probably one of the very important > issues when independent Archive Providers want to offe this service to end > users and smaller companies. (One mechanism I could imagine is that the > users are submitting encrypted data/documents and solve most of there urgent > problems with that.) To what degree do you trust your provider of the operating system and the machine processor to not have a backdoor in the system which will be activated when things happen in a environment of a 'competitor'. Encryption may be a solution for short term, otherwise in real paranoia you need to physically split the data and store then at places where you are reasonably sure that the operators cannot cheat together without leaving some trace. There are also various possible combinations of in/out-sourcing. what seems important is that the provider/operator of the service has an auditable system in a very large sense. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIKU6N046948; Tue, 27 Jan 2004 10:20: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 i0RIKUfD046947; Tue, 27 Jan 2004 10:20:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.31.93.ixos.de [149.235.31.93]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RIKQXe046936 for ; Tue, 27 Jan 2004 10:20:29 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from MUCXG02.ixos.de (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.9/8.12.9) with ESMTP id i0RIKLqC019146 for ; Tue, 27 Jan 2004 19:20:21 +0100 (MET) Received: by MUCXG02.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 19:20:42 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5312@muc-mail5.ixos.de> From: Tobias Gondrom To: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ? Date: Tue, 27 Jan 2004 19:20:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E502.40D91650" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E502.40D91650 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I would like to discuss in section 2 "Terminology" the name "Trusted Archiving" and TAA: This name "Trusted" is somehow confusing for me. For me "Trusted" = implies that the archive is a somehow trusted third party that needs some = evalutions by some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous). Of course the documents have to be stored and it has to be taken care = that the needed steps of resigning are taken but all this is normal = business. For that I would prefer if we could change the names from : "Trusted Archiving" to "Archiving"=20 And from: "Trusted Archive Authority" to "Archive Authority" or = "Archive Service" Best regards Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/M=FCnchen E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com =20 Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C3E502.40D91650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Initial requirements for long-term archive I-D - wording: = Trusted archiving ?

Hello,

I would like to discuss in section 2 = "Terminology" the name "Trusted Archiving" and = TAA:

This name "Trusted" is = somehow confusing for me. For me "Trusted" implies that the = archive is a somehow trusted third party that needs some evalutions by = some government authority. I don't think that such is necessary. All = the mechanisms to ensure the integrity of the data can be based on the = trustworthyness of the TSP (that has to be a trusted third party as = changing e.g. the time of the server would be disasterous).

Of course the documents have to be = stored and it has to be taken care that the needed steps of resigning = are taken but all this is normal business.

For that I would prefer if we could = change the names from :

"Trusted Archiving" to = "Archiving"
And from: "Trusted Archive = Authority" to "Archive Authority" or "Archive = Service"

Best regards

        Tobias




Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may = contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the sender immediately and destroy this eMail. Any use, disclosure or = distribution of the material in this eMail is strictly = forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie bitte sofort den Absender und vernichten Sie diese = eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe = ist nicht gestattet.

------_=_NextPart_001_01C3E502.40D91650-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RHBoi2040670; Tue, 27 Jan 2004 09:11: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 i0RHBocJ040667; Tue, 27 Jan 2004 09:11:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.89.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RHBlEd040642 for ; Tue, 27 Jan 2004 09:11:48 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i0RHBaeX018377; Tue, 27 Jan 2004 18:11:41 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jan 2004 18:12:08 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D5308@muc-mail5.ixos.de> From: Tobias Gondrom To: "'A. Jerman Blazic'" Cc: ietf-ltans@imc.org Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej Date: Tue, 27 Jan 2004 18:11:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E4F8.A54F3600" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3E4F8.A54F3600 Content-Type: text/plain Dear Aleksej, Dear Tobias and others First of all, I am pleased LTANS did produce one of the first discussable drafts. Thanks. The same for me. In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management". Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself). I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored. Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand) User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems... I see the authentication problem quite similar and have at the moment not the optimal solution for it. :( On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied. On the other hand how can one achieve authentication across very long times spans of decades ? Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.) [see also page 9 bottom: "protocol should permit encryption of data before submission..." ] On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy? It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5] Hope this will trigger some discussion... Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....) For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list. Regards Tobias ------_=_NextPart_001_01C3E4F8.A54F3600 Content-Type: text/html Message
Dear Aleksej,
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first discussable drafts.
 
Thanks. The same for me.
In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time  (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management".  
Here I fully agree. That is why Carl and I voted for two RFCs that will be devloped on the requirements paper. One concerning the protocol and one concerning the Data structure (which naturally is bound to the archive itself).
I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... 
For conservation mechanisms traditional timestamps shall be used and aggregated in a defined way so that complete chains of timestamps are generated for the whole time the data is stored.
 
Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. 
 
Fully agree. We don't have to specify this in the protocol or data structures. Of course there must not be a contradiction to these requirements from the planned specifications. For this reason its included in the requirements paper. (as far as I understand)
User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems...
 
I see the authentication problem quite similar and have at the moment not the optimal solution for it. :(
On the one side you have to be able to store data and with this the retrieval has to authenticated and access control has somehow to be applied.
On the other hand how can one achieve authentication across very long times spans of decades ?
 
Confidentiality is something that will be probably one of the very important issues when independent Archive Providers want to offe this service to end users and smaller companies. (One mechanism I could imagine is that the users are submitting encrypted data/documents and solve most of there urgent problems with that.)
[see also page 9 bottom: "protocol should permit encryption of data before submission..." ]
 On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy?
It depends. As long as the content is always accessible by the service (what is necessary when a Hash-Algorithm fails - until then you can mostly work with hash values). But it is dependent on the use case not necessary that the archive Service is also functioning as a document store from which you can later also retrive the data - not only the evidence. [see also "pure long-term non-repudiation service" on page 5]
Hope this will trigger some discussion...
 
Hoping the same and thank you. (and please forgive me that my answer came so late - I was for some days on winter holiday....)
 
For further discussion I encourage anyone to feel free and isolate any topic he wants from the conversation and discuss it on the mailing-list.
 
Regards
 
    Tobias
 
------_=_NextPart_001_01C3E4F8.A54F3600-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DGxTib050400; Tue, 13 Jan 2004 08:59:29 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DGxTnP050399; Tue, 13 Jan 2004 08:59:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0DGxNib050388 for ; Tue, 13 Jan 2004 08:59:23 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 17249 invoked from network); 13 Jan 2004 16:54:23 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:23 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 15667-10 for ; Tue, 13 Jan 2004 17:54:23 +0100 (CET) Received: (qmail 17239 invoked from network); 13 Jan 2004 16:54:22 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 13 Jan 2004 16:54:22 -0000 From: "A. Jerman Blazic" To: "'Tobias Gondrom'" , Subject: RE: Initial requirements for long-term archive I-D Date: Tue, 13 Jan 2004 17:59:14 +0100 Message-ID: <00ac01c3d9f6$92db8cb0$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C3D9FE.F49FF4B0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> X-Virus-Scanned: by amavisd-new at e5.ijs.si 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_00AD_01C3D9FE.F49FF4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Tobias and others =20 First of all, I am pleased LTANS did produce one of the first discussable drafts. =20 In the first place I do have some views on the general document structure, which is very "Trusted Archive Protocol" oriented. In my view, one has to distinguish two main logical parts of the archive, which is protocol interaction mechanisms, i.e. trusted archive protocol or a point of user's interaction with an archive. The other is archive itself and integrated mechanisms for assuring object validity over defined or undefined period of time (I do distinguish at least two measures of archiving period, although e-archiving is tightly related to needs/requirements/obligations on content archiving, so many "time-frame" definitions are possible) in combination with archived object "management". I guess data structures are trying to focus on later but conservation mechanisms seems like missing or at least no indirect linkage to additional specifications are mentioned, of course if there are some (XAdES??).... =20 Next, in the document (page 4) redundant storage, disaster recovery, etc. are mentioned. Data storage mechanisms should be out of the scope of the e-archive, since back-up mechanisms and systems are something which one can find on, let's say, "lower" infrastructure layer and should be dealt as is. =20 User authentication is another problem in wide scale deployment of archive services. Bearing in mind that privacy is one of the (more and more) important factor in open infrastructure, confidentiality is even more important in case of formal content handling (contracts, invoices!!). Furthermore, DVCS exposes the content to authority at least, and has serious confidentiality problems... =20 On page 5 and 6, TAA is presented as a document storage service, which in certain case doesn't have to. My personal view is, that archiving does not mean only archiving service but extended functionality of existing document warehouses or management systems. In this case, TAA is a service maintaining only archiving related data and not content by itself, i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means single point of interaction for many content related services. Do we really need such content redundancy? =20 Hope this will trigger some discussion... =20 Regards =20 Aleksej -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Tobias Gondrom Sent: Monday, January 12, 2004 6:41 PM To: 'ietf-ltans@imc.org' Subject: Initial requirements for long-term archive I-D=20 Importance: High Hello,=20 Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D "=20 (first milestone, unfortunately 6 weeks behind schedule)=20 <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data structures and protocol) will be targeting to fulfill the discussed requirements. The initial drafts for these 2 documents are also behind schedule but initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind:=20 - discuss the different sections for the document individually=20 - if possible list the chapter you want to change and the old and the new text to make it easier for the others to follow the discussion and for the editor. At the moment there are even topics for dicusiion open from the writing of the initial paper.=20 Best regards=20 Tobias=20 Tobias Gondrom=20 Senior Software Architect=20 Engineering=20 IXOS Software AG=20 Technopark Neukeferloh=20 Bretonischer Ring 12=20 D-85630 Grasbrunn/M=FCnchen=20 E-Mail: Tobias.Gondrom@ixos.de=20 WWW: http://www.ixos.com=20 Tel: +49-89-4629-1816=20 Fax: +49-89-4629-33-1816=20 This eMail may contain confidential and/or privileged information. If you are not the intended recipient or have received this eMail in error, please notify the sender immediately and destroy this eMail. Any use, disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------=_NextPart_000_00AD_01C3D9FE.F49FF4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first = discussable=20 drafts.
 
In the first place I do have some views on the = general document=20 structure, which is very "Trusted Archive Protocol" oriented. In my = view, one=20 has to distinguish two main logical parts of the archive, which is = protocol=20 interaction mechanisms, i.e. trusted archive protocol or a point of = user's=20 interaction with an archive. The other is archive itself and integrated=20 mechanisms for assuring object validity over defined or undefined period = of time=20 (I do distinguish at least two measures of archiving period, although=20 e-archiving is tightly related to needs/requirements/obligations on = content=20 archiving, so many "time-frame" definitions are possible) in combination = with=20 archived object "management". I guess data structures are trying to = focus on=20 later but conservation mechanisms seems like missing or at least no = indirect linkage to additional specifications are mentioned, of course = if there=20 are some (XAdES??)....
 
Next, in the document (page 4) = redundant storage,=20 disaster recovery, etc. are mentioned. Data storage mechanisms = should be=20 out of the scope of the e-archive, since back-up mechanisms and systems = are=20 something which one can find on, let's say, "lower" infrastructure=20 layer and should be dealt as = is.
 
User authentication is another problem in = wide scale=20 deployment of archive services. Bearing in mind that privacy is one of = the (more=20 and more) important factor in open infrastructure, confidentiality is = even more=20 important in case of formal content handling (contracts, invoices!!).=20 Furthermore, DVCS exposes the content to authority at least, and has = serious=20 confidentiality problems...
 
On page 5 and 6, TAA is presented as a = document storage=20 service, which in certain case doesn't have to. My personal view is, = that=20 archiving does not mean only archiving service but extended = functionality of=20 existing document warehouses or management systems. In this case, TAA is = a=20 service maintaining only archiving related data and not content by = itself,=20 i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means = single=20 point of interaction for many content related services. Do we really = need such=20 content redundancy?
 
Hope this will trigger some=20 discussion...
 
Regards
 
Aleksej
-----Original Message-----
From:=20 owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] = On=20 Behalf Of Tobias Gondrom
Sent: Monday, January 12, 2004 = 6:41=20 PM
To: 'ietf-ltans@imc.org'
Subject: Initial = requirements=20 for long-term archive I-D
Importance: = High

Hello,

Thanks to Carl, Uli and Ralf we = finished the=20
"Initial requirements for long-term archive = I-D=20 "
(first milestone,=20 unfortunately 6 weeks behind schedule)
<<draft-ietf-ltans-reqs-01.txt>> =

I would like to encourage now the = discussion for=20 this draft on the mailing-list as fast as possible as the following = standards=20 (data structures and protocol)  will be targeting to fulfill the=20 discussed requirements. The initial drafts for these 2 documents are = also=20 behind schedule but initial documents shall be available for = discussion end of=20 january.

Please keep best practices for the = discussion in=20 mind:
- discuss the different = sections for=20 the document individually
- if = possible=20 list the chapter you want to change and the old and the new text to = make it=20 easier for the others to follow the discussion and for the = editor.

At the moment there are even topics for = dicusiion=20 open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG =
Technopark Neukeferloh
Bretonischer=20 Ring 12
D-85630 = Grasbrunn/M=FCnchen=20

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com =
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain = confidential=20 and/or privileged information. If you are not the intended recipient = or have=20 received this eMail in error, please notify the sender immediately and = destroy=20 this eMail. Any use, disclosure or distribution of the material in = this eMail=20 is strictly forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich=20 gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind = oder diese=20 eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und=20 vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder=20 Weitergabe ist nicht gestattet.

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHfBib096845; Mon, 12 Jan 2004 09:41:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CHfBDt096844; Mon, 12 Jan 2004 09:41:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.89.ixos.de [149.235.31.89]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CHf2ib096817 for ; Mon, 12 Jan 2004 09:41:09 -0800 (PST) (envelope-from tobias.gondrom@ixos.de) Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i0CHeswI004219 for ; Mon, 12 Jan 2004 18:40:55 +0100 (MET) Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id ; Mon, 12 Jan 2004 18:40:54 +0100 Message-ID: <077097E85A6BD3119E910800062786A9094D529C@muc-mail5.ixos.de> From: Tobias Gondrom To: "'ietf-ltans@imc.org'" Subject: Initial requirements for long-term archive I-D Date: Mon, 12 Jan 2004 18:40:52 +0100 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3D933.398CBCB0" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3D933.398CBCB0" ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Thanks to Carl, Uli and Ralf we finished the=20 "Initial requirements for long-term archive I-D " (first milestone, unfortunately 6 weeks behind schedule) <>=20 I would like to encourage now the discussion for this draft on the mailing-list as fast as possible as the following standards (data = structures and protocol) will be targeting to fulfill the discussed requirements. = The initial drafts for these 2 documents are also behind schedule but = initial documents shall be available for discussion end of january. Please keep best practices for the discussion in mind: - discuss the different sections for the document individually - if possible list the chapter you want to change and the old and the = new text to make it easier for the others to follow the discussion and for = the editor. At the moment there are even topics for dicusiion open from the writing = of the initial paper. Best regards Tobias Tobias Gondrom Senior Software Architect Engineering IXOS Software AG Technopark Neukeferloh Bretonischer Ring 12 D-85630 Grasbrunn/M=FCnchen E-Mail: Tobias.Gondrom@ixos.de WWW: http://www.ixos.com =20 Tel: +49-89-4629-1816 Fax: +49-89-4629-33-1816 This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. ------_=_NextPart_001_01C3D933.398CBCB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Initial requirements for long-term archive I-D

Hello,

Thanks to Carl, Uli and Ralf we = finished the
"Initial requirements for long-term archive I-D "
(first milestone, unfortunately 6 = weeks behind schedule)
= <<draft-ietf-ltans-reqs-01.txt>>

I would like to encourage now the = discussion for this draft on the mailing-list as fast as possible as = the following standards (data structures and protocol)  will be = targeting to fulfill the discussed requirements. The initial drafts for = these 2 documents are also behind schedule but initial documents shall = be available for discussion end of january.

Please keep best practices for the = discussion in mind:
- discuss the different sections for = the document individually
- if possible list the chapter you = want to change and the old and the new text to make it easier for the = others to follow the discussion and for the editor.

At the moment there are even topics = for dicusiion open from the writing of the initial paper.

Best regards

        Tobias



Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: Tobias.Gondrom@ixos.de
WWW: http://www.ixos.com
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may = contain confidential and/or privileged information. If you are not the = intended recipient or have received this eMail in error, please notify = the sender immediately and destroy this eMail. Any use, disclosure or = distribution of the material in this eMail is strictly = forbidden.

Diese eMail enth=E4lt vertrauliche = und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der = richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, = informieren Sie bitte sofort den Absender und vernichten Sie diese = eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe = ist nicht gestattet.

------_=_NextPart_001_01C3D933.398CBCB0-- ------_=_NextPart_000_01C3D933.398CBCB0 Content-Type: text/plain; name="draft-ietf-ltans-reqs-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltans-reqs-01.txt" Internet Draft Carl Wallace=20 draft-ietf-ltans-reqs-01.txt Orion Security Solutions=20 January 2004 Ralf Brandner=20 Expires July 2004 InterComponentWare AG Walldorf Ulrich Pordesch=20 Fraunhofer Institute=20 Secure Telecooperation=20 =20 =20 Long-term Archive Service Requirements=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of [RFC2026]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced or made obsolete by other documents at=20 any time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2004). All Rights Reserved.=20 =20 Abstract=20 =20 In many scenarios, users need to be able to ensure and prove the=20 existence and integrity of data, especially digitally signed data, = in a common and reproducible way over a long and possibly undetermined=20 period of time. This document specifies the technical requirements=20 for a long-term archive service to support such scenarios.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=20 document are to be interpreted as described in [RFC2119].=20 Wallace Expires July 2004 [Page 1] =0C Long-term archive service requirements January 2004=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Terminology....................................................3=20 3. Application scenarios and general requirements.................4=20 3.1 Long-term archive problems and tasks.......................4=20 3.2 Long-term Archive Service..................................5=20 3.3 Instances and overall architecture.........................7=20 4. Long-term Archive Service functional and quality requirements..8=20 5. Long-term Archive Service data structure requirements..........9=20 6. Long-term Archive Service Protocol requirements...............10=20 7. Security Considerations.......................................11=20 8. Acknowledgements..............................................11=20 9. Normative References..........................................11=20 10. Authors' Addresses...........................................13=20 =20 =20 1. Introduction=20 =20 Various scenarios require the ability to preserve digital data and=20 its value as evidence for long periods of time. If data is = important=20 and will be needed in the future, it is necessary to store it in a=20 highly secure and persistent way. If the data is needed as evidence=20 in court, it may be necessary to prove that the existed at a certain = time in the past and has not been modified since then. If data is=20 signed or timestamped it is necessary to prove that it existed = before=20 cryptographic algorithms used to generate its signatures became weak = or the certificates expired or were revoked. =20 =20 A long-term archive service aids in the preservation of data over=20 long periods of time. In particular, it periodically performs=20 activities to preserve the non-repudiation of existence and = integrity=20 as well as ensuring the availability of data.=20 =20 A variety of technical and operational means are required to achieve = this goal and technical issues beyond cryptography, such as storage=20 media lifetime, disaster planning, changes in processing or software = technology, etc., as well as legal issues must be addressed.=20 =20 It is anticipated that a timestamp will be obtained for data = submitted to a long-term archive service. Thus, for all types of data, i.e.=20 signed and unsigned, will require preservation of evidence value by=20 the long-term archive service. =20 =20 Any digital signature that may need to be verified at points in time = well into the future, e.g. past the certificate validity period or=20 past the cryptoperiod of the signature private key, is a candidate=20 for preservation using a long-term archive service. Examples = include=20 =20 =20 Wallace Expires July 2004 [Page 2] =0C Long-term archive service requirements January 2004=20 signed contracts or agreements, wills, property deeds, CRLs and=20 timestamps over any type of data. The service will provide means to = prove the integrity and time of existence of the data at a given=20 point in time. It must be provable that the data is reliable,=20 because it existed at a point in time in the past when e.g. the=20 embedded hash and signature algorithms were still strong and the=20 included certificates were not revoked.=20 =20 This document aims to identify the technical requirements for a = long- term archive service. The=20 requirements analysis is divided into two parts.=20 The first part presents several application=20 scenarios. The second part addresses more specific requirements for = functions of the service, data structures to support preservation of data integrity using cryptographic mechanisms and at least protocol=20 requirements for interacting with a long-term archive service.=20 =20 Operational requirements, such as storage media concerns, individual = legal requirements and questions dealing with accounting and billing = techniques are not addressed by this document. However, the=20 transaction data and protocols must allow information to be carried=20 either directly or indirectly to facilitate association of=20 transactions with some accounting and billing mechanism, e.g.=20 identifiers for individual clients and/or large customers.=20 =20 =20 2. Terminology=20 =20 Arbitrator: Person, who has to be convinced of various aspects of=20 authenticity (originator, integrity, time of existence) of archived=20 data objects.=20 =20 Archived data object: Data unit that is archived and has to be=20 preserved for a long time by the Long-term Archive Service. =20 =20 Archive package: Collection of information including archived data=20 objects and the associated evidence record.=20 =20 Evidence: Information that may be used to resolve a dispute about=20 various aspects of authenticity of archived data objects. =20 =20 Evidence record: Collection of evidence compiled for one or more=20 given archived data objects over time. An evidence record may=20 include timestamps and additional verification data, like=20 certificates, revocation information, trust anchors, policy details, = role information, etc.=20 =20 Originator: Role (person or process) who produces, and possibly=20 signs, a data object that is to be archived. The Originator does=20 not necessarily generate or request generation of an evidence record = for the data.=20 =20 =20 Wallace Expires July 2004 [Page = 3] =0C Long-term archive service requirements January 2004=20 Timestamp: A signed confirmation generated by a Time Stamping=20 Authority (TSA) that a data item existed at a certain time. =20 [RFC3161] specifies a good structure for timestamps and a protocol=20 for communicating with a Timestamp Authority (TSA). =20 =20 Trusted Archiving: A process that includes storing of data objects=20 for long periods of time preserving its integrity, periodic=20 generation of timestamps and collection of evidence in support of=20 long-term preservation of data integrity.=20 =20 Trusted archive authority (TAA): A service responsible for=20 preserving data for long periods of time, including generation and=20 collection of evidence, storage of archived data objects and=20 evidence, etc. A.K.A. Long-term archive service. =20 =20 User: Role (person or process), who submit data objects for=20 archiving, request archive packages and verify the evidence of an=20 archived data object using the associated evidence record,=20 optionally including the verification of any signatures within the=20 archived data object itself. =20 =20 =20 3. Application scenarios and general requirements=20 =20 =20 3.1 Long-term archive problems and tasks=20 =20 A Long-term Archive Service has to be designed to cover several=20 problems in the area of long-term archiving of data objects. The=20 following sections describe some of these problems.=20 =20 3.1.1 Availability and integrity of data for long periods of time=20 =20 Individuals, companies and organisations are facing the problem of=20 how to store electronic documents in a safe way for sometimes even=20 undetermined spans of time. Examples include digital contracts, tax = declarations or electronic birth certificates. These documents need = special care in order to ensure persistent readability, permanent=20 availability, integrity and proper protection of confidentiality. =20 While some large organisations may be capable of supporting=20 appropriate backup, archive and protection mechanisms citizens and=20 small enterprises lack the technical prerequisites for this task. =20 Service providers offering external services for such documents are=20 thus needed.=20 =20 3.1.2 Demonstration of proof of existence and integrity for court=20 =20 Many archived documents are valuable and may be used as evidence in=20 court at some point in the future, e.g. to prove entitlements to=20 =20 =20 Wallace Expires July 2004 [Page 4] =0C Long-term archive service requirements January 2004=20 benefits or damages. In this case, it might be required to prove=20 that these documents existed at a certain time in the past and where = not modified since that time. =20 =20 3.1.3 Preservation of evidence for signed or timestamped data=20 =20 Archived data objects may contain digital signatures or time stamps=20 to be able to prove the origin and the time of existence of these=20 objects and signatures. In the course of time the value of evidence = of these signatures or timestamps can decrease or can get lost for=20 many reasons:=20 =20 - Revocation information is no longer available due to the=20 decommissioning of a CA or OCSP responder;=20 =20 - Lack of availability of certificates necessary to verify a=20 digital signature;=20 =20 - Expiration or Revocation of a certificate associated with a=20 digital signature;=20 =20 - Cryptanalytic or computational advances make it possible to=20 forge documents and signatures or to compute secret keys.=20 =20 In order to avoid problems in case of disputes in the future it is=20 necessary to preserve a digitally signed document, as well as=20 certificates, revocations lists, OCSP responses and time stamps, = even=20 if these elements are not included in the signed document itself. =20 Preservation may be achieved by periodic review of evidence. Upon=20 review, updated evidence may be obtained and stored or additional=20 cryptographic mechanisms may be applied, e.g. a new timestamp=20 obtained possibly using a stronger algorithm. =20 =20 By periodically inspecting and acting upon stored evidence, it is=20 possible to generate a cryptographically protected history for a = data item that contains no periods of time during which an algorithm was=20 thought to be weak, an authority thought to be compromised, etc.=20 =20 =20 3.2 Long-term Archive Service=20 =20 A Long-term Archive Service is to be designed to solve essential=20 parts of these problems by providing a specialized service:=20 =20 - The Long-term Archive Service is to store archived data objects=20 over a long, optionally undefined, period of time. Recovery methods, = redundant storage and disaster management and other measures have to = guarantee the availability of the data objects.=20 =20 Wallace Expires July 2004 [Page 5] =0C Long-term archive service requirements January 2004=20 - The Long-term Archive Service provides material needed to prove = the=20 existence and integrity of data objects for users as well as in=20 court. These means especially are time-stamps, periodically=20 generated during the archiving period of the data objects. = Additional=20 verification data, to verify these time-stamps after a long period = of=20 time (CRLS, OCSP responses and certificates) need also be provided. = =20 - The Long-term Archive Service provides means to preserve the value = of evidence of the archived data objects that are signed. These = means=20 are also time-stamps but with regard to possible special legal=20 requirements for the use as mechanism for the renewal of signatures. = =20 By using these means a signature application can verify that a=20 document, which contains signatures, existed before algorithms got=20 weak or certificates got invalid.=20 =20 A Long-term Archive Service is to not be designed to solve all=20 thinkable problems of long-term-verification of digital signatures. = It does not provide data necessary to verify signatures which are=20 part of the archived data object itself. This has to be done by=20 verifiers using PKI-Services like SCVP (Simple Certificate = Validation=20 Protocol) or DVCS (Data Validation and Certification Server). This=20 is done, in part, so the archive service can operate without=20 knowledge of numerous signed data formats, document formats, etc. = It=20 also does not provide any means to integrate verification data in=20 data objects and verify embedded signatures. This has to be done on = the basis of other specifications, like RFC 3029 and with regard to=20 specifications of document formats. Of course it is recommended to=20 use such specifications together with a Long-term Archive Service.=20 =20 Several application scenarios providing one or more of these basic=20 service features are to be supported, including:=20 =20 - Archive service assuring long-term Non-Repudiation =20 =20 Long-term Archive Service stores data objects like signed or=20 unsigned documents for identified and authenticated users. It=20 generates time stamps for these data objects and obtains necessary=20 verification data over a given time or until a request of deletion = by=20 this authorized user is sent.=20 =20 - Pure long-term non-repudiation Service=20 =20 Long-term Archive Service only guarantees non-repudiation of=20 existence of data. It periodically generates time stamps and = obtains=20 additional verification data for a given period of time. It stores=20 data objects (e.g. documents, but also relevant parts of documents=20 containing signatures) locally only for the purpose of non- repudiation. It is not a document-archive for users and therefore=20 does not provide retrieval of documents and no deletion of data=20 objects. Therefore it does not need any access control.=20 =20 Wallace Expires July 2004 [Page 6] =0C Long-term archive service requirements January 2004=20 =20 3.3 Instances and overall architecture=20 =20 =20 The basic functions of a Long-term Archive Service are realized by=20 several instances:=20 =20 =20 +-------------+=20 | |=20 | User |=20 | |=20 +-------------+=20 |=20 ----------- Long-term Archive Protocol=20 |=20 +-------------+=20 | |=20 | TAA |=20 | |=20 +-------------+=20 |=20 ----------- Time Stamp Protocol=20 |=20 +-------------+=20 | |=20 | TSA |=20 | |=20 +-------------+=20 =20 Users transfer the data objects that shall be archived at the = Trusted=20 Archive Authority (TAA) using their application of choice. After=20 that, the user or application can request archive packages = containing=20 the stored data objects and the associated evidence record. This is = done by using the Long-term Archive Service Protocol and the data=20 format of archive package to be specified. The TAA stores the=20 documents, and obtains necessary verification data, especially time=20 stamps consulting a Time Stamp Authority using a special Protocol,=20 especially Time Stamp Protocol (RFC 3161). TAA also uses other=20 protocols (e.g. SCVP) to get additional verification data necessary=20 to verify generated time-stamps.=20 =20 A TAA may also provide the functions of a TSA, but separation must = be=20 possible. A TAA may store the archived data objects locally or may=20 use external archive services.=20 =20 Long-term Archive Service may allow for relays using Long-term=20 Archive Protocol. The use of external archive services may be also=20 possible. But Relaying must be transparent to the client. =20 =20 Wallace Expires July 2004 [Page 7] =0C Long-term archive service requirements January 2004=20 A TAA may be a server within an enterprise network communicating = with=20 local archive servers and other applications or an external service=20 accessible via internet.=20 =20 =20 4. Long-term Archive Service functional and quality requirements=20 =20 A Long-term Archive Service MUST provide following basic functions:=20 =20 - Accept data objects or groups of data objects for preservation; = =20 - Store submitted data objects for a given period of time;=20 =20 - Generate, store and maintain evidence records (i.e. by=20 periodically obtaining timestamps) for data objects submitted for=20 preservation;=20 =20 - Collect and store additional verification data necessary to=20 verify evidence records;=20 =20 - Provide archive packages containing archived data, evidence=20 record or both;=20 =20 - Provide service according to a long-term archive policy;=20 - The archive service MUST be able to provide evidence about the policies that have been used at any time. =20 - Be able to provide archive packages even if the storage,=20 software or processing technology changes during the lifetime of an=20 archived data object;=20 =20 - Be able to provide an acknowledgement that a data object = existed=20 at a certain time, as an alternative, if user is not able to=20 interpret the evidence record;=20 =20 - Operate per an archive policy, which at least determines = quality=20 of time-stamps and conditions for there renewal and etc;=20 =20 - If data objects are not stored by the Long-term-Archive-Service = itself, there must exist mechanisms to make these data objects later available to the service if necessary in case of renewal of time-stamps. A long-term archive service must be able to work efficiently even = for=20 large amounts of archived data objects. In order to limit expenses, = costs and dependency on high performance, time-stamp services, the=20 number of necessary time stamps MUST be minimized and a time stamp=20 should include a large number of signatures and documents;=20 =20 =20 =20 =20 Wallace Expires July 2004 [Page 8] =0C Long-term archive service requirements January 2004=20 =20 Necessity to access stored archived data object SHOULD be minimized. = =20 It SHOULD only be necessary access to the archived data objects only = if the archived data objects are requested by users or if applied=20 hash algorithms become insecure. =20 =20 A Long-term Archive Service may implement additional features, such=20 as validation of data objects, if they are signed documents.=20 5. Long-term Archive Service data structure requirements=20 =20 Standardization of data structures and processing procedures for an=20 archive package will simplify the job of TAAs and enable = verification=20 by any user.=20 =20 The data structure for archive package should include the archived=20 data objects and the evidence record. Archived data objects may be=20 included as part of the archive package so that it is possible to=20 request only the evidence record.=20 =20 The data structure for the evidence record itself should have the=20 following properties:=20 =20 - It MUST be possible to include all timestamps necessary to=20 verify the existence of the archived data objects.=20 =20 - The timestamp data structure SHOULD be defined in such a way=20 that it is possible to provide evidence for many archived data=20 objects in an efficient way.=20 =20 - It SHOULD be possible to provide evidence for groups of = archived=20 data objects. For example, it should be possible to archive a=20 document file and a signature file together such that they get the=20 same evidence record.=20 =20 - Where groups of data objects are submitted, non-repudiation=20 proof MUST still be available for each archived data object=20 separately.=20 =20 - The deletion of archived data objects MUST NOT put the=20 provability of other archived data at risk.=20 =20 - It SHOULD be possible to create timestamps without the need to=20 access the archived data objects. The access to the archived data=20 SHOULD only be necessary if the security suitability of employed = hash=20 algorithm is menaced.=20 =20 - All hash algorithms applied to archived data over time SHOULD = be=20 identified in a single location to facilitate single pass=20 verification.=20 =20 - It SHOULD be possible to package all evidence along with the=20 archived data objects in a single data item or to package evidence=20 =20 Wallace Expires July 2004 [Page 9] =0C Long-term archive service requirements January 2004=20 and archived data objects in separate items.=20 =20 - It SHOULD be possible to provide evidence for encrypted = archived=20 data objects. It SHOULD be possible to integrate information for = the=20 reconstruction of the archived data objects of the unencrypted data=20 objects (key, algorithm, etc.).=20 =20 - It SHOULD be possible to integrate additional information for=20 the verification of timestamps within the evidence record or the=20 archived data object itself such as certificates and revocation=20 information, the security suitability of applied algorithms and = trust=20 anchors. =20 =20 =20 6. Long-term Archive Service Protocol requirements=20 =20 Standardization of a protocol for interactions with a Long-term=20 Archive Service is desirable. The protocol should have the = following=20 properties:=20 =20 - The protocol MUST define interactions with a Long-term Archive=20 Service including, at a minimum: submission of data or groups of=20 data for preservation, retrieval of archive packages and deletion=20 of archived data and associated evidence records. =20 - The protocol MUST provide a response indicating successful=20 submission or deletion of data. The acknowledgement of successful=20 submission SHOULD permit a submitter to verify that the correct data = was received by the service for preservation, e.g. the=20 acknowledgement could include an index, a signature or a timestamp=20 obtained for the archived data object.=20 =20 - The protocol MUST response an index to retrieve the archive=20 package. It also should be possible to retrieve archive packages by = using hash values of the archived data objects.=20 - The protocol SHOULD support some basic Metadata (Mime-Type, key = words,etc.), i.e. the client should be able to provide metadata=20 along with the archived data to facilitate future search operations=20 based on the metadata.=20 =20 - If a Long-term Archive Service does not support a client- requested long-term archive policy, the service MUST return an = error.=20 =20 - A Long-term Archive Service MUST provide an indication of the=20 long-term archive policy under which the service operates.=20 =20 - The protocol MUST prevent replay attacks. =20 - The protocol SHOULD permit encryption of data before submission = in such a way that there exists non-repudiation evidence for the=20 unencrypted data.=20 =20 Wallace Expires July 2004 [Page 10] =0C Long-term archive service requirements January 2004=20 - The protocol SHOULD provide means of associating submitted data = objects with previously submitted data objects, i.e. to facilitate=20 retrieval based on aggregation of objects over time.=20 - The protocol SHOULD provide means for specifying a point in = time=20 at which an archived data object need no longer be preserved. It=20 also should be possible to extend the archiving period.=20 =20 - The protocol SHOULD provide the submission of evidence records=20 previously generated by a different TAA.=20 - The format for the acknowledgements MUST allow the=20 identification of the archiving provider.=20 - The format for the acknowledgements MUST allow (at least from the creating archiving provider) the identification of the=20 participating client. - Responses must uniquely reference corresponding requests - It should be possible to sign requests and responses. It is=20 recommended that in particular acknowledgements are signed. - Deletion must be authenticated.=20 =20 - The archive service MUST be able to provide evidence about the policies that have been used at any time - The protocol SHOULD be as simple to use as possible.=20 =20 Means to enable accountability, access control, confidentiality of=20 communication between applications and TAA need additional=20 precautions (like SSL) that are outside the scope of these=20 requirements.=20 7. Security Considerations=20 =20 Where non-standard formats are used or proprietary processing is=20 employed, verification of signatures on or in archived data may=20 require the availability of specific applications or tools.=20 =20 Certificate revocation could retroactively invalidate previously=20 verified signatures. Measures may be implemented to support such=20 claims by an alleged signer, e.g. collection of revocation=20 information after a grace period during which compromise can be=20 reported or preservation of subsequent revocation information. =20 =20 Access control mechanisms associated with data stored by a TAA = should=20 consider the lifespan of the data object. For example, the=20 credentials of an entity that submitted data to an archive may not = be=20 available or valid when the data needs to be retrieved.=20 Wallace Expires July 2004 [Page 11] =0C Long-term archive service requirements January 2004=20 To achieve accountability, local means should be employed to ensure that all data is inserted in chronological order, e.g. by using write-once media. Similarly, methods should be deployed to ensure that all deletions are detectable. =20 =20 8. Acknowledgements=20 =20 Thanks to Peter Sylvester for sharing information from the=20 OpenEvidence project.=20 =20 =20 9. Normative References=20 =20 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision=20 3", BCP 9, RFC 2026, October 1996.=20 =20 [RFC2028] Bradner, S. and R. Hovey, "The Organizations Involved in=20 the IETF Standards Process", BCP 11, RFC 2028, October=20 1996.=20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997.=20 =20 [RFC3029] Adams, C., Sylvester, P., Zolotarev, M. and R.=20 Zuccherato, "Internet X.509 Public Key Infrastructure=20 Data Validation and Certification Server Protocols", RFC=20 3029, August 2001.=20 =20 [RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,=20 "Internet X.509 Public Key Infrastructure Time-Stamp=20 Protocol (TSP)", RFC 3161, August 2001.=20 =20 =20 Wallace Expires July 2004 [Page 12] = =0C Long-term archive service requirements January 2004=20 10. Authors' Addresses=20 =20 Carl Wallace=20 Orion Security Solutions=20 Suite 300=20 1489 Chain Bridge Road=20 McLean, VA 22101=20 E-Mail : cwallace@orionsec.com=20 =20 Ralf Brandner=20 Otto-Hahn-Str. 3 =20 D-69190 Walldorf, Germany=20 E-Mail: ralf.brandner@intercomponentware.com=20 Ulrich Pordesch=20 Fraunhofer Gesellschaft=20 Institute Secure Telecooperation=20 Dolivostrasse 15=20 D-64293 Darmstadt, Germany=20 E-Mail: ulrich.pordesch@sit.fraunhofer.de=20 Wallace Expires July 2004 [Page 13] ------_=_NextPart_000_01C3D933.398CBCB0-- Received: from netscape105.com (a64021.upc-a.chello.nl [62.163.64.21]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0371sib054186 for ; Fri, 2 Jan 2004 23:01:55 -0800 (PST) (envelope-from zuka2006@netscape.net) Message-Id: <200401030701.i0371sib054186@above.proper.com> From: Zuka To: ietf-ltans-bks@above.proper.com Reply-To: zuka2006@netscape.net Subject: MR.MUDIWA ZUKA Date: Sat, 03 Jan 2004 08:02:30 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5009bf94-5f1f-4a2f-b67a-faef2ea52bf7" This is a multi-part message in MIME format --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable DEAR SIR. HAPPY NEW YEAR .I AM A GIRL OF 25 YEARS OLD AND I AM LOOKING FOR INVESTMENT = OPPORTUNITY. I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS = INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE = NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME THROUGH = THIS EMAIL zuka2008@excite.com BEST REGARDS MS. MUDIWA ZUKA --5009bf94-5f1f-4a2f-b67a-faef2ea52bf7--