From owner-ietf-ltans Wed May 11 23:33:45 2005
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 j4C6XjK3026327;
	Wed, 11 May 2005 23:33:45 -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 j4C6Xj4t026326;
	Wed, 11 May 2005 23:33:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from tcmail21.telekom.de (tcmail21.telekom.de [217.6.95.235])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C6Xh2Z026267
	for <ietf-ltans@imc.org>; Wed, 11 May 2005 23:33:44 -0700 (PDT)
	(envelope-from ErnstG.Giessmann@t-systems.com)
Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 12 May 2005 08:33:37 +0200
Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <KSAN30NF>; Thu, 12 May 2005 08:33:36 +0200
Message-Id: <7475C91E48FAC449A10440CE79B1A122012A5DAD@E9JDH.mgb01.telekom.de>
From: "Giessmann, Ernstg" <ErnstG.Giessmann@t-systems.com>
To: ietf-ltans@imc.org
Subject: AW: [ers-02.txt] Questions
Date: Thu, 12 May 2005 08:33:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C6Xj2Z026319
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


XAdES = XML Advanced Electronic Signatures
nothing about /extended/ is said in the name ;-)
/EG.

> -----Ursprüngliche Nachricht-----
> Von: owner-ietf-ltans@mail.imc.org
> [mailto:owner-ietf-ltans@mail.imc.org]Im Auftrag von A. Jerman Blazic
> Gesendet: Freitag, 29. April 2005 11:08
> An: 'HOUSSIER Loic RD-MAPS-ISS'; ietf-ltans@imc.org
> Betreff: RE: [ers-02.txt] Questions
> 
> Dear Loic
> 
> I would be very careful here. XAdES for example is like the name says:
> syntax for extended signature, which builds on top of a signature and
....


From owner-ietf-ltans Thu May 12 03:33:15 2005
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 j4CAXFCv022969;
	Thu, 12 May 2005 03:33:15 -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 j4CAXFnm022968;
	Thu, 12 May 2005 03:33:15 -0700 (PDT)
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.9) with SMTP id j4CAXEgk022949
	for <ietf-ltans@imc.org>; Thu, 12 May 2005 03:33:14 -0700 (PDT)
	(envelope-from aljosa@e5.ijs.si)
Message-Id: <200505121033.j4CAXEgk022949@above.proper.com>
Received: (qmail 29886 invoked from network); 12 May 2005 10:33:12 -0000
Received: from localhost (127.0.0.1)
  by e5.ijs.si with SMTP; 12 May 2005 10:33:12 -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 29751-05 for <ietf-ltans@imc.org>;
 Thu, 12 May 2005 12:33:10 +0200 (CEST)
Received: (qmail 29849 invoked from network); 12 May 2005 10:33:06 -0000
Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27)
  by e5.ijs.si with SMTP; 12 May 2005 10:33:06 -0000
From: "A. Jerman Blazic" <aljosa@e5.ijs.si>
To: <ietf-ltans@imc.org>
Subject: RE: [ers-02.txt] Questions
Date: Thu, 12 May 2005 12:39:46 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVWvdwEGCQdef87Qbm+R0xfRY4BkgAIOaTg
In-Reply-To: <7475C91E48FAC449A10440CE79B1A122012A5DAD@E9JDH.mgb01.telekom.de>
X-Virus-Scanned: amavisd-new at e5.ijs.si
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CAXFgk022962
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Technically, you are absolutely right but it has figurative meaning.....

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org 
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Giessmann, Ernstg
> Sent: 12. maj 2005 8:33
> To: ietf-ltans@imc.org
> Subject: AW: [ers-02.txt] Questions
> 
> 
> XAdES = XML Advanced Electronic Signatures nothing about 
> /extended/ is said in the name ;-) /EG.
> 
> > -----Ursprüngliche Nachricht-----
> > Von: owner-ietf-ltans@mail.imc.org
> > [mailto:owner-ietf-ltans@mail.imc.org]Im Auftrag von A. 
> Jerman Blazic
> > Gesendet: Freitag, 29. April 2005 11:08
> > An: 'HOUSSIER Loic RD-MAPS-ISS'; ietf-ltans@imc.org
> > Betreff: RE: [ers-02.txt] Questions
> > 
> > Dear Loic
> > 
> > I would be very careful here. XAdES for example is like the 
> name says:
> > syntax for extended signature, which builds on top of a 
> signature and
> ....
> 



From owner-ietf-ltans Thu May 12 08:24:10 2005
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 j4CFOAsR092372;
	Thu, 12 May 2005 08:24:10 -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 j4CFOAp8092371;
	Thu, 12 May 2005 08:24:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFO8m3092362
	for <ietf-ltans@imc.org>; Thu, 12 May 2005 08:24:09 -0700 (PDT)
	(envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40])
	by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA30340;
	Thu, 12 May 2005 17:38:55 +0200
Received: from bull.net ([129.182.108.120])
          by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10)
          with ESMTP id 2005051217235770:1164 ;
          Thu, 12 May 2005 17:23:57 +0200 
Message-ID: <42837547.7050406@bull.net>
Date: Thu, 12 May 2005 17:24:55 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tobias Gondrom <tgondrom@opentext.com>
CC: ietf-ltans@imc.org
Subject: Re: [ers-02.txt] Questions
References: <3C1BE8610E44734499EF92FB35F5B070CA4C8A@MUCXGC1.opentext.net>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at
 12/05/2005 17:23:57,
	Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at
 12/05/2005 17:23:59,
	Serialize complete at 12/05/2005 17:23:59
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CFOAm3092365
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Tobias,

Surety has a lot of patents that involve the use of hashtrees used together 
with time-stamp tokens.

Do you have any idea if the realisations you have in mind will fall into 
these patents or outside ?

Denis


> Loïc,
> 
> Maybe to provide further info:
> 
> 
>>Well, it's more clear to me now...
>>ERS just proposes a syntax for EV that can be used by CSM to kepp
>>electronic signature valid.
>>But according to RFC-3126, ES-A is a format that reech the same target
>>than ERS in CMS.
> 
> 
> Yes. In some way ES-A in RFC3126 is trying to achieve the same. 
> With ES-A you can try to "re-sign" a signed file with a new layer wrapped around it every time a cryptographic algorithm gets weak (respectively before) - the concept is quite obvious and well thought for the use case to store only a limited number of signed documents. 
> 
> As Aleksej already described ERS also enables the possibility for long-term non repudiation and integrity. 
> Second aspect of ERS is that it scales for large volumes of signed documents. With ES-A you have to wrap around every file another layer. 
> With ERS you just create new hashtrees - which is if you think of e.g. about 10^6 to 10^9 documents a lot better concerning performance. (especially if only e.g. a public key algorithm gets weak or a used key length is no longer sufficient.)
> 
> Concerning RFC3126: From my opinion it is not necessary that ERS will obsolete ES-A. But I surely expect that many big storage, Document Management System and ECM vendors will implement ERS and not ES-A. So in B2B and B2C we will most probably seeing a lot of ERS.
> 
> The coexistence of ES-A and ERS will be something to discuss when ERS is finally an RFC.
> 
> Best regards
> 
> 	Tobias
> 
> 
> 
> 
> 
> 
>>So my question is, if i want to archive signature, i have the choice
>>between RFC3126 ES-A or ERS in CMS. Am I right ?
>>
>>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
>>[ers-02])  ?
>>
>>But be sure that I understand ERS is more than just a way to maintain a
>>singature valid.
>>
>>Regards,
>>
>>Loïc
>>
>>
>>
>>
>>>-----Message d'origine-----
>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si]
>>>Envoyé : vendredi 29 avril 2005 11:48
>>>À : HOUSSIER Loic RD-MAPS-ISS; ietf-ltans@imc.org
>>>Objet : RE: [ers-02.txt] Questions
>>>
>>>Loic
>>>
>>>This is what I didn't state. You have to distinguish the
>>>level of the two
>>>approaches. ERS deals mainly with providing syntax on (time)
>>>evidence and
>>>evidence on integrity of a data, while RFC3126 provides data
>>>strucutre for
>>>long term validity of a digital signatures. In this case RFC
>>>can rely on ERS
>>>for time and integrity evidence of a signature, so it is a
>>>more low level
>>>syntax. Or in other words, if you equip CMS with accredited
>>>time, you can
>>>ged basic ERS structure (of course ERS is more than that:
>>>e.g. grouping and
>>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
>>>somehow different, while addressing similar problems.
>>>
>>>BR
>>>
>>>Aleksej
>>>
>>>
>>>>-----Original Message-----
>>>>From: HOUSSIER Loic RD-MAPS-ISS
>>>>[mailto:loic.houssier@francetelecom.com]
>>>>Sent: 29. april 2005 11:24
>>>>To: A. Jerman Blazic; ietf-ltans@imc.org
>>>>Subject: RE: [ers-02.txt] Questions
>>>>
>>>>Aleksej,
>>>>Thanks for your reply.
>>>>
>>>>So, to demonstrate the existantce and stability of signature
>>>>on particular, there will be two ways in PKIX community:
>>>>One using rfc3126, one with ERS attribute within a CMS
>>>>signature object. Am I wrong ?
>>>>
>>>>Loïc
>>>>
>>>>
>>>>
>>>>
>>>>>-----Message d'origine-----
>>>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si] Envoyé :
>>>>
>>>>vendredi 29
>>>>
>>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
>>>>
>>>ietf-ltans@imc.org
>>>
>>>>>Objet : RE: [ers-02.txt] Questions
>>>>>
>>>>>Dear Loic
>>>>>
>>>>>I would be very careful here. XAdES for example is like the
>>>>
>>>>name says:
>>>>
>>>>>syntax for extended signature, which builds on top of a
>>>>
>>>>signature and
>>>>
>>>>>includes all needed complementary data to provide long term
>>>>
>>>>stability
>>>>
>>>>>of digital signatures. The LTANS position, as I understand it,
>>>>>distances from such approach and deals with long term
>>>>
>>>stability of
>>>
>>>>>data. ERS in this case defines requirements on how to
>>>>
>>>>demonstrate the
>>>>
>>>>>existence and stability of data (not signature on
>>>>
>>>particular) on a
>>>
>>>>>timeline. It does not define the data structure nor the
>>>>
>>>>syntax and at
>>>>
>>>>>the moment you can freely use any interpretation of an
>>>>
>>>>evidence record
>>>>
>>>>>including CMS. But XAdES? I am not so sure....
>>>>>
>>>>>Best regards
>>>>>
>>>>>Aleksej
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: owner-ietf-ltans@mail.imc.org
>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
>>>>>
>>>HOUSSIER Loic
>>>
>>>>>>RD-MAPS-ISS
>>>>>>Sent: 29. april 2005 10:46
>>>>>>To: ietf-ltans@imc.org
>>>>>>Subject: [ers-02.txt] Questions
>>>>>>
>>>>>>
>>>>>>Hi all,
>>>>>>
>>>>>>Reading ERS_02, I have question :
>>>>>>It s said that ER can be part of the Archive or can be
>>>>>
>>>stored as
>>>
>>>>>>another file. What I understand is that we can (using CMS
>>>>>
>>>>or XADES)
>>>>
>>>>>>do ER as part of the Archive.
>>>>>>But Is it compliant with ERS ?
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>Loïc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Message d'origine-----
>>>>>>>De : owner-ietf-ltans@mail.imc.org
>>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] De la part de
>>>>>>>Internet-Drafts@ietf.org Envoyé : vendredi 8 avril 2005
>>>>>>
>>>>21:29 À :
>>>>
>>>>>>>i-d-announce@ietf.org Cc : ietf-ltans@imc.org Objet : I-D
>>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
>>>>>>>
>>>>>>>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		: Evidence Record Syntax (ERS)
>>>>>>>	Author(s)	: R. Brandner, et al.
>>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
>>>>>>>	Pages		: 25
>>>>>>>	Date		: 2005-4-8
>>>>>>>
>>>>>>>In many scenarios, users need to be able to ensure and
>>>>>>
>>>>prove the
>>>>
>>>>>>>   existence and integrity of data, especially digitally
>>>>>>
>>>>>>signed data,
>>>>>>
>>>>>>>in
>>>>>>>   a common and reproducible way over a long and possibly
>>>>>>
>>>>>>undetermined
>>>>>>
>>>>>>>   period of time.  This document specifies the syntax and
>>>>>>
>>>>>>processing
>>>>>>
>>>>>>>of
>>>>>>>   an Evidence Record, designed for long-term
>>>>>>
>>>>non-repudiation of
>>>>
>>>>>>>   existence of data, which particularly can be used for
>>>>>>
>>>>>>conservation
>>>>>>
>>>>>>>of
>>>>>>>   evidence of digitally signed data.
>>>>>>>
>>>>>>>A URL for this Internet-Draft is:
>>>>>>>
>>>>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
>>>
>>>>>>>To remove yourself from the I-D Announcement list, send a
>>>>>>
>>>>>>message to
>>>>>>
>>>>>>>i-d-announce-request@ietf.org with the word unsubscribe in
>>>>>>
>>>>>>the body of
>>>>>>
>>>>>>>the message.
>>>>>>>You can also visit
>>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>>>>>to change your subscription settings.
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts are also available by anonymous FTP.
>>>>>>
>>>>>Login with the
>>>>>
>>>>>>>username "anonymous" and a password of your e-mail
>>>>>>
>>>>address. After
>>>>
>>>>>>>logging in, type "cd internet-drafts" and then
>>>>>>>	"get draft-ietf-ltans-ers-02.txt".
>>>>>>>
>>>>>>>A list of Internet-Drafts directories can be found in
>>>>>>>http://www.ietf.org/shadow.html or
>>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts can also be obtained by e-mail.
>>>>>>>
>>>>>>>Send a message to:
>>>>>>>	mailserv@ietf.org.
>>>>>>>In the body type:
>>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.txt".
>>>>>>>
>>>>>>>NOTE:	The mail server at ietf.org can return the document in
>>>>>>>	MIME-encoded form by using the "mpack" utility.
>>>>>>
>>>> To use this
>>>>
>>>>>>>	feature, insert the command "ENCODING mime"
>>>>>>
>>>>before the "FILE"
>>>>
>>>>>>>	command.  To decode the response(s), you will
>>>>>>
>>>>need "munpack" or
>>>>
>>>>>>>	a MIME-compliant mail reader.  Different MIME-compliant
>>>>>>
>>>>>>mail readers
>>>>>>
>>>>>>>	exhibit different behavior, especially when dealing with
>>>>>>>	"multipart" MIME messages (i.e. documents which
>>>>>>
>>>>have been split
>>>>
>>>>>>>	up into multiple messages), so check your local
>>>>>>
>>>>documentation on
>>>>
>>>>>>>	how to manipulate these messages.
>>>>>>>
>>>>>>>
>>>>>>>Below is the data which will enable a MIME compliant
>>>>>>
>>>>mail reader
>>>>
>>>>>>>implementation to automatically retrieve the ASCII
>>>>>>
>>>>version of the
>>>>
>>>>>>>Internet-Draft.
>>>>>>>
>>>>>>
>>>>>
>>>
> 
> 




From owner-ietf-ltans Fri May 20 08:44:43 2005
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 j4KFihx2094532;
	Fri, 20 May 2005 08:44:43 -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 j4KFihI7094531;
	Fri, 20 May 2005 08:44:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KFigNs094523
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 08:44:43 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (static-70-21-127-143.res.east.verizon.net [70.21.127.143])
	by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4KFifeN029513
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 11:44:41 -0400
Message-Id: <200505201544.j4KFifeN029513@host15.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Subject: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 11:44:36 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0041_01C55D31.4F4E7650"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnA==
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Below are some questions and comments on the -02 draft of ERS.

Administrative
	- EVS in section 1.1, section 1.2 should be ERS
	- EV should be ER in "EV as file format" and "EV as part of another
syntax specification".
	- ETS in section 1.2 should be ERS
	- "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
	- "Trusted archiving" is not referenced in the body of the
specification.  Suggest removing it from the Terminology section.  Same
applies to "archived data object group" and "trusted archive authority".
	- In section 2.1, remove comma from "contains data, necessary".
	- In section 2.1, change "if necessary" to "as necessary" or "when
necessary" in bullet 3.
	- In section 3, change "to verify" to "verification of".
	- In section 3.1, change "not existent" to "not present, "
	- In section 3.1, change "identically" to "identical"
	- Throughout section 4, change "first Initial" to "first
ArchiveTimeStamp in the first ArchiveTimeStampChain".
	- In section 4.1, change "must be ordered" to "MUST be ordered"
	- Suggest renaming ArchiveTimeStampSequence to
ArchiveTimeStampChainSequence
	- In section 4.2, "ASN.1 encoded" to "DER encoded".
	- In figure 4 and associated text, h123, h12 and h2abc should be
h123', h12' and h2abc'.
	- In 5.2, update the CMS reference and omit requirement for RSA
algorithm.
	- Section 5.2 requires encrypted data to be encapsulated but
Appendix A permits detached data.
	- id-ATS is not defined in the ASN.1 module.
	- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

Non-administrative
	- In section 2.1, how would a partial document be archived, i.e. how
can the structures be used to archive the "essential parts" of a document?
	- The verification algorithm needs a sorting step before
concatenation (section 3.3, bullet 3).  
	- In 4.1, why must all ArchiveTimestamps in an ArchiveTimestampChain
use the same hash algorithm?  Seems like this should refer to the algorithm
used within the hash tree not the hash algorithm used for the timestamp.
	- For timestamp renewal, why not obtain a timestamp for the entire
previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
reduced hashtree and timestamp) instead of the timestamp field only?  This
would simplify processing (and would facilitate covering verification data -
see below).  Also, it's not clear in the current text if the entire
ContentInfo is timestamped or the content field of the timestamp object (in
section 4.2).
	- In section 4.2, bullet 3, is the hash calculated over a
concatenation or over the encoded ArchiveTimeStampChainSequence?  	
	- In Appendix A, given a detached set of signatures, what
constitutes the first signature?  
	- In Appendix A, why define two OIDs for the attribute?  One could
do with context determining how the attribute is processed.
	- Appendix A should also account for ContentWithAttributes structure
(see RFC4073).  This may be the cleanest way to associate an EvidenceRecord
attribute with any type of CMS object and avoid the need to strip out
attributes and reencode at verification time.
	- Suggest pushing cryptoInfos down a level.  This would allow
cryptoInfos to be protected by subsequent timestamps.  
	- Need to define some cryptoInfo types.
	- Suggest adding SIZE (1.MAX)  to each SEQUENCE OF in the
reducedHashtree definition.  Also on Chain object definitions.



------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>draft-ietf-ltans-ers-02 comments</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Below are some questions and comments =
on the -02 draft of ERS.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EVS in section 1.1, section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EV should be ER in &quot;EV as file format&quot; and =
&quot;EV as part of another syntax specification&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- ETS in section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Reduce hash-tree&quot; should be &quot;Reduced =
hash-tree&quot; in Terminology</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Trusted archiving&quot; is not referenced in the =
body of the specification.&nbsp; Suggest removing it from the =
Terminology section.&nbsp; Same applies to &quot;archived data object =
group&quot; and &quot;trusted archive authority&quot;.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, remove comma from &quot;contains data, =
necessary&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, change &quot;if necessary&quot; to =
&quot;as necessary&quot; or &quot;when necessary&quot; in bullet =
3.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3, change &quot;to verify&quot; to =
&quot;verification of&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;not existent&quot; to =
&quot;not present, &quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;identically&quot; to =
&quot;identical&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Throughout section 4, change &quot;first Initial&quot; =
to &quot;first ArchiveTimeStamp in the first =
ArchiveTimeStampChain&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.1, change &quot;must be ordered&quot; to =
&quot;MUST be ordered&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest renaming ArchiveTimeStampSequence to =
ArchiveTimeStampChainSequence</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, &quot;ASN.1 encoded&quot; to &quot;DER =
encoded&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In figure 4 and associated text, h123, h12 and h2abc =
should be h123', h12' and h2abc'.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 5.2, update the CMS reference and omit requirement =
for RSA algorithm.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Section 5.2 requires encrypted data to be encapsulated =
but Appendix A permits detached data.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- id-ATS is not defined in the ASN.1 module.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, =
h1}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Non-administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, how would a partial document be =
archived, i.e. how can the structures be used to archive the =
&quot;essential parts&quot; of a document?</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- The verification algorithm needs a sorting step before =
concatenation (section 3.3, bullet 3).&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 4.1, why must all ArchiveTimestamps in an =
ArchiveTimestampChain use the same hash algorithm?&nbsp; Seems like this =
should refer to the algorithm used within the hash tree not the hash =
algorithm used for the timestamp.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- For timestamp renewal, why not obtain a timestamp for =
the entire previous ArchiveTimeStamp (i.e. complete sequence including =
hash alg, reduced hashtree and timestamp) instead of the timestamp field =
only?&nbsp; This would simplify processing (and would facilitate =
covering verification data - see below).&nbsp; Also, it's not clear in =
the current text if the entire ContentInfo is timestamped or the content =
field of the timestamp object (in section 4.2).</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, bullet 3, is the hash calculated over a =
concatenation or over the encoded ArchiveTimeStampChainSequence?&nbsp; =
&nbsp;&nbsp;&nbsp; </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, given a detached set of signatures, what =
constitutes the first signature?&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, why define two OIDs for the =
attribute?&nbsp; One could do with context determining how the attribute =
is processed.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Appendix A should also account for =
ContentWithAttributes structure (see RFC4073).&nbsp; This may be the =
cleanest way to associate an EvidenceRecord attribute with any type of =
CMS object and avoid the need to strip out attributes and reencode at =
verification time.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest pushing cryptoInfos down a level.&nbsp; This =
would allow cryptoInfos to be protected by subsequent timestamps.&nbsp; =
</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Need to define some cryptoInfo types.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest adding SIZE (1&#8230;MAX)&nbsp; to each =
SEQUENCE OF in the reducedHashtree definition.&nbsp; Also on Chain =
object definitions.</FONT></P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0041_01C55D31.4F4E7650--


From owner-ietf-ltans Fri May 20 09:07:03 2005
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 j4KG73s2000228;
	Fri, 20 May 2005 09:07:03 -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 j4KG734p000227;
	Fri, 20 May 2005 09:07:03 -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 j4KG6xt1000212
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 09:07:00 -0700 (PDT)
	(envelope-from tgondrom@opentext.com)
Received: from samxg01.opentext.net (localhost [127.0.0.1])
	by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j4KG6mvQ017850;
	Fri, 20 May 2005 18:06:49 +0200 (MEST)
Received: from MUCXGC1.opentext.net ([149.235.128.14]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 20 May 2005 09:06:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [ers-02.txt] Questions
Date: Fri, 20 May 2005 18:06:57 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B070D8EE8C@MUCXGC1.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ers-02.txt] Questions
Thread-Index: AcVXB7lNceF47njRQo2vb+SVO3BKMgGTe69g
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: <ietf-ltans@imc.org>
X-OriginalArrivalTime: 20 May 2005 16:06:47.0702 (UTC) FILETIME=[ECD6A360:01C55D55]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KG70t1000213
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Denis, 

Carl and I clarify with the AD (Russ) about the correct procedure whether we need do detailed research on patents or not and how to proceed.

Tobias


> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Thursday, May 12, 2005 5:25 PM
> To: Tobias Gondrom
> Cc: ietf-ltans@imc.org
> Subject: Re: [ers-02.txt] Questions
> 
> Tobias,
> 
> Surety has a lot of patents that involve the use of hashtrees used
> together
> with time-stamp tokens.
> 
> Do you have any idea if the realisations you have in mind will fall into
> these patents or outside ?
> 
> Denis
> 
> 
> > Loïc,
> >
> > Maybe to provide further info:
> >
> >
> >>Well, it's more clear to me now...
> >>ERS just proposes a syntax for EV that can be used by CSM to kepp
> >>electronic signature valid.
> >>But according to RFC-3126, ES-A is a format that reech the same target
> >>than ERS in CMS.
> >
> >
> > Yes. In some way ES-A in RFC3126 is trying to achieve the same.
> > With ES-A you can try to "re-sign" a signed file with a new layer
> wrapped around it every time a cryptographic algorithm gets weak
> (respectively before) - the concept is quite obvious and well thought for
> the use case to store only a limited number of signed documents.
> >
> > As Aleksej already described ERS also enables the possibility for long-
> term non repudiation and integrity.
> > Second aspect of ERS is that it scales for large volumes of signed
> documents. With ES-A you have to wrap around every file another layer.
> > With ERS you just create new hashtrees - which is if you think of e.g.
> about 10^6 to 10^9 documents a lot better concerning performance.
> (especially if only e.g. a public key algorithm gets weak or a used key
> length is no longer sufficient.)
> >
> > Concerning RFC3126: From my opinion it is not necessary that ERS will
> obsolete ES-A. But I surely expect that many big storage, Document
> Management System and ECM vendors will implement ERS and not ES-A. So in
> B2B and B2C we will most probably seeing a lot of ERS.
> >
> > The coexistence of ES-A and ERS will be something to discuss when ERS is
> finally an RFC.
> >
> > Best regards
> >
> > 	Tobias
> >
> >
> >
> >
> >
> >
> >>So my question is, if i want to archive signature, i have the choice
> >>between RFC3126 ES-A or ERS in CMS. Am I right ?
> >>
> >>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
> >>[ers-02])  ?
> >>
> >>But be sure that I understand ERS is more than just a way to maintain a
> >>singature valid.
> >>
> >>Regards,
> >>
> >>Loïc
> >>
> >>
> >>
> >>
> >>>-----Message d'origine-----
> >>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si]
> >>>Envoyé : vendredi 29 avril 2005 11:48
> >>>À : HOUSSIER Loic RD-MAPS-ISS; ietf-ltans@imc.org
> >>>Objet : RE: [ers-02.txt] Questions
> >>>
> >>>Loic
> >>>
> >>>This is what I didn't state. You have to distinguish the
> >>>level of the two
> >>>approaches. ERS deals mainly with providing syntax on (time)
> >>>evidence and
> >>>evidence on integrity of a data, while RFC3126 provides data
> >>>strucutre for
> >>>long term validity of a digital signatures. In this case RFC
> >>>can rely on ERS
> >>>for time and integrity evidence of a signature, so it is a
> >>>more low level
> >>>syntax. Or in other words, if you equip CMS with accredited
> >>>time, you can
> >>>ged basic ERS structure (of course ERS is more than that:
> >>>e.g. grouping and
> >>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
> >>>somehow different, while addressing similar problems.
> >>>
> >>>BR
> >>>
> >>>Aleksej
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: HOUSSIER Loic RD-MAPS-ISS
> >>>>[mailto:loic.houssier@francetelecom.com]
> >>>>Sent: 29. april 2005 11:24
> >>>>To: A. Jerman Blazic; ietf-ltans@imc.org
> >>>>Subject: RE: [ers-02.txt] Questions
> >>>>
> >>>>Aleksej,
> >>>>Thanks for your reply.
> >>>>
> >>>>So, to demonstrate the existantce and stability of signature
> >>>>on particular, there will be two ways in PKIX community:
> >>>>One using rfc3126, one with ERS attribute within a CMS
> >>>>signature object. Am I wrong ?
> >>>>
> >>>>Loïc
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Message d'origine-----
> >>>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si] Envoyé :
> >>>>
> >>>>vendredi 29
> >>>>
> >>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
> >>>>
> >>>ietf-ltans@imc.org
> >>>
> >>>>>Objet : RE: [ers-02.txt] Questions
> >>>>>
> >>>>>Dear Loic
> >>>>>
> >>>>>I would be very careful here. XAdES for example is like the
> >>>>
> >>>>name says:
> >>>>
> >>>>>syntax for extended signature, which builds on top of a
> >>>>
> >>>>signature and
> >>>>
> >>>>>includes all needed complementary data to provide long term
> >>>>
> >>>>stability
> >>>>
> >>>>>of digital signatures. The LTANS position, as I understand it,
> >>>>>distances from such approach and deals with long term
> >>>>
> >>>stability of
> >>>
> >>>>>data. ERS in this case defines requirements on how to
> >>>>
> >>>>demonstrate the
> >>>>
> >>>>>existence and stability of data (not signature on
> >>>>
> >>>particular) on a
> >>>
> >>>>>timeline. It does not define the data structure nor the
> >>>>
> >>>>syntax and at
> >>>>
> >>>>>the moment you can freely use any interpretation of an
> >>>>
> >>>>evidence record
> >>>>
> >>>>>including CMS. But XAdES? I am not so sure....
> >>>>>
> >>>>>Best regards
> >>>>>
> >>>>>Aleksej
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: owner-ietf-ltans@mail.imc.org
> >>>>>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
> >>>>>
> >>>HOUSSIER Loic
> >>>
> >>>>>>RD-MAPS-ISS
> >>>>>>Sent: 29. april 2005 10:46
> >>>>>>To: ietf-ltans@imc.org
> >>>>>>Subject: [ers-02.txt] Questions
> >>>>>>
> >>>>>>
> >>>>>>Hi all,
> >>>>>>
> >>>>>>Reading ERS_02, I have question :
> >>>>>>It s said that ER can be part of the Archive or can be
> >>>>>
> >>>stored as
> >>>
> >>>>>>another file. What I understand is that we can (using CMS
> >>>>>
> >>>>or XADES)
> >>>>
> >>>>>>do ER as part of the Archive.
> >>>>>>But Is it compliant with ERS ?
> >>>>>>
> >>>>>>Thanks
> >>>>>>
> >>>>>>Loïc
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>-----Message d'origine-----
> >>>>>>>De : owner-ietf-ltans@mail.imc.org
> >>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] De la part de
> >>>>>>>Internet-Drafts@ietf.org Envoyé : vendredi 8 avril 2005
> >>>>>>
> >>>>21:29 À :
> >>>>
> >>>>>>>i-d-announce@ietf.org Cc : ietf-ltans@imc.org Objet : I-D
> >>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
> >>>>>>>
> >>>>>>>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		: Evidence Record Syntax (ERS)
> >>>>>>>	Author(s)	: R. Brandner, et al.
> >>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
> >>>>>>>	Pages		: 25
> >>>>>>>	Date		: 2005-4-8
> >>>>>>>
> >>>>>>>In many scenarios, users need to be able to ensure and
> >>>>>>
> >>>>prove the
> >>>>
> >>>>>>>   existence and integrity of data, especially digitally
> >>>>>>
> >>>>>>signed data,
> >>>>>>
> >>>>>>>in
> >>>>>>>   a common and reproducible way over a long and possibly
> >>>>>>
> >>>>>>undetermined
> >>>>>>
> >>>>>>>   period of time.  This document specifies the syntax and
> >>>>>>
> >>>>>>processing
> >>>>>>
> >>>>>>>of
> >>>>>>>   an Evidence Record, designed for long-term
> >>>>>>
> >>>>non-repudiation of
> >>>>
> >>>>>>>   existence of data, which particularly can be used for
> >>>>>>
> >>>>>>conservation
> >>>>>>
> >>>>>>>of
> >>>>>>>   evidence of digitally signed data.
> >>>>>>>
> >>>>>>>A URL for this Internet-Draft is:
> >>>>>>>
> >>>>>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
> >>>
> >>>>>>>To remove yourself from the I-D Announcement list, send a
> >>>>>>
> >>>>>>message to
> >>>>>>
> >>>>>>>i-d-announce-request@ietf.org with the word unsubscribe in
> >>>>>>
> >>>>>>the body of
> >>>>>>
> >>>>>>>the message.
> >>>>>>>You can also visit
> >>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>>>>>>to change your subscription settings.
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts are also available by anonymous FTP.
> >>>>>>
> >>>>>Login with the
> >>>>>
> >>>>>>>username "anonymous" and a password of your e-mail
> >>>>>>
> >>>>address. After
> >>>>
> >>>>>>>logging in, type "cd internet-drafts" and then
> >>>>>>>	"get draft-ietf-ltans-ers-02.txt".
> >>>>>>>
> >>>>>>>A list of Internet-Drafts directories can be found in
> >>>>>>>http://www.ietf.org/shadow.html or
> >>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts can also be obtained by e-mail.
> >>>>>>>
> >>>>>>>Send a message to:
> >>>>>>>	mailserv@ietf.org.
> >>>>>>>In the body type:
> >>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.txt".
> >>>>>>>
> >>>>>>>NOTE:	The mail server at ietf.org can return the document in
> >>>>>>>	MIME-encoded form by using the "mpack" utility.
> >>>>>>
> >>>> To use this
> >>>>
> >>>>>>>	feature, insert the command "ENCODING mime"
> >>>>>>
> >>>>before the "FILE"
> >>>>
> >>>>>>>	command.  To decode the response(s), you will
> >>>>>>
> >>>>need "munpack" or
> >>>>
> >>>>>>>	a MIME-compliant mail reader.  Different MIME-compliant
> >>>>>>
> >>>>>>mail readers
> >>>>>>
> >>>>>>>	exhibit different behavior, especially when dealing with
> >>>>>>>	"multipart" MIME messages (i.e. documents which
> >>>>>>
> >>>>have been split
> >>>>
> >>>>>>>	up into multiple messages), so check your local
> >>>>>>
> >>>>documentation on
> >>>>
> >>>>>>>	how to manipulate these messages.
> >>>>>>>
> >>>>>>>
> >>>>>>>Below is the data which will enable a MIME compliant
> >>>>>>
> >>>>mail reader
> >>>>
> >>>>>>>implementation to automatically retrieve the ASCII
> >>>>>>
> >>>>version of the
> >>>>
> >>>>>>>Internet-Draft.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
> >
> 



From owner-ietf-ltans Fri May 20 10:54:14 2005
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 j4KHsEXi021223;
	Fri, 20 May 2005 10:54:14 -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 j4KHsEMd021222;
	Fri, 20 May 2005 10:54:14 -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 j4KHsCgV021215
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 10:54:13 -0700 (PDT)
	(envelope-from tgondrom@opentext.com)
Received: from samxg01.opentext.net (localhost [127.0.0.1])
	by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j4KHs93L020747
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 19:54:10 +0200 (MEST)
Received: from MUCXGC1.opentext.net ([149.235.128.14]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.211);
	 Fri, 20 May 2005 10:54:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 19:54:18 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B070D8EEAA@MUCXGC1.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-ers-02 comments
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnAADOL2QAABnh5A=
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: <ietf-ltans@imc.org>
X-OriginalArrivalTime: 20 May 2005 17:54:09.0004 (UTC) FILETIME=[EC2752C0:01C55D64]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHsDgV021217
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Carl, 
fully agree to all formal aspects!
Further comments below:

> Below are some questions and comments on the -02 draft of ERS.
> Administrative
>         - EVS in section 1.1, section 1.2 should be ERS
>         - EV should be ER in "EV as file format" and "EV as part of
> another syntax specification".
>         - ETS in section 1.2 should be ERS
>         - "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
>         - "Trusted archiving" is not referenced in the body of the
> specification.  Suggest removing it from the Terminology section.  Same
> applies to "archived data object group" and "trusted archive authority".
>         - In section 2.1, remove comma from "contains data, necessary".
>         - In section 2.1, change "if necessary" to "as necessary" or "when
> necessary" in bullet 3.
>         - In section 3, change "to verify" to "verification of".
>         - In section 3.1, change "not existent" to "not present, "
>         - In section 3.1, change "identically" to "identical"
>         - Throughout section 4, change "first Initial" to "first
> ArchiveTimeStamp in the first ArchiveTimeStampChain".
>         - In section 4.1, change "must be ordered" to "MUST be ordered"
>         - Suggest renaming ArchiveTimeStampSequence to
> ArchiveTimeStampChainSequence
>         - In section 4.2, "ASN.1 encoded" to "DER encoded".
>         - In figure 4 and associated text, h123, h12 and h2abc should be
> h123', h12' and h2abc'.
>         - In 5.2, update the CMS reference and omit requirement for RSA
> algorithm.
>         - Section 5.2 requires encrypted data to be encapsulated but
> Appendix A permits detached data.
>         - id-ATS is not defined in the ASN.1 module.
>         - In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

As above: I agree.

> Non-administrative
>         - In section 2.1, how would a partial document be archived, i.e.
> how can the structures be used to archive the "essential parts" of a
> document?

I am not sure why we need partial documents? Where do they come from?

>         - The verification algorithm needs a sorting step before
> concatenation (section 3.3, bullet 3).

You are right we need the same sorting as when building the hash-tree: 
"in binary ascending order" refer to top of page 9
" 2. Select all hash values, which have the same father node as h. 
      Generate the first list of hash values by arranging these hashes,
      in binary ascending order. Repeat this step for the father node
      of these hashes until the root hash is reached. The father nodes
      are not saved in the hash lists - they are computable."



>         - In 4.1, why must all ArchiveTimestamps in an
> ArchiveTimestampChain use the same hash algorithm?  Seems like this should
> refer to the algorithm used within the hash tree not the hash algorithm
> used for the timestamp.

The problem is that an ArchiveTimeStampChain is only a Sequence of ArchiveTimeStamps due to the fact of simple timestamp renewals, i.e. the timestamps have lost their value, but the has-algorith of the hash-trees of the Archivetimestamps is still valid.
If the hash-algorithm of the trees is broken (more precisely "before") you have to open a new ArchiveTimeStampChain with hash-values calculated with the new algorithm as the seed. See section 4.2

>         - For timestamp renewal, why not obtain a timestamp for the entire
> previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
> reduced hashtree and timestamp) instead of the timestamp field only?  This
> would simplify processing (and would facilitate covering verification data
> - see below).  Also, it's not clear in the current text if the entire
> ContentInfo is timestamped or the content field of the timestamp object
> (in section 4.2).

The timestamp (containing the hash-value of the highest node) does represent the complete hash-tree and is with this fully sufficient - so one can spare additional operations.

>         - In section 4.2, bullet 3, is the hash calculated over a
> concatenation or over the encoded ArchiveTimeStampChainSequence?

You are right this is unclear: I will come up with a proposal for the precise solution in the next few days.


>         - In Appendix A, given a detached set of signatures, what
> constitutes the first signature?
>         - In Appendix A, why define two OIDs for the attribute?  One could
> do with context determining how the attribute is processed.
>         - Appendix A should also account for ContentWithAttributes
> structure (see RFC4073).  This may be the cleanest way to associate an
> EvidenceRecord attribute with any type of CMS object and avoid the need to
> strip out attributes and reencode at verification time.
>         - Suggest pushing cryptoInfos down a level.  This would allow
> cryptoInfos to be protected by subsequent timestamps.
>         - Need to define some cryptoInfo types.
>         - Suggest adding SIZE (1...MAX)  to each SEQUENCE OF in the
> reducedHashtree definition.  Also on Chain object definitions.

No comment at this time - I hope the authors can also comment on that.


From owner-ietf-ltans Fri May 20 12:49:02 2005
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 j4KJn2eq050146;
	Fri, 20 May 2005 12:49:02 -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 j4KJn20a050145;
	Fri, 20 May 2005 12:49:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJmv7g050104
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 12:49:01 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (pool-70-18-254-93.res.east.verizon.net [70.18.254.93])
	by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4KJmuxO029963
	for <ietf-ltans@imc.org>; Fri, 20 May 2005 15:48:56 -0400
Message-Id: <200505201948.j4KJmuxO029963@host15.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 15:48:56 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnAADOL2QAABnh5AABCaeMA==
In-Reply-To: <3C1BE8610E44734499EF92FB35F5B070D8EEAA@MUCXGC1.opentext.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KJn17g050140
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


> >         - Throughout section 4, change "first Initial" to "first 
> > ArchiveTimeStamp in the first ArchiveTimeStampChain".

This change makes no sense as a literal replacement.  I just found the term
"first Initial" difficult and intended to suggest replacing instances of
"first Initial Archive Time-Stamps".  

> > Non-administrative
> >         - In section 2.1, how would a partial document be 
> archived, i.e.
> > how can the structures be used to archive the "essential 
> parts" of a 
> > document?
> 
> I am not sure why we need partial documents? Where do they come from?

Perhaps the "essential parts" clause should simply be deleted.
 
> >         - The verification algorithm needs a sorting step before 
> > concatenation (section 3.3, bullet 3).
> 
> You are right we need the same sorting as when building the 
> hash-tree: 
> "in binary ascending order" refer to top of page 9 " 2. 
> Select all hash values, which have the same father node as h. 
>       Generate the first list of hash values by arranging 
> these hashes,
>       in binary ascending order. Repeat this step for the father node
>       of these hashes until the root hash is reached. The father nodes
>       are not saved in the hash lists - they are computable."
> 

Right.  However, bullet 3 would benefit from a statement of this, in my
opinion.

> 
> >         - In 4.1, why must all ArchiveTimestamps in an 
> > ArchiveTimestampChain use the same hash algorithm?  Seems like this 
> > should refer to the algorithm used within the hash tree not 
> the hash 
> > algorithm used for the timestamp.
> 
> The problem is that an ArchiveTimeStampChain is only a 
> Sequence of ArchiveTimeStamps due to the fact of simple 
> timestamp renewals, i.e. the timestamps have lost their 
> value, but the has-algorith of the hash-trees of the 
> Archivetimestamps is still valid.
> If the hash-algorithm of the trees is broken (more precisely 
> "before") you have to open a new ArchiveTimeStampChain with 
> hash-values calculated with the new algorithm as the seed. 
> See section 4.2

Exactly.  So why must all ArchiveTimestamps within an ArchiveTimestampChain
use the same hash algorithm?  The hash algorithms could vary in an
ArchiveTimestampChain as long as the hash used for the hash tree doesn't
change, which would result in a new ArchiveTimestampChain featuring a
recalculated hash tree using a new hash algorithm.
 
> >         - For timestamp renewal, why not obtain a timestamp for the 
> > entire previous ArchiveTimeStamp (i.e. complete sequence including 
> > hash alg, reduced hashtree and timestamp) instead of the timestamp 
> > field only?  This would simplify processing (and would facilitate 
> > covering verification data
> > - see below).  Also, it's not clear in the current text if 
> the entire 
> > ContentInfo is timestamped or the content field of the timestamp 
> > object (in section 4.2).
> 
> The timestamp (containing the hash-value of the highest node) 
> does represent the complete hash-tree and is with this fully 
> sufficient - so one can spare additional operations.

Renewal can't target the entire ArchiveTimestamp due to the inclusion of the
reduction.  I withdraw the question regarding targeting ArchiveTimestamp.
Still not clear whether timestamp or timestamp.content is timestamped at
renewal time.
 
> >         - Suggest pushing cryptoInfos down a level.  This 
> would allow 
> > cryptoInfos to be protected by subsequent timestamps.

This suggestion is OBE, given that ArchiveTimestamp can't be the target.
The cert bag and unsigned attributes of the timestamp could serve to hold
additional information.




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 j4KJn2eq050146; Fri, 20 May 2005 12:49:02 -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 j4KJn20a050145; Fri, 20 May 2005 12:49:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJmv7g050104 for <ietf-ltans@imc.org>; Fri, 20 May 2005 12:49:01 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (pool-70-18-254-93.res.east.verizon.net [70.18.254.93]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4KJmuxO029963 for <ietf-ltans@imc.org>; Fri, 20 May 2005 15:48:56 -0400
Message-Id: <200505201948.j4KJmuxO029963@host15.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 15:48:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnAADOL2QAABnh5AABCaeMA==
In-Reply-To: <3C1BE8610E44734499EF92FB35F5B070D8EEAA@MUCXGC1.opentext.net>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KJn17g050140
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

> >         - Throughout section 4, change "first Initial" to "first 
> > ArchiveTimeStamp in the first ArchiveTimeStampChain".

This change makes no sense as a literal replacement.  I just found the term
"first Initial" difficult and intended to suggest replacing instances of
"first Initial Archive Time-Stamps".  

> > Non-administrative
> >         - In section 2.1, how would a partial document be 
> archived, i.e.
> > how can the structures be used to archive the "essential 
> parts" of a 
> > document?
> 
> I am not sure why we need partial documents? Where do they come from?

Perhaps the "essential parts" clause should simply be deleted.
 
> >         - The verification algorithm needs a sorting step before 
> > concatenation (section 3.3, bullet 3).
> 
> You are right we need the same sorting as when building the 
> hash-tree: 
> "in binary ascending order" refer to top of page 9 " 2. 
> Select all hash values, which have the same father node as h. 
>       Generate the first list of hash values by arranging 
> these hashes,
>       in binary ascending order. Repeat this step for the father node
>       of these hashes until the root hash is reached. The father nodes
>       are not saved in the hash lists - they are computable."
> 

Right.  However, bullet 3 would benefit from a statement of this, in my
opinion.

> 
> >         - In 4.1, why must all ArchiveTimestamps in an 
> > ArchiveTimestampChain use the same hash algorithm?  Seems like this 
> > should refer to the algorithm used within the hash tree not 
> the hash 
> > algorithm used for the timestamp.
> 
> The problem is that an ArchiveTimeStampChain is only a 
> Sequence of ArchiveTimeStamps due to the fact of simple 
> timestamp renewals, i.e. the timestamps have lost their 
> value, but the has-algorith of the hash-trees of the 
> Archivetimestamps is still valid.
> If the hash-algorithm of the trees is broken (more precisely 
> "before") you have to open a new ArchiveTimeStampChain with 
> hash-values calculated with the new algorithm as the seed. 
> See section 4.2

Exactly.  So why must all ArchiveTimestamps within an ArchiveTimestampChain
use the same hash algorithm?  The hash algorithms could vary in an
ArchiveTimestampChain as long as the hash used for the hash tree doesn't
change, which would result in a new ArchiveTimestampChain featuring a
recalculated hash tree using a new hash algorithm.
 
> >         - For timestamp renewal, why not obtain a timestamp for the 
> > entire previous ArchiveTimeStamp (i.e. complete sequence including 
> > hash alg, reduced hashtree and timestamp) instead of the timestamp 
> > field only?  This would simplify processing (and would facilitate 
> > covering verification data
> > - see below).  Also, it's not clear in the current text if 
> the entire 
> > ContentInfo is timestamped or the content field of the timestamp 
> > object (in section 4.2).
> 
> The timestamp (containing the hash-value of the highest node) 
> does represent the complete hash-tree and is with this fully 
> sufficient - so one can spare additional operations.

Renewal can't target the entire ArchiveTimestamp due to the inclusion of the
reduction.  I withdraw the question regarding targeting ArchiveTimestamp.
Still not clear whether timestamp or timestamp.content is timestamped at
renewal time.
 
> >         - Suggest pushing cryptoInfos down a level.  This 
> would allow 
> > cryptoInfos to be protected by subsequent timestamps.

This suggestion is OBE, given that ArchiveTimestamp can't be the target.
The cert bag and unsigned attributes of the timestamp could serve to hold
additional information.




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 j4KHsEXi021223; Fri, 20 May 2005 10:54:14 -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 j4KHsEMd021222; Fri, 20 May 2005 10:54:14 -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 j4KHsCgV021215 for <ietf-ltans@imc.org>; Fri, 20 May 2005 10:54:13 -0700 (PDT) (envelope-from tgondrom@opentext.com)
Received: from samxg01.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j4KHs93L020747 for <ietf-ltans@imc.org>; Fri, 20 May 2005 19:54:10 +0200 (MEST)
Received: from MUCXGC1.opentext.net ([149.235.128.14]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 10:54:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 19:54:18 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B070D8EEAA@MUCXGC1.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-ltans-ers-02 comments
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnAADOL2QAABnh5A=
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: <ietf-ltans@imc.org>
X-OriginalArrivalTime: 20 May 2005 17:54:09.0004 (UTC) FILETIME=[EC2752C0:01C55D64]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHsDgV021217
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Carl, 
fully agree to all formal aspects!
Further comments below:

> Below are some questions and comments on the -02 draft of ERS.
> Administrative
>         - EVS in section 1.1, section 1.2 should be ERS
>         - EV should be ER in "EV as file format" and "EV as part of
> another syntax specification".
>         - ETS in section 1.2 should be ERS
>         - "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
>         - "Trusted archiving" is not referenced in the body of the
> specification.  Suggest removing it from the Terminology section.  Same
> applies to "archived data object group" and "trusted archive authority".
>         - In section 2.1, remove comma from "contains data, necessary".
>         - In section 2.1, change "if necessary" to "as necessary" or "when
> necessary" in bullet 3.
>         - In section 3, change "to verify" to "verification of".
>         - In section 3.1, change "not existent" to "not present, "
>         - In section 3.1, change "identically" to "identical"
>         - Throughout section 4, change "first Initial" to "first
> ArchiveTimeStamp in the first ArchiveTimeStampChain".
>         - In section 4.1, change "must be ordered" to "MUST be ordered"
>         - Suggest renaming ArchiveTimeStampSequence to
> ArchiveTimeStampChainSequence
>         - In section 4.2, "ASN.1 encoded" to "DER encoded".
>         - In figure 4 and associated text, h123, h12 and h2abc should be
> h123', h12' and h2abc'.
>         - In 5.2, update the CMS reference and omit requirement for RSA
> algorithm.
>         - Section 5.2 requires encrypted data to be encapsulated but
> Appendix A permits detached data.
>         - id-ATS is not defined in the ASN.1 module.
>         - In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

As above: I agree.

> Non-administrative
>         - In section 2.1, how would a partial document be archived, i.e.
> how can the structures be used to archive the "essential parts" of a
> document?

I am not sure why we need partial documents? Where do they come from?

>         - The verification algorithm needs a sorting step before
> concatenation (section 3.3, bullet 3).

You are right we need the same sorting as when building the hash-tree: 
"in binary ascending order" refer to top of page 9
" 2. Select all hash values, which have the same father node as h. 
      Generate the first list of hash values by arranging these hashes,
      in binary ascending order. Repeat this step for the father node
      of these hashes until the root hash is reached. The father nodes
      are not saved in the hash lists - they are computable."



>         - In 4.1, why must all ArchiveTimestamps in an
> ArchiveTimestampChain use the same hash algorithm?  Seems like this should
> refer to the algorithm used within the hash tree not the hash algorithm
> used for the timestamp.

The problem is that an ArchiveTimeStampChain is only a Sequence of ArchiveTimeStamps due to the fact of simple timestamp renewals, i.e. the timestamps have lost their value, but the has-algorith of the hash-trees of the Archivetimestamps is still valid.
If the hash-algorithm of the trees is broken (more precisely "before") you have to open a new ArchiveTimeStampChain with hash-values calculated with the new algorithm as the seed. See section 4.2

>         - For timestamp renewal, why not obtain a timestamp for the entire
> previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
> reduced hashtree and timestamp) instead of the timestamp field only?  This
> would simplify processing (and would facilitate covering verification data
> - see below).  Also, it's not clear in the current text if the entire
> ContentInfo is timestamped or the content field of the timestamp object
> (in section 4.2).

The timestamp (containing the hash-value of the highest node) does represent the complete hash-tree and is with this fully sufficient - so one can spare additional operations.

>         - In section 4.2, bullet 3, is the hash calculated over a
> concatenation or over the encoded ArchiveTimeStampChainSequence?

You are right this is unclear: I will come up with a proposal for the precise solution in the next few days.


>         - In Appendix A, given a detached set of signatures, what
> constitutes the first signature?
>         - In Appendix A, why define two OIDs for the attribute?  One could
> do with context determining how the attribute is processed.
>         - Appendix A should also account for ContentWithAttributes
> structure (see RFC4073).  This may be the cleanest way to associate an
> EvidenceRecord attribute with any type of CMS object and avoid the need to
> strip out attributes and reencode at verification time.
>         - Suggest pushing cryptoInfos down a level.  This would allow
> cryptoInfos to be protected by subsequent timestamps.
>         - Need to define some cryptoInfo types.
>         - Suggest adding SIZE (1...MAX)  to each SEQUENCE OF in the
> reducedHashtree definition.  Also on Chain object definitions.

No comment at this time - I hope the authors can also comment on that.



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 j4KG73s2000228; Fri, 20 May 2005 09:07:03 -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 j4KG734p000227; Fri, 20 May 2005 09:07:03 -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 j4KG6xt1000212 for <ietf-ltans@imc.org>; Fri, 20 May 2005 09:07:00 -0700 (PDT) (envelope-from tgondrom@opentext.com)
Received: from samxg01.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j4KG6mvQ017850; Fri, 20 May 2005 18:06:49 +0200 (MEST)
Received: from MUCXGC1.opentext.net ([149.235.128.14]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 May 2005 09:06:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [ers-02.txt] Questions
Date: Fri, 20 May 2005 18:06:57 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B070D8EE8C@MUCXGC1.opentext.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ers-02.txt] Questions
Thread-Index: AcVXB7lNceF47njRQo2vb+SVO3BKMgGTe69g
X-Priority: 5
Importance: low
From: "Tobias Gondrom" <tgondrom@opentext.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>
Cc: <ietf-ltans@imc.org>
X-OriginalArrivalTime: 20 May 2005 16:06:47.0702 (UTC) FILETIME=[ECD6A360:01C55D55]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KG70t1000213
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Denis, 

Carl and I clarify with the AD (Russ) about the correct procedure whether we need do detailed research on patents or not and how to proceed.

Tobias


> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Thursday, May 12, 2005 5:25 PM
> To: Tobias Gondrom
> Cc: ietf-ltans@imc.org
> Subject: Re: [ers-02.txt] Questions
> 
> Tobias,
> 
> Surety has a lot of patents that involve the use of hashtrees used
> together
> with time-stamp tokens.
> 
> Do you have any idea if the realisations you have in mind will fall into
> these patents or outside ?
> 
> Denis
> 
> 
> > Loïc,
> >
> > Maybe to provide further info:
> >
> >
> >>Well, it's more clear to me now...
> >>ERS just proposes a syntax for EV that can be used by CSM to kepp
> >>electronic signature valid.
> >>But according to RFC-3126, ES-A is a format that reech the same target
> >>than ERS in CMS.
> >
> >
> > Yes. In some way ES-A in RFC3126 is trying to achieve the same.
> > With ES-A you can try to "re-sign" a signed file with a new layer
> wrapped around it every time a cryptographic algorithm gets weak
> (respectively before) - the concept is quite obvious and well thought for
> the use case to store only a limited number of signed documents.
> >
> > As Aleksej already described ERS also enables the possibility for long-
> term non repudiation and integrity.
> > Second aspect of ERS is that it scales for large volumes of signed
> documents. With ES-A you have to wrap around every file another layer.
> > With ERS you just create new hashtrees - which is if you think of e.g.
> about 10^6 to 10^9 documents a lot better concerning performance.
> (especially if only e.g. a public key algorithm gets weak or a used key
> length is no longer sufficient.)
> >
> > Concerning RFC3126: From my opinion it is not necessary that ERS will
> obsolete ES-A. But I surely expect that many big storage, Document
> Management System and ECM vendors will implement ERS and not ES-A. So in
> B2B and B2C we will most probably seeing a lot of ERS.
> >
> > The coexistence of ES-A and ERS will be something to discuss when ERS is
> finally an RFC.
> >
> > Best regards
> >
> > 	Tobias
> >
> >
> >
> >
> >
> >
> >>So my question is, if i want to archive signature, i have the choice
> >>between RFC3126 ES-A or ERS in CMS. Am I right ?
> >>
> >>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
> >>[ers-02])  ?
> >>
> >>But be sure that I understand ERS is more than just a way to maintain a
> >>singature valid.
> >>
> >>Regards,
> >>
> >>Loïc
> >>
> >>
> >>
> >>
> >>>-----Message d'origine-----
> >>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si]
> >>>Envoyé : vendredi 29 avril 2005 11:48
> >>>À : HOUSSIER Loic RD-MAPS-ISS; ietf-ltans@imc.org
> >>>Objet : RE: [ers-02.txt] Questions
> >>>
> >>>Loic
> >>>
> >>>This is what I didn't state. You have to distinguish the
> >>>level of the two
> >>>approaches. ERS deals mainly with providing syntax on (time)
> >>>evidence and
> >>>evidence on integrity of a data, while RFC3126 provides data
> >>>strucutre for
> >>>long term validity of a digital signatures. In this case RFC
> >>>can rely on ERS
> >>>for time and integrity evidence of a signature, so it is a
> >>>more low level
> >>>syntax. Or in other words, if you equip CMS with accredited
> >>>time, you can
> >>>ged basic ERS structure (of course ERS is more than that:
> >>>e.g. grouping and
> >>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
> >>>somehow different, while addressing similar problems.
> >>>
> >>>BR
> >>>
> >>>Aleksej
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: HOUSSIER Loic RD-MAPS-ISS
> >>>>[mailto:loic.houssier@francetelecom.com]
> >>>>Sent: 29. april 2005 11:24
> >>>>To: A. Jerman Blazic; ietf-ltans@imc.org
> >>>>Subject: RE: [ers-02.txt] Questions
> >>>>
> >>>>Aleksej,
> >>>>Thanks for your reply.
> >>>>
> >>>>So, to demonstrate the existantce and stability of signature
> >>>>on particular, there will be two ways in PKIX community:
> >>>>One using rfc3126, one with ERS attribute within a CMS
> >>>>signature object. Am I wrong ?
> >>>>
> >>>>Loïc
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Message d'origine-----
> >>>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si] Envoyé :
> >>>>
> >>>>vendredi 29
> >>>>
> >>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
> >>>>
> >>>ietf-ltans@imc.org
> >>>
> >>>>>Objet : RE: [ers-02.txt] Questions
> >>>>>
> >>>>>Dear Loic
> >>>>>
> >>>>>I would be very careful here. XAdES for example is like the
> >>>>
> >>>>name says:
> >>>>
> >>>>>syntax for extended signature, which builds on top of a
> >>>>
> >>>>signature and
> >>>>
> >>>>>includes all needed complementary data to provide long term
> >>>>
> >>>>stability
> >>>>
> >>>>>of digital signatures. The LTANS position, as I understand it,
> >>>>>distances from such approach and deals with long term
> >>>>
> >>>stability of
> >>>
> >>>>>data. ERS in this case defines requirements on how to
> >>>>
> >>>>demonstrate the
> >>>>
> >>>>>existence and stability of data (not signature on
> >>>>
> >>>particular) on a
> >>>
> >>>>>timeline. It does not define the data structure nor the
> >>>>
> >>>>syntax and at
> >>>>
> >>>>>the moment you can freely use any interpretation of an
> >>>>
> >>>>evidence record
> >>>>
> >>>>>including CMS. But XAdES? I am not so sure....
> >>>>>
> >>>>>Best regards
> >>>>>
> >>>>>Aleksej
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: owner-ietf-ltans@mail.imc.org
> >>>>>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
> >>>>>
> >>>HOUSSIER Loic
> >>>
> >>>>>>RD-MAPS-ISS
> >>>>>>Sent: 29. april 2005 10:46
> >>>>>>To: ietf-ltans@imc.org
> >>>>>>Subject: [ers-02.txt] Questions
> >>>>>>
> >>>>>>
> >>>>>>Hi all,
> >>>>>>
> >>>>>>Reading ERS_02, I have question :
> >>>>>>It s said that ER can be part of the Archive or can be
> >>>>>
> >>>stored as
> >>>
> >>>>>>another file. What I understand is that we can (using CMS
> >>>>>
> >>>>or XADES)
> >>>>
> >>>>>>do ER as part of the Archive.
> >>>>>>But Is it compliant with ERS ?
> >>>>>>
> >>>>>>Thanks
> >>>>>>
> >>>>>>Loïc
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>-----Message d'origine-----
> >>>>>>>De : owner-ietf-ltans@mail.imc.org
> >>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] De la part de
> >>>>>>>Internet-Drafts@ietf.org Envoyé : vendredi 8 avril 2005
> >>>>>>
> >>>>21:29 À :
> >>>>
> >>>>>>>i-d-announce@ietf.org Cc : ietf-ltans@imc.org Objet : I-D
> >>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
> >>>>>>>
> >>>>>>>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		: Evidence Record Syntax (ERS)
> >>>>>>>	Author(s)	: R. Brandner, et al.
> >>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
> >>>>>>>	Pages		: 25
> >>>>>>>	Date		: 2005-4-8
> >>>>>>>
> >>>>>>>In many scenarios, users need to be able to ensure and
> >>>>>>
> >>>>prove the
> >>>>
> >>>>>>>   existence and integrity of data, especially digitally
> >>>>>>
> >>>>>>signed data,
> >>>>>>
> >>>>>>>in
> >>>>>>>   a common and reproducible way over a long and possibly
> >>>>>>
> >>>>>>undetermined
> >>>>>>
> >>>>>>>   period of time.  This document specifies the syntax and
> >>>>>>
> >>>>>>processing
> >>>>>>
> >>>>>>>of
> >>>>>>>   an Evidence Record, designed for long-term
> >>>>>>
> >>>>non-repudiation of
> >>>>
> >>>>>>>   existence of data, which particularly can be used for
> >>>>>>
> >>>>>>conservation
> >>>>>>
> >>>>>>>of
> >>>>>>>   evidence of digitally signed data.
> >>>>>>>
> >>>>>>>A URL for this Internet-Draft is:
> >>>>>>>
> >>>>>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
> >>>
> >>>>>>>To remove yourself from the I-D Announcement list, send a
> >>>>>>
> >>>>>>message to
> >>>>>>
> >>>>>>>i-d-announce-request@ietf.org with the word unsubscribe in
> >>>>>>
> >>>>>>the body of
> >>>>>>
> >>>>>>>the message.
> >>>>>>>You can also visit
> >>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>>>>>>to change your subscription settings.
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts are also available by anonymous FTP.
> >>>>>>
> >>>>>Login with the
> >>>>>
> >>>>>>>username "anonymous" and a password of your e-mail
> >>>>>>
> >>>>address. After
> >>>>
> >>>>>>>logging in, type "cd internet-drafts" and then
> >>>>>>>	"get draft-ietf-ltans-ers-02.txt".
> >>>>>>>
> >>>>>>>A list of Internet-Drafts directories can be found in
> >>>>>>>http://www.ietf.org/shadow.html or
> >>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>>>
> >>>>>>>
> >>>>>>>Internet-Drafts can also be obtained by e-mail.
> >>>>>>>
> >>>>>>>Send a message to:
> >>>>>>>	mailserv@ietf.org.
> >>>>>>>In the body type:
> >>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.txt".
> >>>>>>>
> >>>>>>>NOTE:	The mail server at ietf.org can return the document in
> >>>>>>>	MIME-encoded form by using the "mpack" utility.
> >>>>>>
> >>>> To use this
> >>>>
> >>>>>>>	feature, insert the command "ENCODING mime"
> >>>>>>
> >>>>before the "FILE"
> >>>>
> >>>>>>>	command.  To decode the response(s), you will
> >>>>>>
> >>>>need "munpack" or
> >>>>
> >>>>>>>	a MIME-compliant mail reader.  Different MIME-compliant
> >>>>>>
> >>>>>>mail readers
> >>>>>>
> >>>>>>>	exhibit different behavior, especially when dealing with
> >>>>>>>	"multipart" MIME messages (i.e. documents which
> >>>>>>
> >>>>have been split
> >>>>
> >>>>>>>	up into multiple messages), so check your local
> >>>>>>
> >>>>documentation on
> >>>>
> >>>>>>>	how to manipulate these messages.
> >>>>>>>
> >>>>>>>
> >>>>>>>Below is the data which will enable a MIME compliant
> >>>>>>
> >>>>mail reader
> >>>>
> >>>>>>>implementation to automatically retrieve the ASCII
> >>>>>>
> >>>>version of the
> >>>>
> >>>>>>>Internet-Draft.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >
> >
> 




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 j4KFihx2094532; Fri, 20 May 2005 08:44:43 -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 j4KFihI7094531; Fri, 20 May 2005 08:44:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KFigNs094523 for <ietf-ltans@imc.org>; Fri, 20 May 2005 08:44:43 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (static-70-21-127-143.res.east.verizon.net [70.21.127.143]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4KFifeN029513 for <ietf-ltans@imc.org>; Fri, 20 May 2005 11:44:41 -0400
Message-Id: <200505201544.j4KFifeN029513@host15.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: <ietf-ltans@imc.org>
Subject: draft-ietf-ltans-ers-02 comments
Date: Fri, 20 May 2005 11:44:36 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C55D31.4F4E7650"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVdUtMJJ1iEXL3qRz+EVwGnVkrmnA==
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Below are some questions and comments on the -02 draft of ERS.

Administrative
	- EVS in section 1.1, section 1.2 should be ERS
	- EV should be ER in "EV as file format" and "EV as part of another
syntax specification".
	- ETS in section 1.2 should be ERS
	- "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
	- "Trusted archiving" is not referenced in the body of the
specification.  Suggest removing it from the Terminology section.  Same
applies to "archived data object group" and "trusted archive authority".
	- In section 2.1, remove comma from "contains data, necessary".
	- In section 2.1, change "if necessary" to "as necessary" or "when
necessary" in bullet 3.
	- In section 3, change "to verify" to "verification of".
	- In section 3.1, change "not existent" to "not present, "
	- In section 3.1, change "identically" to "identical"
	- Throughout section 4, change "first Initial" to "first
ArchiveTimeStamp in the first ArchiveTimeStampChain".
	- In section 4.1, change "must be ordered" to "MUST be ordered"
	- Suggest renaming ArchiveTimeStampSequence to
ArchiveTimeStampChainSequence
	- In section 4.2, "ASN.1 encoded" to "DER encoded".
	- In figure 4 and associated text, h123, h12 and h2abc should be
h123', h12' and h2abc'.
	- In 5.2, update the CMS reference and omit requirement for RSA
algorithm.
	- Section 5.2 requires encrypted data to be encapsulated but
Appendix A permits detached data.
	- id-ATS is not defined in the ASN.1 module.
	- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

Non-administrative
	- In section 2.1, how would a partial document be archived, i.e. how
can the structures be used to archive the "essential parts" of a document?
	- The verification algorithm needs a sorting step before
concatenation (section 3.3, bullet 3).  
	- In 4.1, why must all ArchiveTimestamps in an ArchiveTimestampChain
use the same hash algorithm?  Seems like this should refer to the algorithm
used within the hash tree not the hash algorithm used for the timestamp.
	- For timestamp renewal, why not obtain a timestamp for the entire
previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
reduced hashtree and timestamp) instead of the timestamp field only?  This
would simplify processing (and would facilitate covering verification data -
see below).  Also, it's not clear in the current text if the entire
ContentInfo is timestamped or the content field of the timestamp object (in
section 4.2).
	- In section 4.2, bullet 3, is the hash calculated over a
concatenation or over the encoded ArchiveTimeStampChainSequence?  	
	- In Appendix A, given a detached set of signatures, what
constitutes the first signature?  
	- In Appendix A, why define two OIDs for the attribute?  One could
do with context determining how the attribute is processed.
	- Appendix A should also account for ContentWithAttributes structure
(see RFC4073).  This may be the cleanest way to associate an EvidenceRecord
attribute with any type of CMS object and avoid the need to strip out
attributes and reencode at verification time.
	- Suggest pushing cryptoInfos down a level.  This would allow
cryptoInfos to be protected by subsequent timestamps.  
	- Need to define some cryptoInfo types.
	- Suggest adding SIZE (1.MAX)  to each SEQUENCE OF in the
reducedHashtree definition.  Also on Chain object definitions.



------=_NextPart_000_0041_01C55D31.4F4E7650
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>draft-ietf-ltans-ers-02 comments</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Below are some questions and comments =
on the -02 draft of ERS.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EVS in section 1.1, section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- EV should be ER in &quot;EV as file format&quot; and =
&quot;EV as part of another syntax specification&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- ETS in section 1.2 should be ERS</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Reduce hash-tree&quot; should be &quot;Reduced =
hash-tree&quot; in Terminology</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- &quot;Trusted archiving&quot; is not referenced in the =
body of the specification.&nbsp; Suggest removing it from the =
Terminology section.&nbsp; Same applies to &quot;archived data object =
group&quot; and &quot;trusted archive authority&quot;.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, remove comma from &quot;contains data, =
necessary&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, change &quot;if necessary&quot; to =
&quot;as necessary&quot; or &quot;when necessary&quot; in bullet =
3.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3, change &quot;to verify&quot; to =
&quot;verification of&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;not existent&quot; to =
&quot;not present, &quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.1, change &quot;identically&quot; to =
&quot;identical&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Throughout section 4, change &quot;first Initial&quot; =
to &quot;first ArchiveTimeStamp in the first =
ArchiveTimeStampChain&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.1, change &quot;must be ordered&quot; to =
&quot;MUST be ordered&quot;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest renaming ArchiveTimeStampSequence to =
ArchiveTimeStampChainSequence</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, &quot;ASN.1 encoded&quot; to &quot;DER =
encoded&quot;.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In figure 4 and associated text, h123, h12 and h2abc =
should be h123', h12' and h2abc'.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 5.2, update the CMS reference and omit requirement =
for RSA algorithm.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Section 5.2 requires encrypted data to be encapsulated =
but Appendix A permits detached data.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- id-ATS is not defined in the ASN.1 module.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, =
h1}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Non-administrative</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 2.1, how would a partial document be =
archived, i.e. how can the structures be used to archive the =
&quot;essential parts&quot; of a document?</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- The verification algorithm needs a sorting step before =
concatenation (section 3.3, bullet 3).&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In 4.1, why must all ArchiveTimestamps in an =
ArchiveTimestampChain use the same hash algorithm?&nbsp; Seems like this =
should refer to the algorithm used within the hash tree not the hash =
algorithm used for the timestamp.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- For timestamp renewal, why not obtain a timestamp for =
the entire previous ArchiveTimeStamp (i.e. complete sequence including =
hash alg, reduced hashtree and timestamp) instead of the timestamp field =
only?&nbsp; This would simplify processing (and would facilitate =
covering verification data - see below).&nbsp; Also, it's not clear in =
the current text if the entire ContentInfo is timestamped or the content =
field of the timestamp object (in section 4.2).</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In section 4.2, bullet 3, is the hash calculated over a =
concatenation or over the encoded ArchiveTimeStampChainSequence?&nbsp; =
&nbsp;&nbsp;&nbsp; </FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, given a detached set of signatures, what =
constitutes the first signature?&nbsp; </FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- In Appendix A, why define two OIDs for the =
attribute?&nbsp; One could do with context determining how the attribute =
is processed.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Appendix A should also account for =
ContentWithAttributes structure (see RFC4073).&nbsp; This may be the =
cleanest way to associate an EvidenceRecord attribute with any type of =
CMS object and avoid the need to strip out attributes and reencode at =
verification time.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest pushing cryptoInfos down a level.&nbsp; This =
would allow cryptoInfos to be protected by subsequent timestamps.&nbsp; =
</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Need to define some cryptoInfo types.</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">- Suggest adding SIZE (1&#8230;MAX)&nbsp; to each =
SEQUENCE OF in the reducedHashtree definition.&nbsp; Also on Chain =
object definitions.</FONT></P>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0041_01C55D31.4F4E7650--



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 j4CFOAsR092372; Thu, 12 May 2005 08:24:10 -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 j4CFOAp8092371; Thu, 12 May 2005 08:24:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFO8m3092362 for <ietf-ltans@imc.org>; Thu, 12 May 2005 08:24:09 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA30340; Thu, 12 May 2005 17:38:55 +0200
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051217235770:1164 ; Thu, 12 May 2005 17:23:57 +0200 
Message-ID: <42837547.7050406@bull.net>
Date: Thu, 12 May 2005 17:24:55 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tobias Gondrom <tgondrom@opentext.com>
CC: ietf-ltans@imc.org
Subject: Re: [ers-02.txt] Questions
References: <3C1BE8610E44734499EF92FB35F5B070CA4C8A@MUCXGC1.opentext.net>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 17:23:57, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 17:23:59, Serialize complete at 12/05/2005 17:23:59
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CFOAm3092365
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Tobias,

Surety has a lot of patents that involve the use of hashtrees used together 
with time-stamp tokens.

Do you have any idea if the realisations you have in mind will fall into 
these patents or outside ?

Denis


> Loïc,
> 
> Maybe to provide further info:
> 
> 
>>Well, it's more clear to me now...
>>ERS just proposes a syntax for EV that can be used by CSM to kepp
>>electronic signature valid.
>>But according to RFC-3126, ES-A is a format that reech the same target
>>than ERS in CMS.
> 
> 
> Yes. In some way ES-A in RFC3126 is trying to achieve the same. 
> With ES-A you can try to "re-sign" a signed file with a new layer wrapped around it every time a cryptographic algorithm gets weak (respectively before) - the concept is quite obvious and well thought for the use case to store only a limited number of signed documents. 
> 
> As Aleksej already described ERS also enables the possibility for long-term non repudiation and integrity. 
> Second aspect of ERS is that it scales for large volumes of signed documents. With ES-A you have to wrap around every file another layer. 
> With ERS you just create new hashtrees - which is if you think of e.g. about 10^6 to 10^9 documents a lot better concerning performance. (especially if only e.g. a public key algorithm gets weak or a used key length is no longer sufficient.)
> 
> Concerning RFC3126: From my opinion it is not necessary that ERS will obsolete ES-A. But I surely expect that many big storage, Document Management System and ECM vendors will implement ERS and not ES-A. So in B2B and B2C we will most probably seeing a lot of ERS.
> 
> The coexistence of ES-A and ERS will be something to discuss when ERS is finally an RFC.
> 
> Best regards
> 
> 	Tobias
> 
> 
> 
> 
> 
> 
>>So my question is, if i want to archive signature, i have the choice
>>between RFC3126 ES-A or ERS in CMS. Am I right ?
>>
>>If I am, will ES-A be obsoleted by ERS in CSM (as shown in Appendix A in
>>[ers-02])  ?
>>
>>But be sure that I understand ERS is more than just a way to maintain a
>>singature valid.
>>
>>Regards,
>>
>>Loïc
>>
>>
>>
>>
>>>-----Message d'origine-----
>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si]
>>>Envoyé : vendredi 29 avril 2005 11:48
>>>À : HOUSSIER Loic RD-MAPS-ISS; ietf-ltans@imc.org
>>>Objet : RE: [ers-02.txt] Questions
>>>
>>>Loic
>>>
>>>This is what I didn't state. You have to distinguish the
>>>level of the two
>>>approaches. ERS deals mainly with providing syntax on (time)
>>>evidence and
>>>evidence on integrity of a data, while RFC3126 provides data
>>>strucutre for
>>>long term validity of a digital signatures. In this case RFC
>>>can rely on ERS
>>>for time and integrity evidence of a signature, so it is a
>>>more low level
>>>syntax. Or in other words, if you equip CMS with accredited
>>>time, you can
>>>ged basic ERS structure (of course ERS is more than that:
>>>e.g. grouping and
>>>hash trees). This is why I said the approaches of LTANS vs. XAdES are
>>>somehow different, while addressing similar problems.
>>>
>>>BR
>>>
>>>Aleksej
>>>
>>>
>>>>-----Original Message-----
>>>>From: HOUSSIER Loic RD-MAPS-ISS
>>>>[mailto:loic.houssier@francetelecom.com]
>>>>Sent: 29. april 2005 11:24
>>>>To: A. Jerman Blazic; ietf-ltans@imc.org
>>>>Subject: RE: [ers-02.txt] Questions
>>>>
>>>>Aleksej,
>>>>Thanks for your reply.
>>>>
>>>>So, to demonstrate the existantce and stability of signature
>>>>on particular, there will be two ways in PKIX community:
>>>>One using rfc3126, one with ERS attribute within a CMS
>>>>signature object. Am I wrong ?
>>>>
>>>>Loïc
>>>>
>>>>
>>>>
>>>>
>>>>>-----Message d'origine-----
>>>>>De : A. Jerman Blazic [mailto:aljosa@e5.ijs.si] Envoyé :
>>>>
>>>>vendredi 29
>>>>
>>>>>avril 2005 11:08 À : HOUSSIER Loic RD-MAPS-ISS;
>>>>
>>>ietf-ltans@imc.org
>>>
>>>>>Objet : RE: [ers-02.txt] Questions
>>>>>
>>>>>Dear Loic
>>>>>
>>>>>I would be very careful here. XAdES for example is like the
>>>>
>>>>name says:
>>>>
>>>>>syntax for extended signature, which builds on top of a
>>>>
>>>>signature and
>>>>
>>>>>includes all needed complementary data to provide long term
>>>>
>>>>stability
>>>>
>>>>>of digital signatures. The LTANS position, as I understand it,
>>>>>distances from such approach and deals with long term
>>>>
>>>stability of
>>>
>>>>>data. ERS in this case defines requirements on how to
>>>>
>>>>demonstrate the
>>>>
>>>>>existence and stability of data (not signature on
>>>>
>>>particular) on a
>>>
>>>>>timeline. It does not define the data structure nor the
>>>>
>>>>syntax and at
>>>>
>>>>>the moment you can freely use any interpretation of an
>>>>
>>>>evidence record
>>>>
>>>>>including CMS. But XAdES? I am not so sure....
>>>>>
>>>>>Best regards
>>>>>
>>>>>Aleksej
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: owner-ietf-ltans@mail.imc.org
>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of
>>>>>
>>>HOUSSIER Loic
>>>
>>>>>>RD-MAPS-ISS
>>>>>>Sent: 29. april 2005 10:46
>>>>>>To: ietf-ltans@imc.org
>>>>>>Subject: [ers-02.txt] Questions
>>>>>>
>>>>>>
>>>>>>Hi all,
>>>>>>
>>>>>>Reading ERS_02, I have question :
>>>>>>It s said that ER can be part of the Archive or can be
>>>>>
>>>stored as
>>>
>>>>>>another file. What I understand is that we can (using CMS
>>>>>
>>>>or XADES)
>>>>
>>>>>>do ER as part of the Archive.
>>>>>>But Is it compliant with ERS ?
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>Loïc
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Message d'origine-----
>>>>>>>De : owner-ietf-ltans@mail.imc.org
>>>>>>>[mailto:owner-ietf-ltans@mail.imc.org] De la part de
>>>>>>>Internet-Drafts@ietf.org Envoyé : vendredi 8 avril 2005
>>>>>>
>>>>21:29 À :
>>>>
>>>>>>>i-d-announce@ietf.org Cc : ietf-ltans@imc.org Objet : I-D
>>>>>>>ACTION:draft-ietf-ltans-ers-02.txt
>>>>>>>
>>>>>>>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		: Evidence Record Syntax (ERS)
>>>>>>>	Author(s)	: R. Brandner, et al.
>>>>>>>	Filename	: draft-ietf-ltans-ers-02.txt
>>>>>>>	Pages		: 25
>>>>>>>	Date		: 2005-4-8
>>>>>>>
>>>>>>>In many scenarios, users need to be able to ensure and
>>>>>>
>>>>prove the
>>>>
>>>>>>>   existence and integrity of data, especially digitally
>>>>>>
>>>>>>signed data,
>>>>>>
>>>>>>>in
>>>>>>>   a common and reproducible way over a long and possibly
>>>>>>
>>>>>>undetermined
>>>>>>
>>>>>>>   period of time.  This document specifies the syntax and
>>>>>>
>>>>>>processing
>>>>>>
>>>>>>>of
>>>>>>>   an Evidence Record, designed for long-term
>>>>>>
>>>>non-repudiation of
>>>>
>>>>>>>   existence of data, which particularly can be used for
>>>>>>
>>>>>>conservation
>>>>>>
>>>>>>>of
>>>>>>>   evidence of digitally signed data.
>>>>>>>
>>>>>>>A URL for this Internet-Draft is:
>>>>>>>
>>>>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-02.txt
>>>
>>>>>>>To remove yourself from the I-D Announcement list, send a
>>>>>>
>>>>>>message to
>>>>>>
>>>>>>>i-d-announce-request@ietf.org with the word unsubscribe in
>>>>>>
>>>>>>the body of
>>>>>>
>>>>>>>the message.
>>>>>>>You can also visit
>>>>>>>https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>>>>>to change your subscription settings.
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts are also available by anonymous FTP.
>>>>>>
>>>>>Login with the
>>>>>
>>>>>>>username "anonymous" and a password of your e-mail
>>>>>>
>>>>address. After
>>>>
>>>>>>>logging in, type "cd internet-drafts" and then
>>>>>>>	"get draft-ietf-ltans-ers-02.txt".
>>>>>>>
>>>>>>>A list of Internet-Drafts directories can be found in
>>>>>>>http://www.ietf.org/shadow.html or
>>>>>>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>
>>>>>>>
>>>>>>>Internet-Drafts can also be obtained by e-mail.
>>>>>>>
>>>>>>>Send a message to:
>>>>>>>	mailserv@ietf.org.
>>>>>>>In the body type:
>>>>>>>	"FILE /internet-drafts/draft-ietf-ltans-ers-02.txt".
>>>>>>>
>>>>>>>NOTE:	The mail server at ietf.org can return the document in
>>>>>>>	MIME-encoded form by using the "mpack" utility.
>>>>>>
>>>> To use this
>>>>
>>>>>>>	feature, insert the command "ENCODING mime"
>>>>>>
>>>>before the "FILE"
>>>>
>>>>>>>	command.  To decode the response(s), you will
>>>>>>
>>>>need "munpack" or
>>>>
>>>>>>>	a MIME-compliant mail reader.  Different MIME-compliant
>>>>>>
>>>>>>mail readers
>>>>>>
>>>>>>>	exhibit different behavior, especially when dealing with
>>>>>>>	"multipart" MIME messages (i.e. documents which
>>>>>>
>>>>have been split
>>>>
>>>>>>>	up into multiple messages), so check your local
>>>>>>
>>>>documentation on
>>>>
>>>>>>>	how to manipulate these messages.
>>>>>>>
>>>>>>>
>>>>>>>Below is the data which will enable a MIME compliant
>>>>>>
>>>>mail reader
>>>>
>>>>>>>implementation to automatically retrieve the ASCII
>>>>>>
>>>>version of the
>>>>
>>>>>>>Internet-Draft.
>>>>>>>
>>>>>>
>>>>>
>>>
> 
> 





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 j4CAXFCv022969; Thu, 12 May 2005 03:33:15 -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 j4CAXFnm022968; Thu, 12 May 2005 03:33:15 -0700 (PDT)
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.9) with SMTP id j4CAXEgk022949 for <ietf-ltans@imc.org>; Thu, 12 May 2005 03:33:14 -0700 (PDT) (envelope-from aljosa@e5.ijs.si)
Message-Id: <200505121033.j4CAXEgk022949@above.proper.com>
Received: (qmail 29886 invoked from network); 12 May 2005 10:33:12 -0000
Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 12 May 2005 10:33:12 -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 29751-05 for <ietf-ltans@imc.org>; Thu, 12 May 2005 12:33:10 +0200 (CEST)
Received: (qmail 29849 invoked from network); 12 May 2005 10:33:06 -0000
Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 12 May 2005 10:33:06 -0000
From: "A. Jerman Blazic" <aljosa@e5.ijs.si>
To: <ietf-ltans@imc.org>
Subject: RE: [ers-02.txt] Questions
Date: Thu, 12 May 2005 12:39:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcVWvdwEGCQdef87Qbm+R0xfRY4BkgAIOaTg
In-Reply-To: <7475C91E48FAC449A10440CE79B1A122012A5DAD@E9JDH.mgb01.telekom.de>
X-Virus-Scanned: amavisd-new at e5.ijs.si
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CAXFgk022962
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Technically, you are absolutely right but it has figurative meaning.....

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org 
> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Giessmann, Ernstg
> Sent: 12. maj 2005 8:33
> To: ietf-ltans@imc.org
> Subject: AW: [ers-02.txt] Questions
> 
> 
> XAdES = XML Advanced Electronic Signatures nothing about 
> /extended/ is said in the name ;-) /EG.
> 
> > -----Ursprüngliche Nachricht-----
> > Von: owner-ietf-ltans@mail.imc.org
> > [mailto:owner-ietf-ltans@mail.imc.org]Im Auftrag von A. 
> Jerman Blazic
> > Gesendet: Freitag, 29. April 2005 11:08
> > An: 'HOUSSIER Loic RD-MAPS-ISS'; ietf-ltans@imc.org
> > Betreff: RE: [ers-02.txt] Questions
> > 
> > Dear Loic
> > 
> > I would be very careful here. XAdES for example is like the 
> name says:
> > syntax for extended signature, which builds on top of a 
> signature and
> ....
> 




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 j4C6XjK3026327; Wed, 11 May 2005 23:33:45 -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 j4C6Xj4t026326; Wed, 11 May 2005 23:33:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from tcmail21.telekom.de (tcmail21.telekom.de [217.6.95.235]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C6Xh2Z026267 for <ietf-ltans@imc.org>; Wed, 11 May 2005 23:33:44 -0700 (PDT) (envelope-from ErnstG.Giessmann@t-systems.com)
Received: from g9jbq.mgb01.telekom.de (g9jbq.mgb01.telekom.de [164.20.31.5]) by tcmail21.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 12 May 2005 08:33:37 +0200
Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id <KSAN30NF>; Thu, 12 May 2005 08:33:36 +0200
Message-Id: <7475C91E48FAC449A10440CE79B1A122012A5DAD@E9JDH.mgb01.telekom.de>
From: "Giessmann, Ernstg" <ErnstG.Giessmann@t-systems.com>
To: ietf-ltans@imc.org
Subject: AW: [ers-02.txt] Questions
Date: Thu, 12 May 2005 08:33:26 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C6Xj2Z026319
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

XAdES = XML Advanced Electronic Signatures
nothing about /extended/ is said in the name ;-)
/EG.

> -----Ursprüngliche Nachricht-----
> Von: owner-ietf-ltans@mail.imc.org
> [mailto:owner-ietf-ltans@mail.imc.org]Im Auftrag von A. Jerman Blazic
> Gesendet: Freitag, 29. April 2005 11:08
> An: 'HOUSSIER Loic RD-MAPS-ISS'; ietf-ltans@imc.org
> Betreff: RE: [ers-02.txt] Questions
> 
> Dear Loic
> 
> I would be very careful here. XAdES for example is like the name says:
> syntax for extended signature, which builds on top of a signature and
....