From tgondrom@gmx.net Mon Jul 12 12:00:31 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A823A6CCA for ; Mon, 12 Jul 2010 12:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX5O056Szf42 for ; Mon, 12 Jul 2010 12:00:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E94723A6C7C for ; Mon, 12 Jul 2010 12:00:26 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2010 19:00:33 -0000 Received: from 94-194-102-93.zone8.bethere.co.uk (EHLO [192.168.1.66]) [94.194.102.93] by mail.gmx.net (mp021) with SMTP; 12 Jul 2010 21:00:33 +0200 X-Authenticated: #1793214 X-Provags-ID: V01U2FsdGVkX1+zHdQhJPuzoXoLDjHHgZ8SuyEhaMNdftDmZ5z3CA JIxRIXMyHvHcZy Message-ID: <4C3B6651.7050404@gmx.net> Date: Mon, 12 Jul 2010 20:00:33 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ltans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [ltans] LTANS meeting: agenda items - proposals? X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 19:00:31 -0000 Hello dear fellow LTANS members, I am currently preparing the agenda for our meeting at the IETF-78 on Friday July-30 in Maastricht. If you have proposals or suggested topics for our meeting, please drop me an email until Wednesday July-14 15:00 GMT. Btw. as our latest drafts XMLERS has made good progress and will progress to LC soon, this will most probably be the last meeting of our WG before we can successfully shut it down. So any topics you want to raise for the agenda, please email me. Best regards and cu, Tobias (chair of LTANS) Tobias Gondrom Sloan Fellowship 2009 London Business School email: tobias.gondrom@gondrom.org mobile: +447521003005 From root@core3.amsl.com Mon Jul 12 15:00:01 2010 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 856F73A6885; Mon, 12 Jul 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712220001.856F73A6885@core3.amsl.com> Date: Mon, 12 Jul 2010 15:00:01 -0700 (PDT) Cc: ltans@ietf.org Subject: [ltans] I-D Action:draft-ietf-ltans-ari-01.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : LTANS Architecture Author(s) : T. Gondrom Filename : draft-ietf-ltans-ari-01.txt Pages : 10 Date : 2010-07-12 This document outlines best practices how to use and integrate components based on the various specifications prepared by the LTANS WG for long term archiving and non-repudiation services can work together in a best practices environment. It especially takes care of the overall architecture and integration of the protocol and the data structures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ari-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-ari-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12145535.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 12 15:15:03 2010 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C60B3A6B41; Mon, 12 Jul 2010 15:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712221503.2C60B3A6B41@core3.amsl.com> Date: Mon, 12 Jul 2010 15:15:02 -0700 (PDT) Cc: ltans@ietf.org Subject: [ltans] I-D Action:draft-ietf-ltans-validate-03.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 22:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Validation and long term verification data for Evidence Records and signed documents Author(s) : T. Gondrom Filename : draft-ietf-ltans-validate-03.txt Pages : 10 Date : 2010-07-12 Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ltans-validate-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12150416.I-D@ietf.org> --NextPart-- From tgondrom@gmx.net Thu Jul 15 07:22:57 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586393A69E9 for ; Thu, 15 Jul 2010 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd3o-B4rctPS for ; Thu, 15 Jul 2010 07:22:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 9CC443A69DD for ; Thu, 15 Jul 2010 07:22:55 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2010 14:23:04 -0000 Received: from 94-194-102-93.zone8.bethere.co.uk (EHLO [192.168.1.66]) [94.194.102.93] by mail.gmx.net (mp021) with SMTP; 15 Jul 2010 16:23:04 +0200 X-Authenticated: #1793214 X-Provags-ID: V01U2FsdGVkX184PZ8WR0I4fUqo4ly761n8LXR968+NRlTg3sWbrK EL8+n8m6SdmKb6 Message-ID: <4C3F19C7.8020503@gmx.net> Date: Thu, 15 Jul 2010 15:23:03 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ltans@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [ltans] LTANS WG agenda for Maastricht X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:22:57 -0000 Hello fellow LTANS members, below the proposed agenda for our meeting in Maastricht, if you like to change or add items, please let me know until Saturday (July-17, 24:00 GMT). http://www.ietf.org/proceedings/78/agenda/ltans.txt ------------------------------------------------------------------------- LTANS WG (ltans-wg) http://datatracker.ietf.org/wg/ltans/charter/ Friday, JULY 30, 2010 1300-1400, 0.4 Brussels ========================================================================= CHAIR: Tobias Gondrom , Carl Wallace AGENDA: 1. WG Status and Direction - Tobias - 5 Min 2. LTANS WG Specifications 2.1. XMLERS Status and topics - Aljosa - 30 Min draft-ietf-ltans-xmlers-06 2.2. ARI Status - Tobias - 5 Min draft-ietf-ltans-ari-01 2.3. validate - Tobias - 10 Min draft-ietf-ltans-validate-03 3. Closing of WG - open discussion - 10 Min The working group plans to close (with all docs close to a finish) and this is most probably the last, final meeting. If you have any items to discuss bring them forth now. Many greetings and looking forward to see you in Maastricht, Tobias (chair of LTANS) Tobias Gondrom Sloan Fellowship 2009 London Business School email: tobias.gondrom@gondrom.org mobile: +447521003005 From tobias.gondrom@gondrom.org Thu Jul 15 16:02:26 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A7F3A6B94 for ; Thu, 15 Jul 2010 16:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.619 X-Spam-Level: X-Spam-Status: No, score=-94.619 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe6OQ9j7wQte for ; Thu, 15 Jul 2010 16:02:25 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 6DD123A693F for ; Thu, 15 Jul 2010 16:02:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Q8ESnZAxf5LCxeqjk8I1jldORSOtYHJG9PQxz+bizD0hBcQBpNiBL5GAPzkVf8mFhyENREExcImiTax61BYrdVSI1gxPvT6plkwjp8WEKVc5phiPUm2xkHUehIVnP5R6; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 19599 invoked from network); 16 Jul 2010 01:01:59 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.66?) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jul 2010 01:01:59 +0200 Message-ID: <4C3F9367.1010901@gondrom.org> Date: Fri, 16 Jul 2010 00:01:59 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: ltans@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ltans] LTANS WG agenda for Maastricht X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 23:02:26 -0000 Hello fellow LTANS members, below the proposed agenda for our meeting in Maastricht, if you like to change or add items, please let me know until Saturday (July-17, 24:00 GMT). http://www.ietf.org/proceedings/78/agenda/ltans.txt ------------------------------------------------------------------------- LTANS WG (ltans-wg) http://datatracker.ietf.org/wg/ltans/charter/ Friday, JULY 30, 2010 1300-1400, 0.4 Brussels ========================================================================= CHAIR: Tobias Gondrom , Carl Wallace AGENDA: 1. WG Status and Direction - Tobias - 5 Min 2. LTANS WG Specifications 2.1. XMLERS Status and topics - Aljosa - 30 Min draft-ietf-ltans-xmlers-06 2.2. ARI Status - Tobias - 5 Min draft-ietf-ltans-ari-01 2.3. validate - Tobias - 10 Min draft-ietf-ltans-validate-03 3. Closing of WG - open discussion - 10 Min The working group plans to close (with all docs close to a finish) and this is most probably the last, final meeting. If you have any items to discuss bring them forth now. Many greetings and looking forward to see you in Maastricht, Tobias (chair of LTANS) Tobias Gondrom Sloan Fellowship 2009 London Business School email: tobias.gondrom@gondrom.org mobile: +447521003005 From aljosa@setcce.si Sun Jul 25 06:47:35 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E273A6967 for ; Sun, 25 Jul 2010 06:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz+KPZ3iRMpT for ; Sun, 25 Jul 2010 06:47:34 -0700 (PDT) Received: from setcce.si (mail.setcce.si [88.200.65.130]) by core3.amsl.com (Postfix) with ESMTP id B3AE13A6965 for ; Sun, 25 Jul 2010 06:47:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jul 2010 15:45:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] Fwd: Re: I-D ACTION:draft-ietf-ltans-xmlers-06.txt Thread-Index: AcsKVTSh4Jf3EUrLR5qnb5fR8UyIdwhpIzuw References: <4C13C490.8080103@gmx.net> From: "Aljosa Jerman Blazic" To: Subject: Re: [ltans] Fwd: Re: I-D ACTION:draft-ietf-ltans-xmlers-06.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 13:47:35 -0000 Tobias Answers are inline. =20 > -------- Original Message -------- > Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-06.txt > Date: Mon, 07 Jun 2010 19:06:38 +0100 > From: Tobias Gondrom > > To: ltans@ietf.org >=20 >=20 > Dear Aljosa, >=20 > thanks a lot for the great update version 06! > I sent a few more purely editorial comments to you directly and have > identified the following questions we should resolve on the mailing- > list as other might have them as well: >=20 > 1. Some more general questions about consistency of used terminology: > - There is some inconsistency in the spelling (start with capital or > small letter) of Evidence record? > Shall we use "Evidence Record" or "evidence record" > - same applies for Archive Time-Stamp/Archive Time Stamp/Archive > Timestamp > - same for in-sentence use of "type" and "Type" > > I have no preference, just think we should use consistent terms > throughout the draft. > In case you like, in RFC4998 when referring to a data structure we > started with the capital letter and otherwise we used timestamp / > evidence reocrd using the small letters. Maybe not the best solution > either. > As I said I have no personal preference for this. Thanks for the comment. > Questions: > 2. section 3.1.1. paragraph 2: > old: concatenated and a new hash value is generated from that string > (there is exception when the first list is having one hash value, then > this value is added to the next list). > new: concatenated and a new hash value is generated from that string. > There is an exception when the first list has only one hash value, in > which case this value is the root hash value). > comment: at least that's how I would understand it, otherwise it seems > to trigger an endless recursive circle. > The current wording seemed incorrect, but maybe I misunderstood s.th > here? One has to read the whole paragraph. "hashes of the first list are ordered in binary ascending order, concatenated and a new hash value is generated from that string (there is exception when the first list has one hash value, then this value is added to the next list). This hash value is added to the next list of hashes and the previous step is repeated. When there are no hash lists left, the last generated hash value is the root hash value..." The last sentence defines termination point of the process, i.e. when there are no hash lists left, then the last value generated is the root value (this way it is not possible to end up with endless recursive circle). If we change the wording as you have proposed then in case when the initial list has only a single value this automatically becomes the root value (to be time-stamped), which is incorrect. A list with a single value my become part of the next list which has several values and the process is repeated. Only when there are no (hash) values to order in a list then this value becomes the root value. For better understanding I suggest the following definition: "hashes of the first list are ordered in binary ascending order, concatenated and a new hash value is generated from that string (there is exception when the first list has one hash value, then this value is added to the next list). Newly generated hash value is added to the next list of hashes and the previous step is repeated until there is only one hash value left, i.e. when there are no hash lists left, the last generated hash value is the root hash value..." > 3. section 3.2. item #2 > Question: where is "canonicalization method C" defined or referenced??? I am not sure I understand this question. You may want to check the structure in section 2.1. Canonicalization Method is a child element of Archive time stamp chain and references to canonicalization method algorithm. > 4. section 3.3. item#4: > "If an archive object is having more data objects and the hash tree is > omitted, also exit with result." > Question: I am not sure why we have to exit in this case with (you > probably mean negative) result??? > Do we? And if yes, why? You are right. It should state "...also exit with negative result." This definition applies to the rule from section 3.1.1., which states: "When an archive object is composed of more than one data object, the first hash list MUST contain hash values of all its data objects." In case when archive object has more than one data object then hash tree HAS TO BE composed form hash values of each data object. In case ERS records fails to demonstrate this, then the result is negative. > 5. section 4.2.1 > Question about "the complete content of the last ATS MUST be time- > stamped" > Why is that? I thought only the old time-stamp has to be > protected/renewed with a new timestamp? > So we would not need to do this to the whole ATS structure.(btw. see > also RFC4998, section 5 does it only on the timestamp) Or do I > misunderstand s.th.? This is where XMLERS differs from ERS. Please pay attention to the XML structure proposed, which includes cryptographic information element used for collecting cryptomaterial related to the actual time stamp. Such material may come in a form as time stamp authority digital certificate, digital certificate revocation list, etc. When renewal occurs, cryptographic material has to be "protected" with the succeeding time stamp, hence the requirement to time-stamp the complete ATS. However, ATS may be empty, i.e. may include only time stamp token and in this case XMLERS performs analogue to the ERS syntax and processing rules. But IMO, this is wrong. Time-stamp renewal occurs for various reasons. The most common reason is revoked or expired digital certificate or decomposing time stamp authority, although hash algorithms used are still stable. ERS ASN.1 syntax fails to demonstrate that previous time stamp was valid at the time of time stamp renewal. It would need to collect cryptographic material of preceding time stamp separately and perform additional ERSing for cryptographic material collected. XMLERS simplifies this process by collecting cryptomaterial within the Archive Time-Stamp. The redundancy here is only hash tree which is re-time-stamped although hash algorithm is still stable. Hash tree element could still be moved out and put as child element to archive time stamp chain element... I am updating the draft now but will wait with publishing until the LTANS meeting. Regards Aljosa