From owner-ietf-ltans Wed Mar 10 01:10:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AHSC068298; Wed, 10 Mar 2004 01:10:17 -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 i2A9AHBM068297; Wed, 10 Mar 2004 01:10:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AF5l068238 for ; Wed, 10 Mar 2004 01:10:16 -0800 (PST) (envelope-from muriel@actimage.net) Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i2A93qC22479 for ; Wed, 10 Mar 2004 10:03:52 +0100 (CET) Message-ID: <03b001c4067f$c75842c0$4406a8c0@leila> From: "Muriel Souville" To: Subject: Launch of the Security Plugtests Registration Date: Wed, 10 Mar 2004 10:12:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A3_01C40688.2621BA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 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_03A3_01C40688.2621BA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The ETSI Plugtests(tm) Service is pleased to announce the opening of the Security Plugtests registration. The event will take place from 24 till 28 May at the ETSI premises, in Sophia Antipolis (France). Deadline to register is 5th May. All details about the event are to be found at http://www.etsi.org/plugtests/security.htm Feel free to forward this email to as many people as you want in order to have a really interesting test opportunity this week. For any enquiry you may have, please write to plugtests@etsi.org. Thanks for your attention. We look forward to welcoming you at our Headquarters in May. Best regards Muriel SOUVILLE ETSI Consultant Tel: +33 (0) 3 90 23 63 63 ------=_NextPart_000_03A3_01C40688.2621BA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,

The ETSI Plugtests(tm) Service is pleased to announce the=20 opening
of the Security Plugtests registration.
The event will = take place=20 from 24 till 28 May at the ETSI premises,
in Sophia Antipolis=20 (France).
Deadline to register is 5th May.

 All details = about the=20 event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as = many people=20 as you want in order
to have a really interesting test opportunity = this=20 week.

For any enquiry you may have, please write to plugtests@etsi.org.

Thanks for your attention.
We look forward to = welcoming you=20 at our Headquarters in May.

Best regards

Muriel = SOUVILLE
ETSI=20 Consultant
Tel: +33 (0) 3 90 23 63=20 63
------=_NextPart_000_03A3_01C40688.2621BA40-- From owner-ietf-ltans Wed Mar 24 10:37:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OIb1Me078268; Wed, 24 Mar 2004 10:37:01 -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 i2OIb14H078267; Wed, 24 Mar 2004 10:37:01 -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 i2OIb0Du078261 for ; Wed, 24 Mar 2004 10:37:00 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2OIasIu029568 for ; Wed, 24 Mar 2004 13:37:03 -0500 From: "Santosh Chokhani" To: Subject: Alternatives for Long Term Archiving Date: Wed, 24 Mar 2004 13:36:54 -0500 Message-ID: <000601c411cf$0045bf90$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C411A5.176FB790" 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 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_0007_01C411A5.176FB790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of the ideas that came out of Seoul meeting (thanks to Larry = Masinter) is to use a key-less approach to trusted archive. The client who has = vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n = must be greater than 1, less than or equal to m, and should be selected based on = the desired degree of protection against collusion. =20 If this scheme is used, we may not need any cryptographic operations at = the TAA. =20 Under this scheme, the LTANS WG would need to still define various = protocol for submission, deletion, and retrieval. if the idea is acceptable to = the group, it could be the preferred or one of the approaches to perform archiving. =20 As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. =20 One advantage of the approach is that any document split is not = sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as = SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. =20 To further illustrate one usage of the approach, a client with the need = to provide long-term, non-repudiation of a transaction, could obtain = current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. =20 When there is a need to retrieve the evidence, n splits could be = retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. =20 The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of = the TAAs. =20 Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_0007_01C411A5.176FB790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
One of = the ideas=20 that came out of Seoul meeting (thanks to Larry Masinter) is to use a = key-less=20 approach to trusted archive.  The client who has vested interest in = the=20 secure storage of archived data, can use Shamir's n of m scheme to = submit the=20 archived data to m archive facilities.  m must be greater than 1 = and should=20 be selected based on availability needs. n must be greater than 1, less = than or=20 equal to m, and should be selected based on the desired degree of = protection=20 against collusion.
 
If = this scheme is=20 used, we may not need any cryptographic operations at the=20 TAA.
 
Under = this scheme,=20 the LTANS WG would need to still define various protocol for submission, = deletion, and retrieval.  if the idea is acceptable to the group, = it could=20 be the preferred or one of the approaches to perform=20 archiving.
 
As the = current LTANS=20 documents in the various stages state or imply,=20 the trusted archive can continue to be used to submit any = class of=20 data.
 
One = advantage of the=20 approach is that any document split is not sensitive even = if the=20 original document is sensitive.  However, if the document requires=20 confidentiality, assuming an adversary could be monitoring the = channels to=20 collect all the splits, the submission and retrieval of the split should = be=20 provided transmission security using techniques such as SSL or session=20 encryption.  This still is lot easier than needing to provide = long-term=20 encryption for stored data.
 
To = further=20 illustrate one usage of the approach, a client with the need to = provide=20 long-term, non-repudiation of a transaction, could obtain current = time=20 stamp, all the trust anchor, certificates, revocation information = relevant to=20 signatures and time stamp, and package them using TBD record format and = create m=20 splits.  These m split could be sent to m TAAs using TLS.  = Each TLS=20 could provide a pointer to its split.
 
When = there is a need=20 to retrieve the evidence, n splits could be retrieved from n TAAs that = are=20 available and can be combined to validate the signatures on the = transaction as=20 well as the time stamp.
 
The = approach also=20 offers some redundancy in case some TAAs are not available, data is = corrupted,=20 or the challenger does not trust some of the TAAs.
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
------=_NextPart_000_0007_01C411A5.176FB790-- From owner-ietf-ltans Wed Mar 24 14:21:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OML8qO095722; Wed, 24 Mar 2004 14:21:08 -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 i2OML8Rr095721; Wed, 24 Mar 2004 14:21:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OML78X095713 for ; Wed, 24 Mar 2004 14:21:08 -0800 (PST) (envelope-from LMM@acm.org) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i2OML5SP011829; Wed, 24 Mar 2004 14:21:06 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i2OML3kq025660; Wed, 24 Mar 2004 14:21:03 -0800 (PST) Received: from MasinterT40 (c-67-195.corp.adobe.com [153.32.67.195]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HV300C16Q322M@mailsj-v1.corp.adobe.com>; Wed, 24 Mar 2004 14:21:02 -0800 (PST) Date: Wed, 24 Mar 2004 14:21:03 -0800 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving In-reply-to: <000601c411cf$0045bf90$9a00a8c0@hq.orionsec.com> To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Message-id: <0HV300C17Q322M@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: multipart/alternative; boundary="Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)" Thread-index: AcQR0NsZsZKEdLl/TTm+iWmOg4Z4nwABRxPA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT There seems to be quite a bit of research in this area. For example, see http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are still open issues about how to manage trust over the long term, and even identity. Larry --Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
There seems to be quite a bit of research in this area. For example, see  http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are still open issues about how to manage trust over the long term, and even identity.
 
Larry
 
--Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)-- From owner-ietf-ltans Thu Mar 25 13:10:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLA4Hj069730; Thu, 25 Mar 2004 13:10:04 -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 i2PLA4pK069729; Thu, 25 Mar 2004 13:10:04 -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 i2PLA4iI069723 for ; Thu, 25 Mar 2004 13:10:04 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2PLA8Iu032276 for ; Thu, 25 Mar 2004 16:10:08 -0500 From: "Santosh Chokhani" To: Subject: FW: April 12-14: 3rd Annual PKI R&D Workshop Date: Thu, 25 Mar 2004 16:10:08 -0500 Message-ID: <010d01c412ad$8d7ce030$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2PLA4iI069724 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI. ------------- The 3rd Annual PKI R&D Workshop is almost here: April 12-14 2004 at NIST in Gaithersburg, MD. Registrations should be in by Monday March 29. The program features a broad variety of perspectives, results and new ideas on the use of Public Key technology for security decision making, not just traditional "PKI". There are talks and panel sessions on the dynamic delegation of rights, application-specific PKI designs, document signatures, certificate path discovery, experience papers and panels on where to go from here. Speakers include Peter Gutmann, Carlisle Adams, Stefan Brands, Ken Klingenstein, John Linn, Tim Polk, Von Welch and many other experts. The intimate workshop atmosphere provides ample opportunities to interact with others working on the issues you're facing, including Work-In-Progress and Birds-of-a-Feather sessions. 802.11b Wireless access points will be available for SSH, IPSEC, HTTP, DNS, FTP, POP, IMAP, and SMTP connectivity. At only $105 for registration, it's a bargain. More information at http://middleware.internet2.edu/pki04/ Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 Preliminary Program - Subject to change Monday, April 12 12:00 - 12:15 Opening Remarks Program Committee Susan Zevin Director, Information Technology Laboratory, NIST 12:15 - 1:15 KEYNOTE ADDRESS Non-Intrusive Cross-Domain Identity Management Stefan Brands Credentica 2:00 - 3:30 Role Sharing in Password-Enabled PKI Xunhua Wang James Madison University Greenpass: Decentralized, PKI-based Authorization for Wireless LANs Nicholas C. Goffee Dartmouth College X.509 Proxy Certificates for Dynamic Delegation Von Welch National Center for Supercomputing Applications, University of Illinois 4:00 - 5:30 Panel: Controlled and Dynamic Delegation of Rights Moderator: Frank Siebenlist Argonne National Laboratory 6:15 - 8:00 Social Gathering and Workshop Dinner Gaithersburg Holiday Inn 8:00 - 9:00 Work in Progress Session Gaithersburg Holiday Inn Contact Krishna Sankar if you would like to present some Work in Progress Tuesday, April 13 9:00 - 10:00 KEYNOTE ADDRESS Simple, Straightforward, Functional PKI Peter Gutmann University of Auckland 10:00 - 10:30 Experiences of establishing trust in a distributed system operated by mutually distrusting parties David Chadwick University of Salford 11:00 - 12:00 Panel: An update on Phase Three of the PKI Interop Project with EDUCAUSE Moderator: Peter Alterman National Institutes of Health Deb Blanchard Digital Signature Trust Russ Weiser Betrusted 12:00 - 12:30 Trusted Archiving Santosh Chokhani Orion Security Solutions 12:30 - 2:00: Lunch - NIST Cafeteria 2:00 - 3:00 Panel: Document Signatures Moderator: Randy Sabett, Cooley Godward LLP & Tim Polk NIST 3:00 - 3:30 PKI: Ten Years Later Carlisle Adams University of Ottawa 4:00 - 4:30 An Examination of Asserted PKI Issues and Proposed Alternatives John Linn RSA Laboratories 4:30 - 5:30 Panel: Which PKI Approach for Which Application Domain? Moderator: Peter Alterman National Institutes of Health Carl Ellison Microsoft Russ Weiser Betrusted 5:30 - 8:00: Dinner (on your own) 8:00 - 9:00 Birds of a Feather sessions - sign up at Registration Wednesday, April 14 9:00 - 10:00 KEYNOTE ADDRESS The Middleware Connection Ken Klingenstein University of Colorado; Internet2 10:00 - 10:30 Private Revocation Test using Oblivious Membership Evaluation Protocol Hiroaki Kikuchi Tokai University 11:00 - 11:30 "Dynamic Bridge" Concept Paper Ken Stillson Mitretek Systems 11:30 - 12:30 Panel: Approaches to Certificate Path Discovery Moderator: Peter Hesse Gemini Security Solutions Steve Hanna Sun Microsystems Matt Cooper Orion Security Solutions Ken Stillson Mitretek Systems 12:30 - 2:00: Lunch - NIST Cafeteria 2:00 - 2:30 Johnson & Johnson Use of Public Key Technology Rich Guida Johnson & Johnson 2:30 - 3:00 Identifying and Overcoming Obstacles to PKI Deployment and Usage Jean Pawluk Inovant 3:30 - 4:30 Panel: The PKI Action Plan: Will it make a difference? Moderator: Steve Hanna Sun Microsystems Lieutenant Commander Thomas Winnenberg U.S.N., DISA Jean Pawluk Inovant Tim Polk NIST John Linn RSA Laboratories Sean Smith Dartmouth College 4:30 - 5:00 Wrapup Session From owner-ietf-ltans Thu Mar 25 13:08:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PL8E1R069448; Thu, 25 Mar 2004 13:08: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 i2PL8EAX069447; Thu, 25 Mar 2004 13:08:14 -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 i2PL8CpG069439 for ; Thu, 25 Mar 2004 13:08:13 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i2PL8GN07692; Thu, 25 Mar 2004 22:08:16 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 25 Mar 2004 22:08:16 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i2PL8FB11242; Thu, 25 Mar 2004 22:08:15 +0100 (MET) Date: Thu, 25 Mar 2004 22:08:15 +0100 (MET) From: Peter Sylvester Message-Id: <200403252108.i2PL8FB11242@chandon.edelweb.fr> To: chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Cc: ietf-ltans@imc.org Content-Type: X-sun-attachment Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 13 > One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) > is to use a key-less approach to trusted archive. The client who has vested > interest in the secure storage of archived data, can use Shamir's n of m > scheme to submit the archived data to m archive facilities. m must be > greater than 1 and should be selected based on availability needs. n must be > greater than 1, less than or equal to m, and should be selected based on the > desired degree of protection against collusion. > Addressing the problem of confidentiality and redundancy need in this way had been proposed as one of the work iteme of a research project APRICOT concerning archiving. It seems useful to me to elaborate how these aproach can be implemented in practice. ---------- X-Sun-Data-Type: html X-Sun-Encoding-Info: quoted-printable X-Sun-Content-Length: 5575 X-Sun-Content-Lines: 129 Message
One of = the ideas=20 that came out of Seoul meeting (thanks to Larry Masinter) is to use a = key-less=20 approach to trusted archive.  The client who has vested interest in = the=20 secure storage of archived data, can use Shamir's n of m scheme to = submit the=20 archived data to m archive facilities.  m must be greater than 1 = and should=20 be selected based on availability needs. n must be greater than 1, less = than or=20 equal to m, and should be selected based on the desired degree of = protection=20 against collusion.
 
If = this scheme is=20 used, we may not need any cryptographic operations at the=20 TAA.
 
Under = this scheme,=20 the LTANS WG would need to still define various protocol for submission, = deletion, and retrieval.  if the idea is acceptable to the group, = it could=20 be the preferred or one of the approaches to perform=20 archiving.
 
As the = current LTANS=20 documents in the various stages state or imply,=20 the trusted archive can continue to be used to submit any = class of=20 data.
 
One = advantage of the=20 approach is that any document split is not sensitive even = if the=20 original document is sensitive.  However, if the document requires=20 confidentiality, assuming an adversary could be monitoring the = channels to=20 collect all the splits, the submission and retrieval of the split should = be=20 provided transmission security using techniques such as SSL or session=20 encryption.  This still is lot easier than needing to provide = long-term=20 encryption for stored data.
 
To = further=20 illustrate one usage of the approach, a client with the need to = provide=20 long-term, non-repudiation of a transaction, could obtain current = time=20 stamp, all the trust anchor, certificates, revocation information = relevant to=20 signatures and time stamp, and package them using TBD record format and = create m=20 splits.  These m split could be sent to m TAAs using TLS.  = Each TLS=20 could provide a pointer to its split.
 
When = there is a need=20 to retrieve the evidence, n splits could be retrieved from n TAAs that = are=20 available and can be combined to validate the signatures on the = transaction as=20 well as the time stamp.
 
The = approach also=20 offers some redundancy in case some TAAs are not available, data is = corrupted,=20 or the challenger does not trust some of the TAAs.
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
From owner-ietf-ltans Thu Mar 25 13:35:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLZDCr071061; Thu, 25 Mar 2004 13:35:13 -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 i2PLZDvu071060; Thu, 25 Mar 2004 13:35:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLZCvh071054 for ; Thu, 25 Mar 2004 13:35:12 -0800 (PST) (envelope-from kent@raven.songbird.com) Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2PLZHd24700; Thu, 25 Mar 2004 13:35:17 -0800 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i2PLZDJf012518; Thu, 25 Mar 2004 13:35:13 -0800 Date: Thu, 25 Mar 2004 13:35:13 -0800 From: kent crispin To: Peter Sylvester Cc: chokhani@orionsec.com, ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Message-ID: <20040325213513.GB8516@raven.songbird.com> Mail-Followup-To: Peter Sylvester , chokhani@orionsec.com, ietf-ltans@imc.org References: <200403252108.i2PL8FB11242@chandon.edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403252108.i2PL8FB11242@chandon.edelweb.fr> User-Agent: Mutt/1.4.1i Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 25, 2004 at 10:08:15PM +0100, Peter Sylvester wrote: Hi Peter -- your mail client is sending strange attachments: [-- application/x-X-sun-attachment is unsupported (use 'v' to view this part) --] -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.com From owner-ietf-ltans Fri Mar 26 01:35:18 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q9ZIxg085860; Fri, 26 Mar 2004 01:35:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q9ZIuw085859; Fri, 26 Mar 2004 01:35:18 -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 i2Q9ZHWl085746 for ; Fri, 26 Mar 2004 01:35:17 -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 KAA01238; Fri, 26 Mar 2004 10:34:40 +0100 (MET) Message-ID: <4063F99F.9050505@sit.fraunhofer.de> Date: Fri, 26 Mar 2004 10:36:31 +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: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving References: <000601c411cf$0045bf90$9a00a8c0@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: I think that a keyless approach could be an ideal approach, however, I don't see Shamir's scheme as solving all of our problems. First, the complexity of the system would increase. This starts with the distribution of the original document, and then the possible redistribution of the document as TAAs are removed or added. Such functionality would add to the complexity of the (server-server) protocols. Furthermore, stricter access control must be ensured, such that an attacker can't simply retrieve n parts of the document from the TAAs. Using the current encryption scheme, an attacker would first have to bypass the access control of the (single) TAA, and then have to break the encryption of the document. Thus, the security focus of the systems are different, one is strictly based upon access control, the other on access control and encryption. One could even argue that no access control is needed for the evidence records, since they only contain a hash of the document and reveal nothing about its content. The cost to archive a document would increase, likely linearly based on the size of m. How many clients want to pay m times more for a service? (unless the alternatives are shown to be insufficient) Furthermore, each TAA would probably have to be, at least in Germany, accredited, since it is attesting for the document insertion time (and integrity). Accreditation is not needed by the TAAs in the ERS solution, only accredited TSA(s) are needed. I believe that this distribution approach could be useful, for at least particular cases, but am unsure if it is suitable today for a generic archive service that needs to be efficient and cost effective for large volumes of documents. Thus, I still think (based on what has been presented so far) that ERS should be continued, in order to get a needed, standard, viable solution in the near future, and the distribution approach could be further investigated, refined and then in the future be evaluated whether it is added to the LTANS approach as the new recommended method, or as an optional method recommended for specific use cases. Brian From owner-ietf-ltans Fri Mar 26 05:54:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QDs28u013852; Fri, 26 Mar 2004 05:54: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 i2QDs2Fs013851; Fri, 26 Mar 2004 05:54:02 -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 i2QDs1Np013845 for ; Fri, 26 Mar 2004 05:54:02 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2QDs1Iu018936 for ; Fri, 26 Mar 2004 08:54:01 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Fri, 26 Mar 2004 08:54:00 -0500 Message-ID: <001601c41339$cae81ed0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4063F99F.9050505@sit.fraunhofer.de> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QDs2Np013846 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: See responses in-line in []. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Friday, March 26, 2004 4:37 AM To: Santosh Chokhani Cc: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving I think that a keyless approach could be an ideal approach, however, I don't see Shamir's scheme as solving all of our problems. First, the complexity of the system would increase. [I think the complexity of the client will increase. But, the TAAs will become very, very simply. In my judgment the overall system complexity will reduce since there is no encryption, signature, timestamp, time refresh etc., but a simply n of m split only one time] This starts with the distribution of the original document, and then the possible redistribution of the document as TAAs are removed or added. Such functionality would add to the complexity of the (server-server) protocols. [Actually, when TAAs are removed or added, n of m scheme may be better suited to handle this. I have not fully grasped Shamir's technique, but it lets you add new shares if some properties hold. Removal on the other hand can be handled in two ways. n of m gives you some margin for removing some TAs (may be up to m-n). Alternatively, since there are no keys involved it will be easier to move to a newly created TAA. In the current proposal, the whole stuff has to be with another TAA] Furthermore, stricter access control must be ensured, such that an attacker can't simply retrieve n parts of the document from the TAAs. Using the current encryption scheme, an attacker would first have to bypass the access control of the (single) TAA, and then have to break the encryption of the document. Thus, the security focus of the systems are different, one is strictly based upon access control, the other on access control and encryption. One could even argue that no access control is needed for the evidence records, since they only contain a hash of the document and reveal nothing about its content. [n of m does not prevent you from encrypting the document. I just wanted to point out that confidentiality against TAAs and against an eavesdropper can be easily achieved. If you think all TAAs' access controls can be bypassed (not just one TAA's), which I doubt, you can encrypt the document a la current proposal. The cost to archive a document would increase, likely linearly based on the size of m. How many clients want to pay m times more for a service? (unless the alternatives are shown to be insufficient) Furthermore, each TAA would probably have to be, at least in Germany, accredited, since it is attesting for the document insertion time (and integrity). Accreditation is not needed by the TAAs in the ERS solution, only accredited TSA(s) are needed. [Cost may be a concern. But, hopefully even 2 of 2 might suffice. Also, since TAAs are simple, cost per archival should offset some of the costs. This is one of the reasons, I do not want to standardize on current proposal alone or n of m alone, but see if there is a way to accommodate both and have most aspects of transactions and storage record common.] I believe that this distribution approach could be useful, for at least particular cases, but am unsure if it is suitable today for a generic archive service that needs to be efficient and cost effective for large volumes of documents. Thus, I still think (based on what has been presented so far) that ERS should be continued, in order to get a needed, standard, viable solution in the near future, and the distribution approach could be further investigated, refined and then in the future be evaluated whether it is added to the LTANS approach as the new recommended method, or as an optional method recommended for specific use cases. [I would like to read the paper Larry pointed to and then make a judgment if ERS or both ERS and n of m should be considered. I am not proposing that ERS be not part of the approach.]. Brian From owner-ietf-ltans Sat Mar 27 04:35:01 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RCZ1wK086037; Sat, 27 Mar 2004 04:35:01 -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 i2RCZ1f6086036; Sat, 27 Mar 2004 04:35:01 -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 i2RCYxwo086024 for ; Sat, 27 Mar 2004 04:35:00 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i2RCYtN01951; Sat, 27 Mar 2004 13:34:55 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 27 Mar 2004 13:34:55 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i2RCYrM17153; Sat, 27 Mar 2004 13:34:53 +0100 (MET) Date: Sat, 27 Mar 2004 13:34:53 +0100 (MET) From: Peter Sylvester Message-Id: <200403271234.i2RCYrM17153@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, kent@songbird.com Subject: Re: Alternatives for Long Term Archiving Cc: chokhani@orionsec.com, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry for that strange attachment. It doesn't contain anything important. From owner-ietf-ltans Mon Mar 29 06:08:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TE8PNN042222; Mon, 29 Mar 2004 06:08:25 -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 i2TE8PnX042221; Mon, 29 Mar 2004 06:08:25 -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 i2TE8ORv042214 for ; Mon, 29 Mar 2004 06:08:25 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2TE8QBv006098 for ; Mon, 29 Mar 2004 09:08:26 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Mon, 29 Mar 2004 09:08:26 -0500 Message-ID: <000b01c41597$4ded5160$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C4156D.65174960" 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: <0HV300C17Q322M@mailsj-v1.corp.adobe.com> 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_000C_01C4156D.65174960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Larry: =20 I have reviewed this paper. Here are some of my observations: =20 . The paper is oriented towards confidentiality . Paper deals with multiple archive servers and what do do if = some are decommissioned or corrupted and others need to be commissioned. We currently do not address the need for multiple servers and we do not = handle decommissioning and commissioning. While the work done to date in LTANS does not address this as a requirement or solution, I think having n of = m and then redistributing shares to create n' of m' should be part of our standard. . The paper deals with integrity of share broadcast that Micali, Feldman etc have provided. This should not be of concern to us since we = can use TLS for secrecy and integrity of current data. My concern largely = here is that of patent . Speaking of patents, I hope the redistribution scheme by = Jajodia or this work are not under patent. =20 I also did not see any outstanding issues with us going forward with = many of the features of n of m. I would suggest that we move out with this = work. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter Sent: Wednesday, March 24, 2004 5:21 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving There seems to be quite a bit of research in this area. For example, see http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are = still open issues about how to manage trust over the long term, and even = identity. =20 Larry =20 ------=_NextPart_000_000C_01C4156D.65174960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Larry:
 
I have=20 reviewed this paper.  Here are some of my = observations:
 

·         The=20 paper is=20 oriented towards confidentiality

·        =20 Paper deals with multiple archive servers and what do do if some are = decommissioned or=20 corrupted and  others need to = be=20 commissioned.  We currently do not address the need for multiple = servers=20 and we do not handle decommissioning and commissioning.  While the = work=20 done to date in LTANS does not address this as a requirement or = solution, I=20 think having n of m and then=20 redistributing shares to create n' of m' should be part of our=20 standard.

·         The paper=20 deals with integrity of share = broadcast that=20 Micali, Feldman etc have provided.  This=20 should not be of = concern to us=20 since we can use TLS for secrecy and integrity of current data.  My concern largely = here is that=20 of patent

·         Speaking of = patents, I hope the=20 redistribution scheme by Jajodia or this work are not under=20 patent.

=
 
I also=20 did not see any outstanding issues with us going forward with many of = the=20 features of n of m.  I would suggest that we move out with this=20 work.
-----Original=20 Message-----
From: owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry=20 Masinter
Sent: Wednesday, March 24, 2004 5:21 = PM
To:=20 'Santosh Chokhani'
Cc: ietf-ltans@imc.org
Subject: = RE:=20 Alternatives for Long Term Archiving

There seems to be quite a bit of research in = this area.=20 For example, see  http://www.pdl= .cmu.edu/PDL-FTP/PASIS/SISW2002.pdf.=20 I think there are still open issues about how to manage trust over the = long=20 term, and even identity.
 
Larry
 
------=_NextPart_000_000C_01C4156D.65174960-- From owner-ietf-ltans Mon Mar 29 12:18:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TKIX8o070530; Mon, 29 Mar 2004 12:18:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TKIXUb070529; Mon, 29 Mar 2004 12:18:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TKIXrA070503 for ; Mon, 29 Mar 2004 12:18:33 -0800 (PST) (envelope-from LMM@acm.org) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i2TKIUSP025427 for ; Mon, 29 Mar 2004 12:18:30 -0800 (PST) Received: from calsj-dev (mailsj [153.32.1.239]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i2TKIS3k010027 for ; Mon, 29 Mar 2004 12:18:28 -0800 (PST) Received: from MasinterT40 ([130.248.178.75]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVC00JTWTQRQL@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Mon, 29 Mar 2004 12:18:27 -0800 (PST) Date: Mon, 29 Mar 2004 12:18:25 -0800 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving In-reply-to: <001601c41339$cae81ed0$9a00a8c0@hq.orionsec.com> To: ietf-ltans@imc.org Message-id: <0HVC00JTXTQRQL@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcQTOzvF7wy1hsuLR0++9tiEB6hZ8gA78SPw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think my main point is that the standard for the network protocol for accessing and interacting with a long term archive and notary (distributed) service should not be tied to the mechanism that the service uses for insuring long term archives and non-repudiation. The current requirements document seems to be too tightly tied to the architecture of the underlying repository and the nature of the mechanisms by which it supplies services. Personally, I think that we should look for "long term archives" solutions that do not rely on algorithmic complexity and one-way functions as the mechanism for insuring privacy, integrity, etc. Larry From owner-ietf-ltans Wed Mar 31 03:39:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VBdwBg087044; Wed, 31 Mar 2004 03:39:58 -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 i2VBdwwb087043; Wed, 31 Mar 2004 03:39:58 -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 i2VBdutL087033 for ; Wed, 31 Mar 2004 03:39:57 -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 NAA20812; Wed, 31 Mar 2004 13:39:23 +0200 (MET DST) Message-ID: <406AAE4A.8060800@sit.fraunhofer.de> Date: Wed, 31 Mar 2004 13:40:58 +0200 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: Larry Masinter CC: ietf-ltans@imc.org, chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving References: <0HVC00JTXTQRQL@mailsj-v1.corp.adobe.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: Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian From owner-ietf-ltans Wed Mar 31 08:30:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGUDm9010407; Wed, 31 Mar 2004 08:30:13 -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 i2VGUDbq010406; Wed, 31 Mar 2004 08:30:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from prometheus.terms.cz (prometheus.terms.cz [81.90.160.70]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGUBmB010390 for ; Wed, 31 Mar 2004 08:30:12 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 ([81.90.165.93]) by prometheus.terms.cz (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VGTpDe032396 for ; Wed, 31 Mar 2004 18:30:03 +0200 From: To: Subject: Our objections to draft ERS Date: Wed, 31 Mar 2004 18:29:50 +0200 Message-ID: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VGUCmB010400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From my point of view the complex impression of this draft is very good. I was really pleased to see that this is already the proposal standard. I could not cope with this sentence: "A time-stamp is requested only for the root hash of the hash-tree" for a long time. But after some time, I consider it to be a good idea. If I think it over, the publishing of the root hash-tree in newspapers every week is interesting, but the "classical" time stamp acc. to RFC-3161 can easily temporarily replace it if containing the week hash. 1. Objections - I do not understand, how documents with long-term signatures will be archived (RFC-3126). When archiving long-term signed document to the TAA, the renew of particular digital signatures acc. to RFC-3126 will be finished and the whole structure will be stored as data (as Archived data object)? And after this, it will be renewed as the Archive Time Stamp Chain? I would like this solution! - Or only digital signatures will enter the Archive Time-stamp calculation as it is in RFC-3126? I would invite some examples, which will make clear the meaning (for example in appendix). - Evidence record: this structure does not contain the identification data of the archived document. How could you find such document in the archive? - Archive Time-stamp, 3.1 Syntax: If I understand well: if the reducedHashtree item misses, there is the time stamp from the document instead of from the root-hash tree. If it is true, it should be described here. 2. Little objections - "Archive Time-Stamp" collides with the same expression with different meaning in the RFC-3126. I would recommend to adjust the name slightly. - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal the ..." Change to "In the case of simple Time-Stamp Renewal the ..." - chap. 1.2, paragraph 6: "Time-Stamp renewal is not sufficient ..." Change to "The simple Time-Stamp renewal is not sufficient ..." - chap. 1.4, paragraph 2: "A multitude of data objects.." change to "A multitude of archived data objects.." - chap. 4.2 from paragraph: " 4. Concatenate each h(i) with ha(i) and generate hash values h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: h(i_a)Æ = H (h(i_a)+ ha(i)) h(i_b)Æ = H (h(i_b)+ ha(i)) etc" There is the non-ASCII character "Æ", which various readers could view in a different way. I would recommend to change it for some other ascii character (e.g. for " ' "). Libor & Marta From owner-ietf-ltans Wed Mar 31 11:28:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJS5hM025994; Wed, 31 Mar 2004 11:28: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 i2VJS5DM025993; Wed, 31 Mar 2004 11:28:05 -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 i2VJS44Y025982 for ; Wed, 31 Mar 2004 11:28:05 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 23124 invoked from network); 31 Mar 2004 19:27:58 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 31 Mar 2004 19:27:58 -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 22984-03 for ; Wed, 31 Mar 2004 21:27:58 +0200 (CEST) Received: (qmail 23119 invoked from network); 31 Mar 2004 19:27:58 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 31 Mar 2004 19:27:58 -0000 From: "A. Jerman Blazic" To: Subject: RE: Our objections to draft ERS Date: Wed, 31 Mar 2004 21:27:58 +0200 Message-ID: <000201c41756$4605d470$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> X-Virus-Scanned: by amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VJS54Y025988 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor, See comments inline > >From my point of view the complex impression of this draft is very > >good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is > requested only for the root hash of the hash-tree" for a long > time. But after some time, I consider it to be a good idea. > If I think it over, the publishing of the root hash-tree in > newspapers every week is interesting, but the "classical" > time stamp acc. to RFC-3161 can easily temporarily replace > it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term > signatures will be archived (RFC-3126). When archiving > long-term signed document to the TAA, the renew of particular > digital signatures acc. to RFC-3126 will be finished and the > whole structure will be stored as data (as Archived data > object)? And after this, it will be renewed as the Archive > Time Stamp Chain? I would like this solution! I do not really understand your point but as far as I know LTANS or TAA is not suppose to deal with digital signatures. It's meant to conserve electronic records only, which means mainly integrity and time reference. Not even validation of signatures is under concern. I personally do not see such scenario evolving but i think complementary procedures will take place to handle digital signatures and their validity over time. > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some > examples, which will make clear the meaning (for example in > appendix). Again, TAA is not suppose to deal with signatures. And also, digital signatures are not timestamping objects alone. Whole document must get stamped to achieve proper archiving. > - Evidence record: this structure does not contain the > identification data of the archived document. How could you > find such document in the archive? This is a major problem and is addressed to management of archived records (and not really LTANS). You might consider OAIS or relevant standards to do the management. I have proposed to have metadata standard for archiving attributes, which would include also other security attributes and their refreshment. Actually the step we took in the designing phase of archival solutions deal with collecting archival, security and management attributes. Whether this is standardized and not is another issue. Regards Aleksej > - Archive Time-stamp, 3.1 Syntax: If I understand well: if > the reducedHashtree item misses, there is the time stamp from > the document instead of from the root-hash tree. If it is > true, it should be > described here. > > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with > different meaning in the RFC-3126. I would recommend to > adjust the name slightly. > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal > the ..." Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not > sufficient ..." Change to "The simple Time-Stamp renewal is > not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." > change to "A multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Æ = H (h(i_a)+ ha(i)) > h(i_b)Æ = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Æ", which various readers > could view in a different way. I would recommend to change it > for some other ascii character (e.g. for " ' "). > > > Libor & Marta > > > > From owner-ietf-ltans Wed Mar 31 11:52:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJqguG028553; Wed, 31 Mar 2004 11:52:42 -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 i2VJqg4R028552; Wed, 31 Mar 2004 11:52:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJqgQh028545 for ; Wed, 31 Mar 2004 11:52:42 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id i2VJqZ326955 for ; Wed, 31 Mar 2004 14:52:36 -0500 (EST) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2004033114523000346 for ; Wed, 31 Mar 2004 14:52:31 -0500 Received: from wchokhani3 ([156.80.234.143]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HVGHVJ00.DYA for ; Wed, 31 Mar 2004 14:52:31 -0500 From: "Santosh Chokhani" To: Subject: RE: Our objections to draft ERS Date: Wed, 31 Mar 2004 14:52:31 -0500 Message-ID: <00d001c41759$b3f25d70$8fea509c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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 In-Reply-To: <000201c41756$4605d470$1b018ac1@arthur> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VJqgQh028547 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej: For the most part, I agree with you. Two points: 1. While TAA does not care about digital signatures, if the submitted archive document is signed and/or time stamped and all applicable certificates, roots, and revocation information are included, the TAA data can be retrieved and used as long term non-repudiation evidence. 2. The TAA will have to provide some hints when a document is submitted in order to ease the burden of retrieval (i.e., finding a needle in a haystack). -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Wednesday, March 31, 2004 2:28 PM To: ietf-ltans@imc.org Subject: RE: Our objections to draft ERS Libor, See comments inline > >From my point of view the complex impression of this draft is very > >good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is > requested only for the root hash of the hash-tree" for a long > time. But after some time, I consider it to be a good idea. > If I think it over, the publishing of the root hash-tree in > newspapers every week is interesting, but the "classical" > time stamp acc. to RFC-3161 can easily temporarily replace > it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term > signatures will be archived (RFC-3126). When archiving > long-term signed document to the TAA, the renew of particular > digital signatures acc. to RFC-3126 will be finished and the > whole structure will be stored as data (as Archived data > object)? And after this, it will be renewed as the Archive > Time Stamp Chain? I would like this solution! I do not really understand your point but as far as I know LTANS or TAA is not suppose to deal with digital signatures. It's meant to conserve electronic records only, which means mainly integrity and time reference. Not even validation of signatures is under concern. I personally do not see such scenario evolving but i think complementary procedures will take place to handle digital signatures and their validity over time. > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some > examples, which will make clear the meaning (for example in > appendix). Again, TAA is not suppose to deal with signatures. And also, digital signatures are not timestamping objects alone. Whole document must get stamped to achieve proper archiving. > - Evidence record: this structure does not contain the > identification data of the archived document. How could you > find such document in the archive? This is a major problem and is addressed to management of archived records (and not really LTANS). You might consider OAIS or relevant standards to do the management. I have proposed to have metadata standard for archiving attributes, which would include also other security attributes and their refreshment. Actually the step we took in the designing phase of archival solutions deal with collecting archival, security and management attributes. Whether this is standardized and not is another issue. Regards Aleksej > - Archive Time-stamp, 3.1 Syntax: If I understand well: if > the reducedHashtree item misses, there is the time stamp from > the document instead of from the root-hash tree. If it is > true, it should be > described here. > > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with > different meaning in the RFC-3126. I would recommend to > adjust the name slightly. > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal > the ..." Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not > sufficient ..." Change to "The simple Time-Stamp renewal is > not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." > change to "A multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Æ = H (h(i_a)+ ha(i)) > h(i_b)Æ = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Æ", which various readers > could view in a different way. I would recommend to change it > for some other ascii character (e.g. for " ' "). > > > Libor & Marta > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJqguG028553; Wed, 31 Mar 2004 11:52:42 -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 i2VJqg4R028552; Wed, 31 Mar 2004 11:52:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJqgQh028545 for ; Wed, 31 Mar 2004 11:52:42 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan1.bah.com (mclean-vscan1.bah.com [156.80.3.61]) by mclean-vscan1.bah.com (8.11.0/8.11.0) with SMTP id i2VJqZ326955 for ; Wed, 31 Mar 2004 14:52:36 -0500 (EST) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan1.bah.com (NAVGW 2.5.2.12) with SMTP id M2004033114523000346 for ; Wed, 31 Mar 2004 14:52:31 -0500 Received: from wchokhani3 ([156.80.234.143]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HVGHVJ00.DYA for ; Wed, 31 Mar 2004 14:52:31 -0500 From: "Santosh Chokhani" To: Subject: RE: Our objections to draft ERS Date: Wed, 31 Mar 2004 14:52:31 -0500 Message-ID: <00d001c41759$b3f25d70$8fea509c@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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 In-Reply-To: <000201c41756$4605d470$1b018ac1@arthur> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VJqgQh028547 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej: For the most part, I agree with you. Two points: 1. While TAA does not care about digital signatures, if the submitted archive document is signed and/or time stamped and all applicable certificates, roots, and revocation information are included, the TAA data can be retrieved and used as long term non-repudiation evidence. 2. The TAA will have to provide some hints when a document is submitted in order to ease the burden of retrieval (i.e., finding a needle in a haystack). -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Wednesday, March 31, 2004 2:28 PM To: ietf-ltans@imc.org Subject: RE: Our objections to draft ERS Libor, See comments inline > >From my point of view the complex impression of this draft is very > >good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is > requested only for the root hash of the hash-tree" for a long > time. But after some time, I consider it to be a good idea. > If I think it over, the publishing of the root hash-tree in > newspapers every week is interesting, but the "classical" > time stamp acc. to RFC-3161 can easily temporarily replace > it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term > signatures will be archived (RFC-3126). When archiving > long-term signed document to the TAA, the renew of particular > digital signatures acc. to RFC-3126 will be finished and the > whole structure will be stored as data (as Archived data > object)? And after this, it will be renewed as the Archive > Time Stamp Chain? I would like this solution! I do not really understand your point but as far as I know LTANS or TAA is not suppose to deal with digital signatures. It's meant to conserve electronic records only, which means mainly integrity and time reference. Not even validation of signatures is under concern. I personally do not see such scenario evolving but i think complementary procedures will take place to handle digital signatures and their validity over time. > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some > examples, which will make clear the meaning (for example in > appendix). Again, TAA is not suppose to deal with signatures. And also, digital signatures are not timestamping objects alone. Whole document must get stamped to achieve proper archiving. > - Evidence record: this structure does not contain the > identification data of the archived document. How could you > find such document in the archive? This is a major problem and is addressed to management of archived records (and not really LTANS). You might consider OAIS or relevant standards to do the management. I have proposed to have metadata standard for archiving attributes, which would include also other security attributes and their refreshment. Actually the step we took in the designing phase of archival solutions deal with collecting archival, security and management attributes. Whether this is standardized and not is another issue. Regards Aleksej > - Archive Time-stamp, 3.1 Syntax: If I understand well: if > the reducedHashtree item misses, there is the time stamp from > the document instead of from the root-hash tree. If it is > true, it should be > described here. > > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with > different meaning in the RFC-3126. I would recommend to > adjust the name slightly. > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal > the ..." Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not > sufficient ..." Change to "The simple Time-Stamp renewal is > not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." > change to "A multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Æ = H (h(i_a)+ ha(i)) > h(i_b)Æ = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Æ", which various readers > could view in a different way. I would recommend to change it > for some other ascii character (e.g. for " ' "). > > > Libor & Marta > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VJS5hM025994; Wed, 31 Mar 2004 11:28: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 i2VJS5DM025993; Wed, 31 Mar 2004 11:28:05 -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 i2VJS44Y025982 for ; Wed, 31 Mar 2004 11:28:05 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 23124 invoked from network); 31 Mar 2004 19:27:58 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 31 Mar 2004 19:27:58 -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 22984-03 for ; Wed, 31 Mar 2004 21:27:58 +0200 (CEST) Received: (qmail 23119 invoked from network); 31 Mar 2004 19:27:58 -0000 Received: from arthur.e5.ijs.si (HELO arthur) (193.138.1.27) by e5.ijs.si with SMTP; 31 Mar 2004 19:27:58 -0000 From: "A. Jerman Blazic" To: Subject: RE: Our objections to draft ERS Date: Wed, 31 Mar 2004 21:27:58 +0200 Message-ID: <000201c41756$4605d470$1b018ac1@arthur> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> X-Virus-Scanned: by amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VJS54Y025988 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Libor, See comments inline > >From my point of view the complex impression of this draft is very > >good. > I was really pleased to see that this is already the proposal > standard. > > I could not cope with this sentence: "A time-stamp is > requested only for the root hash of the hash-tree" for a long > time. But after some time, I consider it to be a good idea. > If I think it over, the publishing of the root hash-tree in > newspapers every week is interesting, but the "classical" > time stamp acc. to RFC-3161 can easily temporarily replace > it if containing the week hash. > > 1. Objections > > - I do not understand, how documents with long-term > signatures will be archived (RFC-3126). When archiving > long-term signed document to the TAA, the renew of particular > digital signatures acc. to RFC-3126 will be finished and the > whole structure will be stored as data (as Archived data > object)? And after this, it will be renewed as the Archive > Time Stamp Chain? I would like this solution! I do not really understand your point but as far as I know LTANS or TAA is not suppose to deal with digital signatures. It's meant to conserve electronic records only, which means mainly integrity and time reference. Not even validation of signatures is under concern. I personally do not see such scenario evolving but i think complementary procedures will take place to handle digital signatures and their validity over time. > - Or only digital signatures will enter the Archive Time-stamp > calculation as it is in RFC-3126? I would invite some > examples, which will make clear the meaning (for example in > appendix). Again, TAA is not suppose to deal with signatures. And also, digital signatures are not timestamping objects alone. Whole document must get stamped to achieve proper archiving. > - Evidence record: this structure does not contain the > identification data of the archived document. How could you > find such document in the archive? This is a major problem and is addressed to management of archived records (and not really LTANS). You might consider OAIS or relevant standards to do the management. I have proposed to have metadata standard for archiving attributes, which would include also other security attributes and their refreshment. Actually the step we took in the designing phase of archival solutions deal with collecting archival, security and management attributes. Whether this is standardized and not is another issue. Regards Aleksej > - Archive Time-stamp, 3.1 Syntax: If I understand well: if > the reducedHashtree item misses, there is the time stamp from > the document instead of from the root-hash tree. If it is > true, it should be > described here. > > 2. Little objections > - "Archive Time-Stamp" collides with the same expression with > different meaning in the RFC-3126. I would recommend to > adjust the name slightly. > - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS > - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal > the ..." Change to "In the case of simple Time-Stamp Renewal the ..." > - chap. 1.2, paragraph 6: "Time-Stamp renewal is not > sufficient ..." Change to "The simple Time-Stamp renewal is > not sufficient ..." > - chap. 1.4, paragraph 2: "A multitude of data objects.." > change to "A multitude of archived data objects.." > - chap. 4.2 from paragraph: > " 4. Concatenate each h(i) with ha(i) and generate hash values > h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: > h(i_a)Æ = H (h(i_a)+ ha(i)) > h(i_b)Æ = H (h(i_b)+ ha(i)) etc" > > There is the non-ASCII character "Æ", which various readers > could view in a different way. I would recommend to change it > for some other ascii character (e.g. for " ' "). > > > Libor & Marta > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGUDm9010407; Wed, 31 Mar 2004 08:30:13 -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 i2VGUDbq010406; Wed, 31 Mar 2004 08:30:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from prometheus.terms.cz (prometheus.terms.cz [81.90.160.70]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGUBmB010390 for ; Wed, 31 Mar 2004 08:30:12 -0800 (PST) (envelope-from Libor.Dostalek@pvt.cz) Received: from cbuwdostalek2 ([81.90.165.93]) by prometheus.terms.cz (8.12.3/8.12.3/Debian-6.6) with ESMTP id i2VGTpDe032396 for ; Wed, 31 Mar 2004 18:30:03 +0200 From: To: Subject: Our objections to draft ERS Date: Wed, 31 Mar 2004 18:29:50 +0200 Message-ID: <000401c4173d$6a8fcf30$6402a8c0@pvt.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2VGUCmB010400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From my point of view the complex impression of this draft is very good. I was really pleased to see that this is already the proposal standard. I could not cope with this sentence: "A time-stamp is requested only for the root hash of the hash-tree" for a long time. But after some time, I consider it to be a good idea. If I think it over, the publishing of the root hash-tree in newspapers every week is interesting, but the "classical" time stamp acc. to RFC-3161 can easily temporarily replace it if containing the week hash. 1. Objections - I do not understand, how documents with long-term signatures will be archived (RFC-3126). When archiving long-term signed document to the TAA, the renew of particular digital signatures acc. to RFC-3126 will be finished and the whole structure will be stored as data (as Archived data object)? And after this, it will be renewed as the Archive Time Stamp Chain? I would like this solution! - Or only digital signatures will enter the Archive Time-stamp calculation as it is in RFC-3126? I would invite some examples, which will make clear the meaning (for example in appendix). - Evidence record: this structure does not contain the identification data of the archived document. How could you find such document in the archive? - Archive Time-stamp, 3.1 Syntax: If I understand well: if the reducedHashtree item misses, there is the time stamp from the document instead of from the root-hash tree. If it is true, it should be described here. 2. Little objections - "Archive Time-Stamp" collides with the same expression with different meaning in the RFC-3126. I would recommend to adjust the name slightly. - chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal the ..." Change to "In the case of simple Time-Stamp Renewal the ..." - chap. 1.2, paragraph 6: "Time-Stamp renewal is not sufficient ..." Change to "The simple Time-Stamp renewal is not sufficient ..." - chap. 1.4, paragraph 2: "A multitude of data objects.." change to "A multitude of archived data objects.." - chap. 4.2 from paragraph: " 4. Concatenate each h(i) with ha(i) and generate hash values h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is: h(i_a)Æ = H (h(i_a)+ ha(i)) h(i_b)Æ = H (h(i_b)+ ha(i)) etc" There is the non-ASCII character "Æ", which various readers could view in a different way. I would recommend to change it for some other ascii character (e.g. for " ' "). Libor & Marta Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VBdwBg087044; Wed, 31 Mar 2004 03:39:58 -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 i2VBdwwb087043; Wed, 31 Mar 2004 03:39:58 -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 i2VBdutL087033 for ; Wed, 31 Mar 2004 03:39:57 -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 NAA20812; Wed, 31 Mar 2004 13:39:23 +0200 (MET DST) Message-ID: <406AAE4A.8060800@sit.fraunhofer.de> Date: Wed, 31 Mar 2004 13:40:58 +0200 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: Larry Masinter CC: ietf-ltans@imc.org, chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving References: <0HVC00JTXTQRQL@mailsj-v1.corp.adobe.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: Larry or Santosh, Could someone tell me how the n of m scheme replaces the need of an (accredited) time-stamping or time-marking service, when the date of document existance must be proved? Is it assumed that each TAA simply states (and signs) when the document existed and when n TAAs state the same date, this date is correct and trustworthy? Regards, Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TKIX8o070530; Mon, 29 Mar 2004 12:18:33 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TKIXUb070529; Mon, 29 Mar 2004 12:18:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TKIXrA070503 for ; Mon, 29 Mar 2004 12:18:33 -0800 (PST) (envelope-from LMM@acm.org) Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i2TKIUSP025427 for ; Mon, 29 Mar 2004 12:18:30 -0800 (PST) Received: from calsj-dev (mailsj [153.32.1.239]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i2TKIS3k010027 for ; Mon, 29 Mar 2004 12:18:28 -0800 (PST) Received: from MasinterT40 ([130.248.178.75]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVC00JTWTQRQL@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Mon, 29 Mar 2004 12:18:27 -0800 (PST) Date: Mon, 29 Mar 2004 12:18:25 -0800 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving In-reply-to: <001601c41339$cae81ed0$9a00a8c0@hq.orionsec.com> To: ietf-ltans@imc.org Message-id: <0HVC00JTXTQRQL@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcQTOzvF7wy1hsuLR0++9tiEB6hZ8gA78SPw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think my main point is that the standard for the network protocol for accessing and interacting with a long term archive and notary (distributed) service should not be tied to the mechanism that the service uses for insuring long term archives and non-repudiation. The current requirements document seems to be too tightly tied to the architecture of the underlying repository and the nature of the mechanisms by which it supplies services. Personally, I think that we should look for "long term archives" solutions that do not rely on algorithmic complexity and one-way functions as the mechanism for insuring privacy, integrity, etc. Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TE8PNN042222; Mon, 29 Mar 2004 06:08:25 -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 i2TE8PnX042221; Mon, 29 Mar 2004 06:08:25 -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 i2TE8ORv042214 for ; Mon, 29 Mar 2004 06:08:25 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2TE8QBv006098 for ; Mon, 29 Mar 2004 09:08:26 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Mon, 29 Mar 2004 09:08:26 -0500 Message-ID: <000b01c41597$4ded5160$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C4156D.65174960" 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: <0HV300C17Q322M@mailsj-v1.corp.adobe.com> 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_000C_01C4156D.65174960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Larry: =20 I have reviewed this paper. Here are some of my observations: =20 . The paper is oriented towards confidentiality . Paper deals with multiple archive servers and what do do if = some are decommissioned or corrupted and others need to be commissioned. We currently do not address the need for multiple servers and we do not = handle decommissioning and commissioning. While the work done to date in LTANS does not address this as a requirement or solution, I think having n of = m and then redistributing shares to create n' of m' should be part of our standard. . The paper deals with integrity of share broadcast that Micali, Feldman etc have provided. This should not be of concern to us since we = can use TLS for secrecy and integrity of current data. My concern largely = here is that of patent . Speaking of patents, I hope the redistribution scheme by = Jajodia or this work are not under patent. =20 I also did not see any outstanding issues with us going forward with = many of the features of n of m. I would suggest that we move out with this = work. -----Original Message----- From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter Sent: Wednesday, March 24, 2004 5:21 PM To: 'Santosh Chokhani' Cc: ietf-ltans@imc.org Subject: RE: Alternatives for Long Term Archiving There seems to be quite a bit of research in this area. For example, see http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are = still open issues about how to manage trust over the long term, and even = identity. =20 Larry =20 ------=_NextPart_000_000C_01C4156D.65174960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Larry:
 
I have=20 reviewed this paper.  Here are some of my = observations:
 

·         The=20 paper is=20 oriented towards confidentiality

·        =20 Paper deals with multiple archive servers and what do do if some are = decommissioned or=20 corrupted and  others need to = be=20 commissioned.  We currently do not address the need for multiple = servers=20 and we do not handle decommissioning and commissioning.  While the = work=20 done to date in LTANS does not address this as a requirement or = solution, I=20 think having n of m and then=20 redistributing shares to create n' of m' should be part of our=20 standard.

·         The paper=20 deals with integrity of share = broadcast that=20 Micali, Feldman etc have provided.  This=20 should not be of = concern to us=20 since we can use TLS for secrecy and integrity of current data.  My concern largely = here is that=20 of patent

·         Speaking of = patents, I hope the=20 redistribution scheme by Jajodia or this work are not under=20 patent.

=
 
I also=20 did not see any outstanding issues with us going forward with many of = the=20 features of n of m.  I would suggest that we move out with this=20 work.
-----Original=20 Message-----
From: owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry=20 Masinter
Sent: Wednesday, March 24, 2004 5:21 = PM
To:=20 'Santosh Chokhani'
Cc: ietf-ltans@imc.org
Subject: = RE:=20 Alternatives for Long Term Archiving

There seems to be quite a bit of research in = this area.=20 For example, see  http://www.pdl= .cmu.edu/PDL-FTP/PASIS/SISW2002.pdf.=20 I think there are still open issues about how to manage trust over the = long=20 term, and even identity.
 
Larry
 
------=_NextPart_000_000C_01C4156D.65174960-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2RCZ1wK086037; Sat, 27 Mar 2004 04:35:01 -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 i2RCZ1f6086036; Sat, 27 Mar 2004 04:35:01 -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 i2RCYxwo086024 for ; Sat, 27 Mar 2004 04:35:00 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i2RCYtN01951; Sat, 27 Mar 2004 13:34:55 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 27 Mar 2004 13:34:55 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i2RCYrM17153; Sat, 27 Mar 2004 13:34:53 +0100 (MET) Date: Sat, 27 Mar 2004 13:34:53 +0100 (MET) From: Peter Sylvester Message-Id: <200403271234.i2RCYrM17153@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, kent@songbird.com Subject: Re: Alternatives for Long Term Archiving Cc: chokhani@orionsec.com, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry for that strange attachment. It doesn't contain anything important. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QDs28u013852; Fri, 26 Mar 2004 05:54: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 i2QDs2Fs013851; Fri, 26 Mar 2004 05:54:02 -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 i2QDs1Np013845 for ; Fri, 26 Mar 2004 05:54:02 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2QDs1Iu018936 for ; Fri, 26 Mar 2004 08:54:01 -0500 From: "Santosh Chokhani" To: Subject: RE: Alternatives for Long Term Archiving Date: Fri, 26 Mar 2004 08:54:00 -0500 Message-ID: <001601c41339$cae81ed0$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4063F99F.9050505@sit.fraunhofer.de> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2QDs2Np013846 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Brian: See responses in-line in []. -----Original Message----- From: Brian Hunter [mailto:brian.hunter@sit.fraunhofer.de] Sent: Friday, March 26, 2004 4:37 AM To: Santosh Chokhani Cc: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving I think that a keyless approach could be an ideal approach, however, I don't see Shamir's scheme as solving all of our problems. First, the complexity of the system would increase. [I think the complexity of the client will increase. But, the TAAs will become very, very simply. In my judgment the overall system complexity will reduce since there is no encryption, signature, timestamp, time refresh etc., but a simply n of m split only one time] This starts with the distribution of the original document, and then the possible redistribution of the document as TAAs are removed or added. Such functionality would add to the complexity of the (server-server) protocols. [Actually, when TAAs are removed or added, n of m scheme may be better suited to handle this. I have not fully grasped Shamir's technique, but it lets you add new shares if some properties hold. Removal on the other hand can be handled in two ways. n of m gives you some margin for removing some TAs (may be up to m-n). Alternatively, since there are no keys involved it will be easier to move to a newly created TAA. In the current proposal, the whole stuff has to be with another TAA] Furthermore, stricter access control must be ensured, such that an attacker can't simply retrieve n parts of the document from the TAAs. Using the current encryption scheme, an attacker would first have to bypass the access control of the (single) TAA, and then have to break the encryption of the document. Thus, the security focus of the systems are different, one is strictly based upon access control, the other on access control and encryption. One could even argue that no access control is needed for the evidence records, since they only contain a hash of the document and reveal nothing about its content. [n of m does not prevent you from encrypting the document. I just wanted to point out that confidentiality against TAAs and against an eavesdropper can be easily achieved. If you think all TAAs' access controls can be bypassed (not just one TAA's), which I doubt, you can encrypt the document a la current proposal. The cost to archive a document would increase, likely linearly based on the size of m. How many clients want to pay m times more for a service? (unless the alternatives are shown to be insufficient) Furthermore, each TAA would probably have to be, at least in Germany, accredited, since it is attesting for the document insertion time (and integrity). Accreditation is not needed by the TAAs in the ERS solution, only accredited TSA(s) are needed. [Cost may be a concern. But, hopefully even 2 of 2 might suffice. Also, since TAAs are simple, cost per archival should offset some of the costs. This is one of the reasons, I do not want to standardize on current proposal alone or n of m alone, but see if there is a way to accommodate both and have most aspects of transactions and storage record common.] I believe that this distribution approach could be useful, for at least particular cases, but am unsure if it is suitable today for a generic archive service that needs to be efficient and cost effective for large volumes of documents. Thus, I still think (based on what has been presented so far) that ERS should be continued, in order to get a needed, standard, viable solution in the near future, and the distribution approach could be further investigated, refined and then in the future be evaluated whether it is added to the LTANS approach as the new recommended method, or as an optional method recommended for specific use cases. [I would like to read the paper Larry pointed to and then make a judgment if ERS or both ERS and n of m should be considered. I am not proposing that ERS be not part of the approach.]. Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q9ZIxg085860; Fri, 26 Mar 2004 01:35:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q9ZIuw085859; Fri, 26 Mar 2004 01:35:18 -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 i2Q9ZHWl085746 for ; Fri, 26 Mar 2004 01:35:17 -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 KAA01238; Fri, 26 Mar 2004 10:34:40 +0100 (MET) Message-ID: <4063F99F.9050505@sit.fraunhofer.de> Date: Fri, 26 Mar 2004 10:36:31 +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: Santosh Chokhani CC: ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving References: <000601c411cf$0045bf90$9a00a8c0@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: I think that a keyless approach could be an ideal approach, however, I don't see Shamir's scheme as solving all of our problems. First, the complexity of the system would increase. This starts with the distribution of the original document, and then the possible redistribution of the document as TAAs are removed or added. Such functionality would add to the complexity of the (server-server) protocols. Furthermore, stricter access control must be ensured, such that an attacker can't simply retrieve n parts of the document from the TAAs. Using the current encryption scheme, an attacker would first have to bypass the access control of the (single) TAA, and then have to break the encryption of the document. Thus, the security focus of the systems are different, one is strictly based upon access control, the other on access control and encryption. One could even argue that no access control is needed for the evidence records, since they only contain a hash of the document and reveal nothing about its content. The cost to archive a document would increase, likely linearly based on the size of m. How many clients want to pay m times more for a service? (unless the alternatives are shown to be insufficient) Furthermore, each TAA would probably have to be, at least in Germany, accredited, since it is attesting for the document insertion time (and integrity). Accreditation is not needed by the TAAs in the ERS solution, only accredited TSA(s) are needed. I believe that this distribution approach could be useful, for at least particular cases, but am unsure if it is suitable today for a generic archive service that needs to be efficient and cost effective for large volumes of documents. Thus, I still think (based on what has been presented so far) that ERS should be continued, in order to get a needed, standard, viable solution in the near future, and the distribution approach could be further investigated, refined and then in the future be evaluated whether it is added to the LTANS approach as the new recommended method, or as an optional method recommended for specific use cases. Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLZDCr071061; Thu, 25 Mar 2004 13:35:13 -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 i2PLZDvu071060; Thu, 25 Mar 2004 13:35:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from joy.songbird.com (joy.songbird.com [208.184.79.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLZCvh071054 for ; Thu, 25 Mar 2004 13:35:12 -0800 (PST) (envelope-from kent@raven.songbird.com) Received: from raven.songbird.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i2PLZHd24700; Thu, 25 Mar 2004 13:35:17 -0800 Received: (from kent@localhost) by raven.songbird.com (8.12.10/8.12.10/Submit) id i2PLZDJf012518; Thu, 25 Mar 2004 13:35:13 -0800 Date: Thu, 25 Mar 2004 13:35:13 -0800 From: kent crispin To: Peter Sylvester Cc: chokhani@orionsec.com, ietf-ltans@imc.org Subject: Re: Alternatives for Long Term Archiving Message-ID: <20040325213513.GB8516@raven.songbird.com> Mail-Followup-To: Peter Sylvester , chokhani@orionsec.com, ietf-ltans@imc.org References: <200403252108.i2PL8FB11242@chandon.edelweb.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403252108.i2PL8FB11242@chandon.edelweb.fr> User-Agent: Mutt/1.4.1i Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 25, 2004 at 10:08:15PM +0100, Peter Sylvester wrote: Hi Peter -- your mail client is sending strange attachments: [-- application/x-X-sun-attachment is unsupported (use 'v' to view this part) --] -- Kent Crispin kent@icann.org p: +1 310 823 9358 f: +1 310 823 8649 kent@songbird.com SIP: 81202@fwd.pulver.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLA4Hj069730; Thu, 25 Mar 2004 13:10:04 -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 i2PLA4pK069729; Thu, 25 Mar 2004 13:10:04 -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 i2PLA4iI069723 for ; Thu, 25 Mar 2004 13:10:04 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2PLA8Iu032276 for ; Thu, 25 Mar 2004 16:10:08 -0500 From: "Santosh Chokhani" To: Subject: FW: April 12-14: 3rd Annual PKI R&D Workshop Date: Thu, 25 Mar 2004 16:10:08 -0500 Message-ID: <010d01c412ad$8d7ce030$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i2PLA4iI069724 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FYI. ------------- The 3rd Annual PKI R&D Workshop is almost here: April 12-14 2004 at NIST in Gaithersburg, MD. Registrations should be in by Monday March 29. The program features a broad variety of perspectives, results and new ideas on the use of Public Key technology for security decision making, not just traditional "PKI". There are talks and panel sessions on the dynamic delegation of rights, application-specific PKI designs, document signatures, certificate path discovery, experience papers and panels on where to go from here. Speakers include Peter Gutmann, Carlisle Adams, Stefan Brands, Ken Klingenstein, John Linn, Tim Polk, Von Welch and many other experts. The intimate workshop atmosphere provides ample opportunities to interact with others working on the issues you're facing, including Work-In-Progress and Birds-of-a-Feather sessions. 802.11b Wireless access points will be available for SSH, IPSEC, HTTP, DNS, FTP, POP, IMAP, and SMTP connectivity. At only $105 for registration, it's a bargain. More information at http://middleware.internet2.edu/pki04/ Neal McBurnett http://bcn.boulder.co.us/~neal/ Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60 Preliminary Program - Subject to change Monday, April 12 12:00 - 12:15 Opening Remarks Program Committee Susan Zevin Director, Information Technology Laboratory, NIST 12:15 - 1:15 KEYNOTE ADDRESS Non-Intrusive Cross-Domain Identity Management Stefan Brands Credentica 2:00 - 3:30 Role Sharing in Password-Enabled PKI Xunhua Wang James Madison University Greenpass: Decentralized, PKI-based Authorization for Wireless LANs Nicholas C. Goffee Dartmouth College X.509 Proxy Certificates for Dynamic Delegation Von Welch National Center for Supercomputing Applications, University of Illinois 4:00 - 5:30 Panel: Controlled and Dynamic Delegation of Rights Moderator: Frank Siebenlist Argonne National Laboratory 6:15 - 8:00 Social Gathering and Workshop Dinner Gaithersburg Holiday Inn 8:00 - 9:00 Work in Progress Session Gaithersburg Holiday Inn Contact Krishna Sankar if you would like to present some Work in Progress Tuesday, April 13 9:00 - 10:00 KEYNOTE ADDRESS Simple, Straightforward, Functional PKI Peter Gutmann University of Auckland 10:00 - 10:30 Experiences of establishing trust in a distributed system operated by mutually distrusting parties David Chadwick University of Salford 11:00 - 12:00 Panel: An update on Phase Three of the PKI Interop Project with EDUCAUSE Moderator: Peter Alterman National Institutes of Health Deb Blanchard Digital Signature Trust Russ Weiser Betrusted 12:00 - 12:30 Trusted Archiving Santosh Chokhani Orion Security Solutions 12:30 - 2:00: Lunch - NIST Cafeteria 2:00 - 3:00 Panel: Document Signatures Moderator: Randy Sabett, Cooley Godward LLP & Tim Polk NIST 3:00 - 3:30 PKI: Ten Years Later Carlisle Adams University of Ottawa 4:00 - 4:30 An Examination of Asserted PKI Issues and Proposed Alternatives John Linn RSA Laboratories 4:30 - 5:30 Panel: Which PKI Approach for Which Application Domain? Moderator: Peter Alterman National Institutes of Health Carl Ellison Microsoft Russ Weiser Betrusted 5:30 - 8:00: Dinner (on your own) 8:00 - 9:00 Birds of a Feather sessions - sign up at Registration Wednesday, April 14 9:00 - 10:00 KEYNOTE ADDRESS The Middleware Connection Ken Klingenstein University of Colorado; Internet2 10:00 - 10:30 Private Revocation Test using Oblivious Membership Evaluation Protocol Hiroaki Kikuchi Tokai University 11:00 - 11:30 "Dynamic Bridge" Concept Paper Ken Stillson Mitretek Systems 11:30 - 12:30 Panel: Approaches to Certificate Path Discovery Moderator: Peter Hesse Gemini Security Solutions Steve Hanna Sun Microsystems Matt Cooper Orion Security Solutions Ken Stillson Mitretek Systems 12:30 - 2:00: Lunch - NIST Cafeteria 2:00 - 2:30 Johnson & Johnson Use of Public Key Technology Rich Guida Johnson & Johnson 2:30 - 3:00 Identifying and Overcoming Obstacles to PKI Deployment and Usage Jean Pawluk Inovant 3:30 - 4:30 Panel: The PKI Action Plan: Will it make a difference? Moderator: Steve Hanna Sun Microsystems Lieutenant Commander Thomas Winnenberg U.S.N., DISA Jean Pawluk Inovant Tim Polk NIST John Linn RSA Laboratories Sean Smith Dartmouth College 4:30 - 5:00 Wrapup Session Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PL8E1R069448; Thu, 25 Mar 2004 13:08: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 i2PL8EAX069447; Thu, 25 Mar 2004 13:08:14 -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 i2PL8CpG069439 for ; Thu, 25 Mar 2004 13:08:13 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i2PL8GN07692; Thu, 25 Mar 2004 22:08:16 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 25 Mar 2004 22:08:16 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i2PL8FB11242; Thu, 25 Mar 2004 22:08:15 +0100 (MET) Date: Thu, 25 Mar 2004 22:08:15 +0100 (MET) From: Peter Sylvester Message-Id: <200403252108.i2PL8FB11242@chandon.edelweb.fr> To: chokhani@orionsec.com Subject: Re: Alternatives for Long Term Archiving Cc: ietf-ltans@imc.org Content-Type: X-sun-attachment Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 13 > One of the ideas that came out of Seoul meeting (thanks to Larry Masinter) > is to use a key-less approach to trusted archive. The client who has vested > interest in the secure storage of archived data, can use Shamir's n of m > scheme to submit the archived data to m archive facilities. m must be > greater than 1 and should be selected based on availability needs. n must be > greater than 1, less than or equal to m, and should be selected based on the > desired degree of protection against collusion. > Addressing the problem of confidentiality and redundancy need in this way had been proposed as one of the work iteme of a research project APRICOT concerning archiving. It seems useful to me to elaborate how these aproach can be implemented in practice. ---------- X-Sun-Data-Type: html X-Sun-Encoding-Info: quoted-printable X-Sun-Content-Length: 5575 X-Sun-Content-Lines: 129 Message
One of = the ideas=20 that came out of Seoul meeting (thanks to Larry Masinter) is to use a = key-less=20 approach to trusted archive.  The client who has vested interest in = the=20 secure storage of archived data, can use Shamir's n of m scheme to = submit the=20 archived data to m archive facilities.  m must be greater than 1 = and should=20 be selected based on availability needs. n must be greater than 1, less = than or=20 equal to m, and should be selected based on the desired degree of = protection=20 against collusion.
 
If = this scheme is=20 used, we may not need any cryptographic operations at the=20 TAA.
 
Under = this scheme,=20 the LTANS WG would need to still define various protocol for submission, = deletion, and retrieval.  if the idea is acceptable to the group, = it could=20 be the preferred or one of the approaches to perform=20 archiving.
 
As the = current LTANS=20 documents in the various stages state or imply,=20 the trusted archive can continue to be used to submit any = class of=20 data.
 
One = advantage of the=20 approach is that any document split is not sensitive even = if the=20 original document is sensitive.  However, if the document requires=20 confidentiality, assuming an adversary could be monitoring the = channels to=20 collect all the splits, the submission and retrieval of the split should = be=20 provided transmission security using techniques such as SSL or session=20 encryption.  This still is lot easier than needing to provide = long-term=20 encryption for stored data.
 
To = further=20 illustrate one usage of the approach, a client with the need to = provide=20 long-term, non-repudiation of a transaction, could obtain current = time=20 stamp, all the trust anchor, certificates, revocation information = relevant to=20 signatures and time stamp, and package them using TBD record format and = create m=20 splits.  These m split could be sent to m TAAs using TLS.  = Each TLS=20 could provide a pointer to its split.
 
When = there is a need=20 to retrieve the evidence, n splits could be retrieved from n TAAs that = are=20 available and can be combined to validate the signatures on the = transaction as=20 well as the time stamp.
 
The = approach also=20 offers some redundancy in case some TAAs are not available, data is = corrupted,=20 or the challenger does not trust some of the TAAs.
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OML8qO095722; Wed, 24 Mar 2004 14:21:08 -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 i2OML8Rr095721; Wed, 24 Mar 2004 14:21:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp-relay-7.sea.adobe.com (smtp-relay-7.adobe.com [192.150.22.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OML78X095713 for ; Wed, 24 Mar 2004 14:21:08 -0800 (PST) (envelope-from LMM@acm.org) Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i2OML5SP011829; Wed, 24 Mar 2004 14:21:06 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i2OML3kq025660; Wed, 24 Mar 2004 14:21:03 -0800 (PST) Received: from MasinterT40 (c-67-195.corp.adobe.com [153.32.67.195]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HV300C16Q322M@mailsj-v1.corp.adobe.com>; Wed, 24 Mar 2004 14:21:02 -0800 (PST) Date: Wed, 24 Mar 2004 14:21:03 -0800 From: Larry Masinter Subject: RE: Alternatives for Long Term Archiving In-reply-to: <000601c411cf$0045bf90$9a00a8c0@hq.orionsec.com> To: "'Santosh Chokhani'" Cc: ietf-ltans@imc.org Message-id: <0HV300C17Q322M@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: multipart/alternative; boundary="Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)" Thread-index: AcQR0NsZsZKEdLl/TTm+iWmOg4Z4nwABRxPA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT There seems to be quite a bit of research in this area. For example, see http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are still open issues about how to manage trust over the long term, and even identity. Larry --Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message
There seems to be quite a bit of research in this area. For example, see  http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are still open issues about how to manage trust over the long term, and even identity.
 
Larry
 
--Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2OIb1Me078268; Wed, 24 Mar 2004 10:37:01 -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 i2OIb14H078267; Wed, 24 Mar 2004 10:37:01 -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 i2OIb0Du078261 for ; Wed, 24 Mar 2004 10:37:00 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (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 i2OIasIu029568 for ; Wed, 24 Mar 2004 13:37:03 -0500 From: "Santosh Chokhani" To: Subject: Alternatives for Long Term Archiving Date: Wed, 24 Mar 2004 13:36:54 -0500 Message-ID: <000601c411cf$0045bf90$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C411A5.176FB790" 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 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_0007_01C411A5.176FB790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of the ideas that came out of Seoul meeting (thanks to Larry = Masinter) is to use a key-less approach to trusted archive. The client who has = vested interest in the secure storage of archived data, can use Shamir's n of m scheme to submit the archived data to m archive facilities. m must be greater than 1 and should be selected based on availability needs. n = must be greater than 1, less than or equal to m, and should be selected based on = the desired degree of protection against collusion. =20 If this scheme is used, we may not need any cryptographic operations at = the TAA. =20 Under this scheme, the LTANS WG would need to still define various = protocol for submission, deletion, and retrieval. if the idea is acceptable to = the group, it could be the preferred or one of the approaches to perform archiving. =20 As the current LTANS documents in the various stages state or imply, the trusted archive can continue to be used to submit any class of data. =20 One advantage of the approach is that any document split is not = sensitive even if the original document is sensitive. However, if the document requires confidentiality, assuming an adversary could be monitoring the channels to collect all the splits, the submission and retrieval of the split should be provided transmission security using techniques such as = SSL or session encryption. This still is lot easier than needing to provide long-term encryption for stored data. =20 To further illustrate one usage of the approach, a client with the need = to provide long-term, non-repudiation of a transaction, could obtain = current time stamp, all the trust anchor, certificates, revocation information relevant to signatures and time stamp, and package them using TBD record format and create m splits. These m split could be sent to m TAAs using TLS. Each TLS could provide a pointer to its split. =20 When there is a need to retrieve the evidence, n splits could be = retrieved from n TAAs that are available and can be combined to validate the signatures on the transaction as well as the time stamp. =20 The approach also offers some redundancy in case some TAAs are not available, data is corrupted, or the challenger does not trust some of = the TAAs. =20 Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ------=_NextPart_000_0007_01C411A5.176FB790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
One of = the ideas=20 that came out of Seoul meeting (thanks to Larry Masinter) is to use a = key-less=20 approach to trusted archive.  The client who has vested interest in = the=20 secure storage of archived data, can use Shamir's n of m scheme to = submit the=20 archived data to m archive facilities.  m must be greater than 1 = and should=20 be selected based on availability needs. n must be greater than 1, less = than or=20 equal to m, and should be selected based on the desired degree of = protection=20 against collusion.
 
If = this scheme is=20 used, we may not need any cryptographic operations at the=20 TAA.
 
Under = this scheme,=20 the LTANS WG would need to still define various protocol for submission, = deletion, and retrieval.  if the idea is acceptable to the group, = it could=20 be the preferred or one of the approaches to perform=20 archiving.
 
As the = current LTANS=20 documents in the various stages state or imply,=20 the trusted archive can continue to be used to submit any = class of=20 data.
 
One = advantage of the=20 approach is that any document split is not sensitive even = if the=20 original document is sensitive.  However, if the document requires=20 confidentiality, assuming an adversary could be monitoring the = channels to=20 collect all the splits, the submission and retrieval of the split should = be=20 provided transmission security using techniques such as SSL or session=20 encryption.  This still is lot easier than needing to provide = long-term=20 encryption for stored data.
 
To = further=20 illustrate one usage of the approach, a client with the need to = provide=20 long-term, non-repudiation of a transaction, could obtain current = time=20 stamp, all the trust anchor, certificates, revocation information = relevant to=20 signatures and time stamp, and package them using TBD record format and = create m=20 splits.  These m split could be sent to m TAAs using TLS.  = Each TLS=20 could provide a pointer to its split.
 
When = there is a need=20 to retrieve the evidence, n splits could be retrieved from n TAAs that = are=20 available and can be combined to validate the signatures on the = transaction as=20 well as the time stamp.
 
The = approach also=20 offers some redundancy in case some TAAs are not available, data is = corrupted,=20 or the challenger does not trust some of the TAAs.
 

Santosh = Chokhani=20
Orion Security = Solutions,=20 Inc.
1489 Chain=20 Bridge Road, Suite 300
McLean, Virginia 22101
(703) 917-0060  Ext. 35 (voice)
(703) 917-0260 (Fax) =
chokhani@orionsec.com
Visit our Web = site
http://www.orionsec.com

 
------=_NextPart_000_0007_01C411A5.176FB790-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AHSC068298; Wed, 10 Mar 2004 01:10:17 -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 i2A9AHBM068297; Wed, 10 Mar 2004 01:10:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from postman-pat.actimage.fr (postman-pat.actimage.net [80.87.224.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A9AF5l068238 for ; Wed, 10 Mar 2004 01:10:16 -0800 (PST) (envelope-from muriel@actimage.net) Received: from leila (inet-gate3 [80.87.224.93]) by postman-pat.actimage.fr (8.11.4/8.11.4) with SMTP id i2A93qC22479 for ; Wed, 10 Mar 2004 10:03:52 +0100 (CET) Message-ID: <03b001c4067f$c75842c0$4406a8c0@leila> From: "Muriel Souville" To: Subject: Launch of the Security Plugtests Registration Date: Wed, 10 Mar 2004 10:12:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A3_01C40688.2621BA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 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_03A3_01C40688.2621BA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, The ETSI Plugtests(tm) Service is pleased to announce the opening of the Security Plugtests registration. The event will take place from 24 till 28 May at the ETSI premises, in Sophia Antipolis (France). Deadline to register is 5th May. All details about the event are to be found at http://www.etsi.org/plugtests/security.htm Feel free to forward this email to as many people as you want in order to have a really interesting test opportunity this week. For any enquiry you may have, please write to plugtests@etsi.org. Thanks for your attention. We look forward to welcoming you at our Headquarters in May. Best regards Muriel SOUVILLE ETSI Consultant Tel: +33 (0) 3 90 23 63 63 ------=_NextPart_000_03A3_01C40688.2621BA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear=20 all,

The ETSI Plugtests(tm) Service is pleased to announce the=20 opening
of the Security Plugtests registration.
The event will = take place=20 from 24 till 28 May at the ETSI premises,
in Sophia Antipolis=20 (France).
Deadline to register is 5th May.

 All details = about the=20 event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as = many people=20 as you want in order
to have a really interesting test opportunity = this=20 week.

For any enquiry you may have, please write to plugtests@etsi.org.

Thanks for your attention.
We look forward to = welcoming you=20 at our Headquarters in May.

Best regards

Muriel = SOUVILLE
ETSI=20 Consultant
Tel: +33 (0) 3 90 23 63=20 63
------=_NextPart_000_03A3_01C40688.2621BA40--