Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VGlVXv028371; Wed, 31 Aug 2005 09:47:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j7VGlVir028369; Wed, 31 Aug 2005 09:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.128.48.ixos.de [149.235.128.48]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j7VGlSET028361 for ; Wed, 31 Aug 2005 09:47:29 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j7VGlGAr016340 for ; Wed, 31 Aug 2005 18:47:27 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AE4B.A4F7F892" Subject: LTANS: new milestones online and info Date: Wed, 31 Aug 2005 18:47:27 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0700118AA1C@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: new milestones online and info Thread-Index: AcWuS6vAnMkkoFO9TTqGbmZVc1sh4Q== X-Priority: 1 Importance: high From: "Tobias Gondrom" To: 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_001_01C5AE4B.A4F7F892 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 as one of the tasks from the meeting in Paris we updated our schedule. Please all authors take a close look and try to get along with the dates. =20 And besides this, a short latest update on the work of LTANS: =20 Beginning this year we read a lot news about the problems with the "broken" SHA-1 and this made many people very concerned about what would have to be done with signed data when trouble is really breaking out. =20 With this in mind our work at LTANS is of significant importance to industry and customers. Currently there already exist two different independent implementations (of the meanwhile pretty stable) ERS. They currently try to follow changes in the spec as good as they can with more and more trouble as the implementations will be installed at a large number of customers within the next months. I want to ensure the stability of those needed implementations (and the ones to come in the future) and to prevent a defacto (industry) standard while the problem is slowly overtaking our achievements in standardization. We did great work in the starting of the WG LTANS but it seems that we somehow lack a bit in the finishing of our work. The customers out there are going to need a solution for the long term archiving of signed data very soon. We should keep clearly in focus to get our results out within the proposed milestones. =20 Second it will be of great importance that we identify issues (and get more details) that need to be covered with the so called "notary service" within the next 4 months. Otherwise the WG will be shut down next spring without addressing this issue! =20 Best regards,=20 =20 Tobias, chair of LTANS =20 ------_=_NextPart_001_01C5AE4B.A4F7F892 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

as one of the tasks from the meeting in Paris we updated our = schedule.

Please all authors take a close look and try to get = along with the dates.

 

And besides this, a short latest update on the work = of LTANS:

 

Beginning this year we read a lot news about the = problems with the “broken” SHA-1 and this made many people very = concerned about what would have to be done with signed data when trouble is really breaking out.

 

With this in mind our work at LTANS is of significant = importance to industry and customers.

Currently there already exist two different = independent implementations (of the meanwhile pretty stable) ERS. They currently try to follow = changes in the spec as good as they can with more and more trouble as the = implementations will be installed at a large number of customers within the next months. = I want to ensure the stability of those needed implementations (and the ones to = come in the future) and to prevent a defacto (industry) standard while the = problem is slowly overtaking our achievements in = standardization.

We did great work in the starting of the WG LTANS but = it seems that we somehow lack a bit in the finishing of our work. The = customers out there are going to need a solution for the long term archiving of = signed data very soon.

We should keep clearly in focus to = get our results out within the proposed = milestones.

 

Second it will be of great importance that we = identify issues (and get more details) that need to be covered with the so called = “notary service” within the next 4 months. Otherwise the WG will be shut = down next spring without addressing this issue!

 

Best regards,

 

Tobias, chair of LTANS

 

------_=_NextPart_001_01C5AE4B.A4F7F892-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j789EUV7049492; Mon, 8 Aug 2005 02:14:30 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j789EUGW049491; Mon, 8 Aug 2005 02:14:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from web42002.mail.yahoo.com (web42002.mail.yahoo.com [66.218.93.170]) by above.proper.com (8.12.11/8.12.9) with SMTP id j789EUAg049454 for ; Mon, 8 Aug 2005 02:14:30 -0700 (PDT) (envelope-from mtcarrascob@yahoo.com) Received: (qmail 77160 invoked by uid 60001); 8 Aug 2005 09:14:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iq0rfjY1WfSwx8Jq7to7uyTOVKYAMsgEjNsPI006c8RWIdh58ObSLFS4mrKnUz1jC3Dvu0dSn6zPc8B/ckqVc0V/JsJAPkZU7nxtK744mjpDFsLWy4ydyTVWpzCop61geHRiBdrEfDK4+Nqbae8y3crrzGTlzAw/f5ATUhS08UM= ; Message-ID: <20050808091424.77158.qmail@web42002.mail.yahoo.com> Received: from [158.169.9.14] by web42002.mail.yahoo.com via HTTP; Mon, 08 Aug 2005 10:14:24 BST Date: Mon, 8 Aug 2005 10:14:24 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: IETF 63 To: ietf-ltans@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Comments following the meeting on the 1st August 2005 (IETF 63) 1) Minimal LTANS One should identify a minimal LTANS that fulfils a large practical need. For example: submitting public objects to be kept for eternity; i.e., *no* ACL, deletion, accounting, etc. This could be implemented fast and not in ten years. In addition to solve present needs, one starts to gain real practical experience. The LTANS profiled in the meeting seems to be far away; say five to ten years. Though, one has to continue to specify a proper framework with all the mechanisms. 2) Levels One needs a way that allows the specification and implementation of LTANs with a variable number of mechanisms. For example: LTAN level 1 : Minimal LTAN level 2 : Also includes ACL … LTAN level n : Full thing 3) Present implementation Reading the drafts, it does not seem to be possible to write today some running code. 4) Service vs. application LTANS should *not* include aspects such as ACL, accounting, etc. Though, these services are needed to construct an application together with LTANS; (service vs. application comes from a corridor conversation with Larry Masinter). 5) Terminology “Notary” illustrates well the idea behind the services. It does not matter that the meaning of notary changes somewhat from one country to another: just define the precise the meaning for LTANS. If the term is no longer acceptable, the name of the group should be changed. Regards Tomas ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74BjTEX084983; Thu, 4 Aug 2005 04:45:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j74BjTxo084982; Thu, 4 Aug 2005 04:45:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j74BjR6W084960 for ; Thu, 4 Aug 2005 04:45:28 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j74Bj4bP008525; Thu, 4 Aug 2005 13:45:25 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C598E9.C690B5EC" Subject: LTANS WG Session Summary - IETF 63 - August 1, 2005, 16:30-18:00 Date: Thu, 4 Aug 2005 13:43:59 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B070010E375A@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS WG Session Summary - IETF 63 - August 1, 2005, 16:30-18:00 Thread-Index: AcWY6c3KwxZ2g8hiSGW3iTM6cQQRrQ== From: "Tobias Gondrom" To: Cc: , , 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_001_01C598E9.C690B5EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes of LTANS meeting August 1, 2005 16:30 - 18:00 (attendees: ~40) =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Action items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * update milestones * update reqs draft concerning comments from Denis and the meeting * proceed and finish ers-02 * proceed and refine ltap-00 * get input from community for notareqs-02 =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agenda Topics: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 Administrivia =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans.ppt) =20 * after decrese of speed of WG from 61st IETF, take up normal schedule again * revised milestones after IETF =20 =20 Short update on archive requirements (reqs-04)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-reqs.ppt) =20 =20 =20 Comments on Archive Requirements (reqs-04). =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/Comments_LTANS-reqs.ppt) =20 * idea of an attestation of deposit has been raised: a user (Client) should recieve a ticket (that might even be used for authorization) as an attestation for the deposition of the archived date.=20 * need to store meta data * Denis expressed the need to manage accounts for the LTAP -> this has been objected by several persons deferring the management of accounts to already existing mechanisms. =20 =20 Cryptographic Maintenance Policy =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTANS_crypto_maintenance_policy.ppt) =20 * encryption algorithms schould be stored to meta data, so that the server can react upon this information, e.g. send warnings when the used algorithms get insecure * Concerning Cryptography: the question has been rised wether encryption of data on the LTA makes any sense - as the encryption mechanisms will become insecure on the long run (5-30 years+) anyway. Denis made the point that he wants to be able to make the normal Systems Engineers (running the LTA) incapable to disclose or read information that is stored currently. Anyway he recognizes that data that might be stored today will be possibly decrypted in several years. Nonetheless the possibility to store encrypted data limits the possibilities for disclosure by the System Engineer working on the LTA. (and the confidentiality of the information might decrease in importance after several years, as data is generally aslo losing its value by time.) * Cryptographic Maintenance Policy will change with time - could be some kind of linked list as the future Maintenance Policies will not be known at the time of archiving as it is unknown at what time relevant cryptographic algorithms are becoming insecure and what new algorithms are developed in the future... * Stephan Santesson: is one of the goals to process signatures inside the archived data packets, e.g. signature verification? Clear answer from Denis and the editors: No. * Larry: we should also keep the application of the maintenance policies so flexible that we can also start a maintenance process when e.g. the certificates expire (simply by time not by broken algorithms) - e.g. introduce additional parameter =20 =20 Presentation of LTAP Protocol =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTAP.ppt) =20 * Peter made the point to make the Protocol as small as possible to make it easy to implement and roll-out even minimal implementetations -> defer account management to other technology * Larry: accounts don't live very long, most probably not as long as the documents are stored. * Denis, audience: suggestion to change the retriever to "public" e.g. after 5 years - so that expired accounts might not be a problem for access... * Shall the LTA certify that certain AC has been applied? * David Black: AC could also be role based * M.T: Carrasco: design a simple level of archive so that it can be implemented easily * Peter: LTAP design is an asynchronous protocol (message send, message received and message archived) - getting the asynchronous message "message archived" has been realized in LTAP by using the poll-mechanism so that no back cahnnel to the client has to be managed * also important is the mechanism to transfer data from one LTA to an other LTA and from one "policy space" to another, e.g. when a inspection is on the way and data must be kept until it is completed although the applied policy would no longer require that the data be kept or maintained. =20 =20 ltans-notareq-04, =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-notareqs-02.ppt) =20 * Larry & tobias: the draft is very slim and we urgently need input from the community about use case and real needs for the scenarios - otherwise we are unsure how to proceed =20 =20 Remarks: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Denis also referred to CAdES and the RFC3126 =20 =20 =20 Tobias, Chair of LTANS ------_=_NextPart_001_01C598E9.C690B5EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minutes of LTANS meeting

August 1, 2005 16:30 - = 18:00

(attendees: ~40)

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Action items

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

* update milestones

* update reqs draft concerning comments from Denis = and the meeting

* proceed and finish = ers-02

* proceed and refine = ltap-00

* get input from community for = notareqs-02

 

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Agenda Topics:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

Administrivia

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans.ppt)

 

* after decrese of speed of WG from 61st IETF, take = up normal schedule again

* revised milestones after = IETF

 

 

Short update on archive requirements (reqs-04) =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-reqs.ppt)

 

 

 

Comments on Archive Requirements (reqs-04).   

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/Comments_LTANS-reqs.ppt)<= /font>

 

* idea of an attestation of deposit has been = raised:

a user (Client) should recieve a ticket (that might = even be used for authorization) as an attestation for the deposition of the = archived date.

* need to store meta = data

* Denis expressed the need to manage accounts for the = LTAP

-> this has been objected by several persons = deferring the management of accounts to already existing = mechanisms.

 

 

Cryptographic Maintenance Policy           &= nbsp;   

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTANS_crypto_maintenance_policy.ppt)

 

* encryption algorithms schould be stored to meta = data, so that the server can react upon this information, e.g. send warnings when = the used algorithms get insecure

* Concerning = Cryptography:

the question has been rised wether encryption of data = on the LTA makes any sense - as the encryption mechanisms will become insecure = on the long run (5-30 years+) anyway.

Denis made the point that he wants to be able to make = the normal Systems Engineers (running the LTA) incapable to disclose or read information that is stored currently. Anyway he recognizes that data = that might be stored today will be possibly decrypted in several years. Nonetheless = the possibility to store encrypted data limits the possibilities for = disclosure by the System Engineer working on the LTA. (and the confidentiality of the information might decrease in importance after several years, as data is generally aslo losing its value by time.)

* Cryptographic Maintenance Policy will change with = time - could be some kind of linked list as the future Maintenance Policies = will not be known at the time of archiving as it is unknown at what time relevant cryptographic algorithms are becoming insecure and what new algorithms = are developed in the future...

* Stephan Santesson: is one of the goals to process signatures inside the archived data packets, e.g. signature = verification? Clear answer from Denis and the editors: No.

* Larry: we should also keep the application of the maintenance policies so flexible that we can also start a maintenance = process when e.g. the certificates expire (simply by time not by broken = algorithms) - e.g. introduce additional parameter

 

 

Presentation of LTAP Protocol           = ;      

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/LTAP.ppt)

 

* Peter made the point to make the Protocol as small = as possible to make it easy to implement and roll-out even minimal implementetations -> defer account management to other = technology

* Larry: accounts don't live very long, most probably = not as long as the documents are stored.

* Denis, audience: suggestion to change the retriever = to "public" e.g. after 5 years - so that expired accounts might = not be a problem for access...

* Shall the LTA certify that certain AC has been = applied?

* David Black: AC could also be role = based

* M.T: Carrasco: design a simple level of archive so = that it can be implemented easily

* Peter: LTAP design is an asynchronous protocol = (message send, message received and message archived) - getting the asynchronous = message "message archived" has been realized in LTAP by using the poll-mechanism so that no back cahnnel to the client has to be = managed

* also important is the mechanism to transfer data = from one LTA to an other LTA and from one "policy space" to another, = e.g. when a inspection is on the way and data must be kept until it is completed = although the applied policy would no longer require that the data be kept or = maintained.

 

 

ltans-notareq-04,      &= nbsp;           &n= bsp;            

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

(preliminary link until the minutes are released: www.gondrom.org/ietf/ltans/63/ltans-notareqs-02.ppt)

 

* Larry & tobias: the draft is very slim and we = urgently need input from the community about use case and real needs for the = scenarios - otherwise we are unsure how to proceed

 

 

Remarks:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Denis also referred to CAdES and the = RFC3126

 

 

 

Tobias, Chair of LTANS

------_=_NextPart_001_01C598E9.C690B5EC--