Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9RE7oME034142; Fri, 27 Oct 2006 07:07:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9RE7orR034141; Fri, 27 Oct 2006 07:07:50 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9RE7kr1034099 for ; Fri, 27 Oct 2006 07:07:49 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 18220 invoked from network); 27 Oct 2006 13:56:39 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Oct 2006 13:56:39 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 27 Oct 2006 13:56:39 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 27 Oct 2006 10:07:35 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1BCCC0E2@scygmxs1.cygnacom.com> From: Carl Wallace To: =?ISO-8859-1?Q?Michael_Str=F6der?= , ietf-ltans@imc.org Subject: RE: draft-ietf-ltans-pki-retention-01.txt Date: Fri, 27 Oct 2006 10:07:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F9D1.3E5CAA19" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6F9D1.3E5CAA19 Content-Type: text/plain; charset="ISO-8859-1" > HI! > > Some comments to this draft: > I fail to see how applications can efficiently query the > historic PKI artifacts. E.g. most times you want to query a > cert by issuer name/serial number. You also have to query the > CRL most recent at a specific time. How is this done? By having a CRL that covers the lifespan of a CA, the need to search for a specific point in time goes away. A single CRL will suffice. If the community covered by a CRL is partitioned well, then even a cumulative CRL should not be too great in size. Applications would query for a CRL using either a CRL DP in a certificate or query the issuer's directory entry. In either case, the historicalCRL entry would have a cumulative CRL and the associated evidence record. The discovery mechanisms are the same as existing mechanisms. There're no provisions for querying for issuer name/serial number in this draft. > In general: How's the relationship of entries of AUXILIARY > class historicalPKIEntity/historicalCRLDistributionPoint to > PKI entities? Do you have any suggestions which entries > should be extended by this class? The new classes are peers to existing pkiCA and cRLDistributionPoint. The new attributes could be added and maintained throughout a CA's life, then an evidence record generated at the end of the CA's life, for example. > More specific: Are attributes historicalCertificate and > historicalCRL supposed to contain several certs/CRLs and the > client has to sort it out? Do you think this scales? If multiple cumulative CRLs are created and stored in the same entry, then there's much for the client to sort out. If a single cumulative CRL is generated when a CA rekeys, for example, then there's not much to sort out and the discovery mechanisms parallel the existing mechanisms. For certificates, clients may have to select from multiple certificates in a similar fashion as they search for current certificates. I think preserving artifacts directly scales better relative to storing all artifacts in each archived data object. > How about looking at draft-ietf-pkix-ldap-pkc-schema? (last vesion at > http://www.watersprings.org/pub/id/draft-ietf-pkix-ldap-pkc-sc hema-01.txt) > Even if you don't take the approach specified there the draft > raises some good points which could inspire > draft-ietf-ltans-pki-retention. I'll give it a read. Thanks. > > Ciao, Michael. > > Internet-Drafts@ietf.org wrote: > > 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 : Infrastructure Support for Retention > of PKI Artifacts > > Author(s) : C. Wallace > > Filename : draft-ietf-ltans-pki-retention-01.txt > > Pages : 14 > > Date : 2006-10-26 > > > > In most PKIs, directory servers are used to provide current > > certificates and revocation information to relying parties. In > > situations where certificates must be validated relative > to a time in > > the past, relying parties often have no means of obtaining the > > necessary PKI artifacts. This specification defines several > > directory attributes to support validation using historical PKI > > artifacts. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-pki-retention-01. > > txt > ------_=_NextPart_001_01C6F9D1.3E5CAA19 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-ltans-pki-retention-01.txt

> HI!
>
> Some comments to this draft:
> I fail to see how applications can efficiently = query the
> historic PKI artifacts. E.g. most times you = want to query a
> cert by issuer name/serial number. You also = have to query the
> CRL most recent at a specific time. How is this = done?

By having a CRL that covers the lifespan of a CA, the = need to search for a specific point in time goes away.  A single = CRL will suffice.  If the community covered by a CRL is = partitioned well, then even a cumulative CRL should not be too great in = size.  Applications would query for a CRL using either a CRL DP in = a certificate or query the issuer's directory entry.  In either = case, the historicalCRL entry would have a cumulative CRL and the = associated evidence record.  The discovery mechanisms are the same = as existing mechanisms.  There're no provisions for querying for = issuer name/serial number in this draft.

 
> In general: How's the relationship of entries = of AUXILIARY
> class = historicalPKIEntity/historicalCRLDistributionPoint to
> PKI entities? Do you have any suggestions which = entries
> should be extended by this class?

The new classes are peers to existing pkiCA and = cRLDistributionPoint.  The new attributes could be added and = maintained throughout a CA's life, then an evidence record generated at = the end of the CA's life, for example. 

 
> More specific: Are attributes = historicalCertificate and
> historicalCRL supposed to contain several = certs/CRLs and the
> client has to sort it out? Do you think this = scales?

If multiple cumulative CRLs are created and stored in = the same entry, then there's much for the client to sort out.  If = a single cumulative CRL is generated when a CA rekeys, for example, = then there's not much to sort out and the discovery mechanisms parallel = the existing mechanisms.  For certificates, clients may have to = select from multiple certificates in a similar fashion as they search = for current certificates.  I think preserving artifacts directly = scales better relative to storing all artifacts in each archived data = object.

 
> How about looking at = draft-ietf-pkix-ldap-pkc-schema? (last vesion at
> http://www.watersprings.org/pub/id/draft-ietf-pkix-lda= p-pkc-sc
hema-01.txt)
> Even if you don't take the approach specified = there the draft
> raises some good points which could inspire =
> draft-ietf-ltans-pki-retention.

I'll give it a read.  Thanks.

>
> Ciao, Michael.
>
> Internet-Drafts@ietf.org wrote:
> > 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   =         : Infrastructure Support for = Retention
> of PKI Artifacts
> >     = Author(s)       : C. Wallace
> >     = Filename        : = draft-ietf-ltans-pki-retention-01.txt
> >     Pages   =         : 14
> >     Date    =         : 2006-10-26
> >    
> > In most PKIs, directory servers are used = to provide current
> >    certificates and = revocation information to relying parties.  In
> >    situations where = certificates must be validated relative
> to a time in
> >    the past, relying = parties often have no means of obtaining the
> >    necessary PKI = artifacts.  This specification defines several
> >    directory attributes to = support validation using historical PKI
> >    artifacts.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-ltans-p= ki-retention-01.
> > txt
>

------_=_NextPart_001_01C6F9D1.3E5CAA19-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9RDdHE0027446; Fri, 27 Oct 2006 06:39:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9RDdHEX027445; Fri, 27 Oct 2006 06:39:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from srv1.int.stroeder.com (209-30-124-83.dsl.3u.net [83.124.30.209]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9RDdFp0027403 for ; Fri, 27 Oct 2006 06:39:16 -0700 (MST) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by srv1.int.stroeder.com (Postfix) with ESMTP id 0BCC03CB9 for ; Fri, 27 Oct 2006 15:39:09 +0200 (CEST) Received: from srv1.int.stroeder.com ([127.0.0.1]) by localhost (srv1 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21347-04 for ; Fri, 27 Oct 2006 15:38:48 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.int.stroeder.com (Postfix) with ESMTP id 289C62871 for ; Fri, 27 Oct 2006 15:38:48 +0200 (CEST) Message-ID: <45420BE7.4070003@stroeder.com> Date: Fri, 27 Oct 2006 15:38:47 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: draft-ietf-ltans-pki-retention-01.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at int.stroeder.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: HI! Some comments to this draft: I fail to see how applications can efficiently query the historic PKI artifacts. E.g. most times you want to query a cert by issuer name/serial number. You also have to query the CRL most recent at a specific time. How is this done? In general: How's the relationship of entries of AUXILIARY class historicalPKIEntity/historicalCRLDistributionPoint to PKI entities? Do you have any suggestions which entries should be extended by this class? More specific: Are attributes historicalCertificate and historicalCRL supposed to contain several certs/CRLs and the client has to sort it out? Do you think this scales? How about looking at draft-ietf-pkix-ldap-pkc-schema? (last vesion at http://www.watersprings.org/pub/id/draft-ietf-pkix-ldap-pkc-schema-01.txt) Even if you don't take the approach specified there the draft raises some good points which could inspire draft-ietf-ltans-pki-retention. Ciao, Michael. Internet-Drafts@ietf.org wrote: > 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 : Infrastructure Support for Retention of PKI Artifacts > Author(s) : C. Wallace > Filename : draft-ietf-ltans-pki-retention-01.txt > Pages : 14 > Date : 2006-10-26 > > In most PKIs, directory servers are used to provide current > certificates and revocation information to relying parties. In > situations where certificates must be validated relative to a time in > the past, relying parties often have no means of obtaining the > necessary PKI artifacts. This specification defines several > directory attributes to support validation using historical PKI > artifacts. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-pki-retention-01.txt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJoILl099406; Thu, 26 Oct 2006 12:50:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9QJoI44099405; Thu, 26 Oct 2006 12:50:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJoFBf099378 for ; Thu, 26 Oct 2006 12:50:18 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C15E82AD28; Thu, 26 Oct 2006 19:50:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEt-0005JC-G1; Thu, 26 Oct 2006 15:50:07 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ltap-03.txt Message-Id: Date: Thu, 26 Oct 2006 15:50:07 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-term Archive Protocol (LTAP) Author(s) : A. Jerman-Blazic, et al. Filename : draft-ietf-ltans-ltap-03.txt Pages : 39 Date : 2006-10-26 This document describes a service operated as a trusted third party to securely archive electronic document called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-03.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-ltap-03.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-ltap-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26101513.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ltap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ltap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26101513.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJoGqn099397; Thu, 26 Oct 2006 12:50:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9QJoG9o099396; Thu, 26 Oct 2006 12:50:16 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9QJoDHS099376 for ; Thu, 26 Oct 2006 12:50:15 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D8B0A26E51; Thu, 26 Oct 2006 19:50:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GdBEt-0005Jk-Nn; Thu, 26 Oct 2006 15:50:07 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-pki-retention-01.txt Message-Id: Date: Thu, 26 Oct 2006 15:50:07 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Infrastructure Support for Retention of PKI Artifacts Author(s) : C. Wallace Filename : draft-ietf-ltans-pki-retention-01.txt Pages : 14 Date : 2006-10-26 In most PKIs, directory servers are used to provide current certificates and revocation information to relying parties. In situations where certificates must be validated relative to a time in the past, relying parties often have no means of obtaining the necessary PKI artifacts. This specification defines several directory attributes to support validation using historical PKI artifacts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-pki-retention-01.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-pki-retention-01.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-pki-retention-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-26110052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-pki-retention-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-pki-retention-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-26110052.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NGIeK0097947; Mon, 23 Oct 2006 09:18:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NGIeta097946; Mon, 23 Oct 2006 09:18:40 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NGIc0u097939 for ; Mon, 23 Oct 2006 09:18:39 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9NGIa9R003677; Mon, 23 Oct 2006 18:18:37 +0200 (MEST) 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: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Date: Mon, 23 Oct 2006 18:18:35 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A786878E1F0@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Thread-Index: Acb2j5NunYw8CbH9QjmQst+cLd5epgALfiOg From: "Tobias Gondrom" To: "Tilo Kienitz" Cc: , =?iso-8859-1?Q?Andr=E9_Damm-Goossens?= Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9NGIe0u097941 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tilo, thank you for the explanation. And I am very happy that you can live with the compromise we discussed. Please accept my apologies in case I might have understood s.th. wrong. And also thank you for making me aware of the mistake with the intended status of the draft. You are right it must of course be "Standard" (not "Experimental"); we will change the field immediately with the next version as I already mentioned in the review results. Btw. independent of the status, as long as an I-D has not finally been released by the IETF it is always still work in progress as defined by RFC2026. So feedback and requests for change of an I-D are always accepted for discussion and welcome. Thanks, Tobias > -----Original Message----- > From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] > Sent: Monday, October 23, 2006 12:40 PM > To: Tobias Gondrom > Cc: ietf-ltans@imc.org; André Damm-Goossens > Subject: Re: next (hopefully final) revision (08) of ERS - discussion > about order of hashtrees by time and not binary > > Hello Tobias, > > please let me explain the motivation of my bosses e-mail. The way > you understood it, was not exactly what he meant. > > Our first implementation matched the ERS draft. But then we noticed > that binary sorting throws away some information that could be > useful: The order in which the documents came into the archive. > Therefore we changed our implementation to respect the order of the > archiving. At the same time I started the discussion on this list. > > I can assure you that we are not afraid of the work to change our > implementation again. We do not want to change it, because we believe > that we chose the appropriate approach to meet our customer's > requirements. ERS is no standard yet, right now it's intended by you > to get "status: Experimental". So it will still be in a state where > implementators may find that a 95% perfect draft could be improved > by adding an OPTIONAL feature. > > Kind regards > Tilo > > > Tobias Gondrom wrote: > > Hello all, > > > > after a short and very good email exchange with Tilo yesterday evening, > > we agreed to the status that we should address the request and > > discussion for an option to order hashtrees by time of archiving > > (instead of binary order) as an additional option for a future revision > > of ERS (version 2) and will proceed with the current ERS as planned to > > come to a release. > > > > Thanks, Tobias > > > > > > > > Ps.: please note that I also received an email from Mr. Damm-Goossen > > (manager of the company of Tilo) who also asked to change the > > specification so that it matches their current implementation. His main > > reason is because they've already rolled out their own proprietary > > solution to some customers and they would have to change this if we > > would not adjust our WG draft to match their implementation. At the > > moment this argument is only motivating me more to finally get ERS > > released as standard ASAP, and not to change the draft. > > 1. arguments on the mailing list are conclusive: Robert's arguments and > > the other discussions give clear reasons why the draft (with binary > > order of hash trees) is the right and best approach. (binary order is a > > reliable criteria, the time of archiving is NOT, it is s.th. that can > > neither be guaranteed nor really relied on - detailed discussion on > > mailinglist at May 16th and 17th this year.) > > 2. The request to change a draft to match a proprietary implementation > > because there are deployments by one individual company who didn't care > > about the draft at the design time and now wants to reduce any work > > implied by their individual approach can not be a valid argument to > > change a draft. If the WG/IETF would follow such a path we would never > > be able to agree on a standard at all. > > > > > > > > > > > >>-----Original Message----- > >>From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > >>On Behalf Of Tobias Gondrom > >>Sent: Tuesday, October 17, 2006 10:19 PM > >>To: Tilo Kienitz > >>Cc: ietf-ltans@imc.org > >>Subject: RE: next (hopefully final) revision (08) of ERS > >> > >> > >>Hi Tilo, > >> > >>actually I did not intend to ignore your comment. I just thought that > >>the answer Robert gave to your comment one day later was pretty good > >>explaining why it does not make any real sense to sort the hashvalues > > > > by > > > >>date and not in binary order. (especially as I did not see any further > >>answer from you on that) > >> > >>And I and the other authors fully agree with Robert's analysis and > >>arguments... > >> > >>If Robert or I am wrong please let me know. > >> > >>Tobias > >> > >> > >>Ps.: maybe there is also a misunderstanding about this issue, so if > > > > you > > > >>like to discuss this on the phone for a few minutes maybe we can > >>exchange some arguments and see whether I missed s.th. or we can > > > > report > > > >>to the mailing list that the question could be resolved or we need > >>further dispute on that. (if you like you can give me a call at > >>+498946291816) > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] > >>>Sent: Tuesday, October 17, 2006 11:39 AM > >>>To: Tobias Gondrom > >>>Cc: ietf-ltans@imc.org > >>>Subject: Re: next (hopefully final) revision (08) of ERS > >>> > >>>Hello Tobias, > >>> > >>>if this is the final revision, then I assume that you do not intend > >>>to answer on my e-mail from 16 June regarding the sorting of the > >>>hash values? > >>> > >>>Kind regards > >>>Tilo Kienitz Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCpwsI038121; Mon, 23 Oct 2006 05:51:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NCpwRR038120; Mon, 23 Oct 2006 05:51:58 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCptf3038094 for ; Mon, 23 Oct 2006 05:51:56 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9NCppLt018693; Mon, 23 Oct 2006 14:51:52 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F6A2.027C8CB5" Subject: RE: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Date: Mon, 23 Oct 2006 14:51:50 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868705289@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Thread-Index: Acb2lN6Gmq0RKaP4Rc6ntE9nJoJusAADOu0w From: "Tobias Gondrom" To: "Carl Wallace" , "Tilo Kienitz" Cc: , =?iso-8859-1?Q?Andr=E9_Damm-Goossens?= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F6A2.027C8CB5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Carl and thanks to Tilo for making us of aware of this mistake: we will = correct the intent of the draft to "Standard" as I already wrote in the = review results for ERS-08 =20 Thanks, Tobias =20 =20 =20 ________________________________ From: Carl Wallace [mailto:CWallace@cygnacom.com]=20 Sent: Monday, October 23, 2006 1:18 PM To: Tilo Kienitz; Tobias Gondrom Cc: ietf-ltans@imc.org; Andr=E9 Damm-Goossens Subject: RE: next (hopefully final) revision (08) of ERS - discussion = about order of hashtrees by time and not binary =20 > ERS is no standard yet,=20 > right now it's intended by you to get "status: Experimental".=20 I've never noticed this, and it certainly is not consistent with = expectations. I suspect this is an artifact of ERS' origins as the = experimental ATS draft and that the next version will be published = without the Experimental indication. ------_=_NextPart_001_01C6F6A2.027C8CB5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: next (hopefully final) revision (08) of ERS - discussion = about order of hashtrees by time and not binary

Carl and thanks = to Tilo for making us of aware of this mistake: we will correct the intent of = the draft to „Standard“ as I already wrote in the review results for = ERS-08

 =

Thanks, = Tobias

 =

 =

 =

From: Carl Wallace [mailto:CWallace@cygnacom.com]
Sent: Monday, October 23, = 2006 1:18 PM
To: Tilo Kienitz; Tobias = Gondrom
Cc: ietf-ltans@imc.org; = Andr=E9 Damm-Goossens
Subject: RE: next = (hopefully final) revision (08) of ERS - discussion about order of hashtrees by = time and not binary

 

> ERS is no standard yet,
> right now it's = intended by you to get "status: Experimental".

I've never noticed this, and it certainly is not consistent with = expectations.  I suspect this is an artifact of ERS' origins as the experimental ATS = draft and that the next version will be published without the Experimental = indication.

------_=_NextPart_001_01C6F6A2.027C8CB5-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCkOuA036942; Mon, 23 Oct 2006 05:46:24 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NCkNwm036941; Mon, 23 Oct 2006 05:46:23 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCkJ6S036915 for ; Mon, 23 Oct 2006 05:46:22 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9NCkHDI026897 for ; Mon, 23 Oct 2006 14:46:18 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F6A1.3B57D4C6" Subject: ERS-08 first results of review for WG Last Call Date: Mon, 23 Oct 2006 14:46:16 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868705283@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS-08 first results of review for WG Last Call Thread-Index: Acb2oTsPxeGuBsx0Sl6uKOdhM4m5Bw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F6A1.3B57D4C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello LTANS WG,=20 Below you find the change requests I received during the WG Last Call for ERS until today. I discussed the proposal shortly with Carl and we agreed to come up with a revised version not today but to wait until end of this week to also give others the time for their comments and for possible discussion about those already received proposed changes on the mailing list.=20 Summary of the changes from the authors: Most of the change requests are only formal or about slightly changes in the wording and pose no problem. In general the authors would be ok to execute all proposed requests. The requests 5 and 6 seem ok to us, but we are aware we may come in the region of the ASN.1 compiler discussion here and would be happy to receive feedback if there are issues with the newly used ASN.1 "TYPE-IDENTIFIER". Request 9 seems more s small definition problem than a change in the end. There might be a deficiency in the defined oids for ltans which could be solved easily either way.=20 Thanks and we are still open for any further review comments and change requests for ERS Tobias Here are the review results so far and change requests:=20 1. formal correction: change the Intended status from Experimental to Standard > Comment from the authors: thanks, we simply forgot to change the XML from which we produce the I-D and this slipped through; change will be executed. 2. add references in the document to the two other LTANS document in work: reqs [I-D.ietf-ltans-reqs] and ltap [I-D.ietf-ltans-ltap]. > Comment from the authors: correct references are always ok, change will be executed. 3. chapter 1.3 Terminology:=20 Change the reference names to a more normative names convention:=20 OLD: [I180141], [I180142], [I180143], and [ANSX995]. New: [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005]. > Comment from the authors: thanks, we were not aware that the other writing of the references would be better: As it has no impact on the content we will execute the change unless someone objects until close of WG Last Call.=20 4. insert a small chapter about the imported ASN.1 structures: > Comment from the authors: To add such a chapter is not a problem and does not change the demantic of the document we execute this unless any objections are raised on the mailing-list. However the changed IMPORT for ContentInfo and AlgorithmIdentifier MUST also get the approval of the mailing-list especially of the AD, or pass until the end of the WG Last Call without objections. (Please note Peter also recommended to change Imports for ContentInfo from CryptographicMessageSyntax2004 to PKCS-7 and for AlgorithmIdentifier from PKIX1Explicit88 to AuthenticationFramework.=20 These imports can be used as well as the ones before. Peter claims they are using current ASN.1 syntax which the the structures we had before did not.=20 (and please note: Peter also provided a reference to a free and open source asn1 compiler that supports the most current version of ASN.1 syntax.: http://lionet.info/asn1c/ ) Here is the proposed text for the chapter about the imports: "2. Identification and references 2.1. ASN.1 module definition This specification defines the following ASN.1 module: ASN.1 Module start ERS {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) id-mod(1) id-mod-ers(1) } DEFINITIONS IMPLICIT TAGS ::=3D BEGIN 2.2. ASN.1 imports and exports The specification exports all definition and imports various definitions. The definitions from the PKCS suite used here because they are written for a current version of ASN.1. ASN.1 Imports and exports -- EXPORTS ALL -- IMPORTS ContentInfo FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7) modules(0) pkcs-7(1)} AlgorithmIdentifier FROM AuthenticationFramework {joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 4} ; 2.3. LTANS identification This document defines the LTANS object identifier tree root. LTANS Object Identifier tree root id-ltans OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) ltans(11) } 2.4. ERS identifiers The defines the following ERS specific ASN.1 object identifier for encryption methods LTANS Object Identifier tree root id-em OBJECT IDENTIFIER ::=3D { id-ltans 2 }" > Comment from the authors: If there are no objections we will add the short chapter in the hope that this will improve the readability and usability of the upcoming standard document .=20 5. I received a proposal also from Peter to change the structure for CryptInfos to address the current syntax definition and capabilities of current ASN.1 syntax definition OLD: CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF CryptoInfo CryptoInfo ::=3D SEQUENCE { cryptoInfoType OBJECT IDENTIFIER cryptoInfoValue ANY DEFINED BY cryptoInfoType } NEW:=20 CRYPT-INFO-CLASS ::=3D TYPE-IDENTIFIER CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF INSTANCE OF CRYPT-INFO-CLASS > Comment from the authors: the semantic of the structure would be sustained (and note CryptoInfos is OPTIONAL in the EvidenceRecord structure), so there are no objections from the authors about this change 6. and as with topic 5 I also received the request to use the current ASN.1 syntax for EncryptionInfo: OLD: EncryptionInfo ::=3D SEQUENCE { encryptionInfoType OBJECT IDENTIFIER, encryptionInfoValue [0] EXPLICIT ANY DEFINED BY encryptionInfoType } NEW: ENCRYPTION-INFO-CLASS ::=3D TYPE-IDENTIFIER EncryptionInfos ::=3D SEQUENCE SIZE (1..MAX) OF INSTANCE OF ENCRYPTION-INFO-CLASS > Comment from the authors: the semantic of the structure would be sustained (and note EncryptionInfo is OPTIONAL in the EvidenceRecord structure), so there are no objections from the authors about this change 7. And to add the three dots in the last line of the structure definition of EvidenceRecord to explicitly define that parser or ERS-version-1 shall ignore all content that might be added by later versions in the row.=20 EvidenceRecord ::=3D SEQUENCE { version INTEGER { v1(1) } , digestAlgorithms SEQUENCE OF AlgorithmIdentifier, cryptoInfos [0] CryptoInfos OPTIONAL, encryptionInfo [1] EncryptionInfo OPTIONAL, archiveTimeStampSequence ArchiveTimeStampSequence, ... } > Comment from the authors: the three dots in the last line of the structure support the future version compatibility and extensibility and thus are supported by the authors - AFAIK good ASN.1 parsers should anyway even without these dots ignore structures after the defined ones and not crash with an error.=20 8. Proposal to revise the wording of the text:=20 OLD:=20 version is the syntax version number, for compatibility with future revisions of this specification. The default value is 1. Lower values indicate that an earlier non-conform (proprietary) version of the ERS has been used. NEW:=20 The `version' item contains the syntax version, for compatibility with future revisions of this specification and to distinguish it from earlier non-conformant or proprietary versions of the ERS. The value 1 indicates this specification. Lower values indicate an earlier version of the ERS has been used. An implementation conforming to this specification MAY reject a version value below 1. > Comment from the authors: the change of the wording does improve clarity of the text and does not change the semantic or intent of the text and can be executed unless any objections are raised on the mailing list.=20 9. To change the OIDs in the Appendix A. Evidence Record using CMS > comment from the authors: the authors are not sure about this change (but there are no big objections either), probably it is also sufficient to simply put on the new oids to the store at: http://www.imc.org/ietf-ltans/ltans-oid.asn - Maybe Peter can come up with a short discussion about this proposed change.=20 OLD: Internal signature: id-EvidenceRecord ::=3D {id-em-env-data-Attribute 1} External signature: id-EvidenceRecord ::=3D {id-em-env-data-Attribute 2} NEW:=20 ASN.1 Internal EvidenceRecord Attribute id-EvidenceRecord-Internal ::=3D {id-em 1} ASN.1 External EvidenceRecord Attribute id-EvidenceRecord-External ::=3D {id-em 2} __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C6F6A1.3B57D4C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ERS-08 first results of review for WG Last Call

Hello = LTANS WG,

Below = you find the change requests I received during the WG Last Call for ERS until today. = I discussed the proposal shortly with Carl and we agreed to come up with = a revised version not today but to wait until end of this week to also give = others = the time for their comments and for possible discussion about those already received proposed changes on the mailing list. =

Summary of the changes from the = authors:

Most = of the change requests are only formal or about slightly changes in the = wording and pose no problem. In general the authors would be ok to execute = all proposed requests. The requests = 5 and 6 seem ok to us, but we are aware we may come in the region of the = ASN.1 compiler discussion here and would be happy to receive feedback if = there are issues with the newly used ASN.1 “TYPE-IDENTIFIER”. Request 9 seems more s small definition problem than a = change in the end. There might be a deficiency in the defined oids for ltans = which could = be solved easily either way.

Thanks and we are still open for any further review comments and change = requests for ERS

Tobias


Here are the review results so far and change = requests:

1. formal correction: change the Intended status from Experimental to Standard

> Comment from the = authors: thanks, = we simply forgot to change the XML from which we produce the I-D and = this slipped through; = change will be executed.

2. add references in the document to the two other LTANS = document in work: reqs [I-D.ietf-ltans-reqs] and ltap [I-D.ietf-ltans-ltap].

> Comment from the = authors: correct references are always ok, change will be = executed.

3. chapter 1.3 Terminology:

      Change the reference names to a = more normative names convention:

OLD: [I180141], [I180142], [I180143], and = [ANSX995].

New: [ISO-18014-1.2002], [ISO-18014-2.2002], = [ISO-18014-3.2004], and [ANSI.X9-95.2005].

> Comment from the = authors: thanks, we were not aware that the other writing of the = references would be better: = As it has no impact on the = content we will execute the change unless someone objects until close of WG Last Call.


4. insert a small chapter about the imported ASN.1 = structures:

> Comment from the = authors: To add such a chapter is not a problem = and does not change the = demantic of the document we execute this unless any objections are raised = on the mailing-list. However the changed IMPORT for ContentInfo and AlgorithmIdentifier MUST also get the approval of the mailing-list especially = of the AD, = or pass until the end of the WG Last Call without objections.

(Please note Peter also recommended to change = Imports for ContentInfo from CryptographicMessageSyntax2004 to PKCS-7 and for AlgorithmIdentifier from PKIX1Explicit88 to AuthenticationFramework.

These = imports can be used as well as the ones before. Peter claims they are = using current ASN.1 syntax which the the structures we had before did not.

(and please note: Peter = also provided a reference to a free and open source asn1 = compiler that supports the most current version of ASN.1 = syntax.: http://lionet.info/asn1c/ = )

Here = is the proposed text for the chapter about the = imports:

“2.  Identification and references

2.1.  ASN.1 module definition

   This specification defines the following = ASN.1 module:

   ASN.1 Module start

   ERS {iso(1) identified-organization(3) = dod(6)

         = internet(1) security(5) mechanisms(5)

         = ltans(11) id-mod(1) id-mod-ers(1) }

   DEFINITIONS IMPLICIT TAGS = ::=3D

   BEGIN


2.2.  ASN.1 imports and exports

   The specification exports all definition and = imports various

   definitions.  The definitions from the = PKCS suite used here because

   they are written for a current version of = ASN.1.

   ASN.1 Imports and exports

   -- EXPORTS ALL --

   IMPORTS

   ContentInfo FROM PKCS-7

     {iso(1) member-body(2) us(840) = rsadsi(113549) pkcs(1) pkcs-7(7)

      modules(0) = pkcs-7(1)}

   AlgorithmIdentifier FROM = AuthenticationFramework

     {joint-iso-itu-t ds(5) module(1) = authenticationFramework(7) 4}

   ;

2.3.  LTANS identification

   This document defines the LTANS object = identifier tree root.

   LTANS Object Identifier tree = root

   id-ltans OBJECT IDENTIFIER = ::=3D

         &nbs= p;  { = iso(1) identified-organization(3) dod(6) internet(1)

         &nbs= p;    security(5) mechanisms(5) ltans(11) = }

2.4.  ERS identifiers

   The defines the following ERS specific ASN.1 = object identifier for

   encryption methods

   LTANS Object Identifier tree = root

   id-em OBJECT IDENTIFIER ::=3D { id-ltans 2 = }”


> Comment from the = authors: = If there are no objections we will add the short chapter in the hope = that this will improve the readability and usability of the upcoming = standard document .


5. I = received a proposal also from Peter to change the structure for CryptInfos to address the current syntax definition and capabilities of current = ASN.1 syntax definition

OLD:

CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) OF = CryptoInfo

   CryptoInfo ::=3D SEQUENCE

   {

      = cryptoInfoType    OBJECT IDENTIFIER

      = cryptoInfoValue   ANY DEFINED BY = cryptoInfoType

   }

NEW: =

   CRYPT-INFO-CLASS ::=3D = TYPE-IDENTIFIER

   CryptoInfos ::=3D SEQUENCE SIZE (1..MAX) = OF

         INSTANCE = OF CRYPT-INFO-CLASS

> Comment from the = authors: = the semantic of the structure would be sustained (and note CryptoInfos = is OPTIONAL in the EvidenceRecord structure), so there are no objections from the authors = about this change


6. = and as with topic 5 I also received the request to use the current ASN.1 = syntax for EncryptionInfo:

OLD:

   EncryptionInfo ::=3D = SEQUENCE

   {

      encryptionInfoType OBJECT = IDENTIFIER,

      encryptionInfoValue [0] = EXPLICIT ANY DEFINED BY encryptionInfoType

   }

NEW:

   ENCRYPTION-INFO-CLASS ::=3D = TYPE-IDENTIFIER

   EncryptionInfos ::=3D SEQUENCE SIZE (1..MAX) = OF

         INSTANCE = OF ENCRYPTION-INFO-CLASS


> Comment from the = authors: = the semantic of the structure would be sustained (and note EncryptionInfo is OPTIONAL in the EvidenceRecord = structure), = so there are no objections from the authors about this = change



7. And to add the three dots in the last line of the = structure definition = of EvidenceRecord to explicitly define that parser or ERS-version-1 shall = ignore all content that might be added by later versions in the = row. =


   EvidenceRecord ::=3D SEQUENCE = {

      = version           =         INTEGER { v1(1) } = ,

      = digestAlgorithms          = SEQUENCE OF AlgorithmIdentifier,

      = cryptoInfos          &n= bsp;    [0] CryptoInfos OPTIONAL,

      = encryptionInfo          = ;  [1] EncryptionInfo OPTIONAL,

      = archiveTimeStampSequence  = ArchiveTimeStampSequence,

      ...

      }

> Comment from the = authors: the three dots in the last line of the structure support = the future version compatibility and extensibility and thus are supported by the authors – AFAIK good ASN.1 parsers = should anyway even without these dots ignore structures after the = defined ones and not crash with an error. =



8. Proposal to revise the wording of the = text:

OLD: =

   version is the syntax version number, for = compatibility with future

   revisions of this specification.  The = default value is 1.  Lower

   values indicate that an earlier non-conform = (proprietary) version of

   the ERS has been used.

NEW: =

   The `version' item contains the syntax = version, for compatibility

   with future revisions of this specification = and to distinguish it

   from earlier non-conformant or proprietary = versions of the ERS.  The

   value 1 indicates this specification.  = Lower values indicate an

   earlier version of the ERS has been = used.  An implementation

   conforming to this specification MAY reject = a version value below 1.


> Comment from the = authors: the change of the wording does improve clarity of the = text and does not change the semantic or intent of the text = and can be executed unless any objections = are raised = on the mailing list.



9. To change the OIDs in the Appendix A.  Evidence Record using = CMS

> = comment from the authors: the authors are not sure about this = change = (but there are no big objections either), probably it is also sufficient to simply put = on the new oids to the store at: = http://www.imc.org/ietf-ltans/ltans-oid.asn<= /U>  - Maybe Peter can come up with a short discussion = about this proposed change.

OLD:

      Internal = signature:

      id-EvidenceRecord ::=3D = {id-em-env-data-Attribute 1}

      External = signature:

      id-EvidenceRecord ::=3D = {id-em-env-data-Attribute 2}

NEW:

   ASN.1 Internal EvidenceRecord = Attribute

   id-EvidenceRecord-Internal ::=3D {id-em = 1}

   ASN.1 External EvidenceRecord = Attribute

   id-EvidenceRecord-External ::=3D {id-em = 2}







__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

This = e-mail is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This e-mail may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above (“Authorized = Recipient”) for the purpose for which it was sent by OTC. All = other rights and licenses to this e-mail are fully reserved to OTC. If = you are not an Authorized Recipient, you are required to immediately = delete this e-mail in its entirety without printing, copying, using, = and/or re-transmitting this e-mail, either in whole or in part. The = transmission of this e-mail by OTC is not to be construed as a waiver by = OTC and/or the individual sending this e-mail on behalf of OTC of any of = their respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C6F6A1.3B57D4C6-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCGdRU030569; Mon, 23 Oct 2006 05:16:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NCGd4P030568; Mon, 23 Oct 2006 05:16:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NCGbJx030558 for ; Mon, 23 Oct 2006 05:16:38 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k9NCGRl20048; Mon, 23 Oct 2006 14:16:27 +0200 (MEST) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Mon, 23 Oct 2006 14:16:27 +0200 (MET DST) Message-ID: <453CB226.1070003@edelweb.fr> Date: Mon, 23 Oct 2006 14:14:30 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Tilo Kienitz CC: Tobias Gondrom , ietf-ltans@imc.org, =?ISO-8859-1?Q?Andr=E9_Damm-Goossens?= Subject: Re: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary References: <2666EB2A846BAC4BB2D7F593301A7868704F6D@MUCXGC2.opentext.net> <453C9BEE.4020502@seccommerce.de> In-Reply-To: <453C9BEE.4020502@seccommerce.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040107080303020500050006" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms040107080303020500050006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Tilo Kienitz wrote: > > Hello Tobias, > > please let me explain the motivation of my bosses e-mail. The way > you understood it, was not exactly what he meant. > > Our first implementation matched the ERS draft. But then we noticed > that binary sorting throws away some information that could be > useful: The order in which the documents came into the archive. > Therefore we changed our implementation to respect the order of the > archiving. At the same time I started the discussion on this list. > It seems good to have some means to determine the order of documents by inspecting a tree. In this way one can add a 'time stamp', e.g. an article of a newspaper into the tree, and knows whether other data were added before or after. Knowing by external means the earliest day when it could have been added, one knows that all date after it are "too late". But I am not sure whether this feature is supposed to be developped via the ERS trees or whether this is something supposed to be done by the 'time stamps'. Or, in other words, do the possible manipulations of a hash tree create any conflict with such a need? Can one restructure trees, etc. ???? -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms040107080303020500050006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDIzMTIxNDMwWjAjBgkqhkiG9w0B CQQxFgQUhAnQIBkNFrCZKH3UCnGvojpPfjEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAJdlnjcmwO8LQecBt lieMCU8RDhgbYPC+fZs46h3RmukvjPTcC6iiWCDX6Fbt/T+jotQLJTz+nfbkDEOh4xsnD7Cn fmC44UyUFN2TjypoTY5wrEbxPYrnPvBbZd0y8IwhoDeKVVOTXRSskdcteGrSaP6sBrfr4FPj N26HwFkS130AAAAAAAA= --------------ms040107080303020500050006-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NBHnNs019166; Mon, 23 Oct 2006 04:17:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NBHnSL019165; Mon, 23 Oct 2006 04:17:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k9NBHmFf019144 for ; Mon, 23 Oct 2006 04:17:48 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 15295 invoked from network); 23 Oct 2006 11:06:52 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;23 Oct 2006 11:06:52 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 23 Oct 2006 11:06:51 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 23 Oct 2006 07:17:42 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1B6FA78F@scygmxs1.cygnacom.com> From: Carl Wallace To: Tilo Kienitz , Tobias Gondrom Cc: ietf-ltans@imc.org, =?ISO-8859-1?Q?Andr=E9_Damm-Goossens?= Subject: RE: next (hopefully final) revision (08) of ERS - discussion abou t order of hashtrees by time and not binary Date: Mon, 23 Oct 2006 07:17:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F694.DAFCA9E2" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C6F694.DAFCA9E2 Content-Type: text/plain; charset="ISO-8859-1" > ERS is no standard yet, > right now it's intended by you to get "status: Experimental". I've never noticed this, and it certainly is not consistent with expectations. I suspect this is an artifact of ERS' origins as the experimental ATS draft and that the next version will be published without the Experimental indication. ------_=_NextPart_001_01C6F694.DAFCA9E2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: next (hopefully final) revision (08) of ERS - discussion = about order of hashtrees by time and not binary

> ERS is no standard yet,
> right now it's intended by you to get = "status: Experimental".

I've never noticed this, and it certainly is not = consistent with expectations.  I suspect this is an artifact of = ERS' origins as the experimental ATS draft and that the next version = will be published without the Experimental indication.

------_=_NextPart_001_01C6F694.DAFCA9E2-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NAdd3g011682; Mon, 23 Oct 2006 03:39:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9NAddfo011681; Mon, 23 Oct 2006 03:39:39 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9NAda4T011658 for ; Mon, 23 Oct 2006 03:39:38 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 5835 invoked from network); 23 Oct 2006 10:45:41 -0000 Received: from unknown (HELO ?127.0.0.1?) (192.168.1.10) by 0 with RC4-MD5 encrypted SMTP; 23 Oct 2006 10:45:41 -0000 Message-ID: <453C9BEE.4020502@seccommerce.de> Date: Mon, 23 Oct 2006 12:39:42 +0200 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org, =?ISO-8859-1?Q?Andr=E9_Damm-Goossens?= Subject: Re: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary References: <2666EB2A846BAC4BB2D7F593301A7868704F6D@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868704F6D@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tobias, please let me explain the motivation of my bosses e-mail. The way you understood it, was not exactly what he meant. Our first implementation matched the ERS draft. But then we noticed that binary sorting throws away some information that could be useful: The order in which the documents came into the archive. Therefore we changed our implementation to respect the order of the archiving. At the same time I started the discussion on this list. I can assure you that we are not afraid of the work to change our implementation again. We do not want to change it, because we believe that we chose the appropriate approach to meet our customer's requirements. ERS is no standard yet, right now it's intended by you to get "status: Experimental". So it will still be in a state where implementators may find that a 95% perfect draft could be improved by adding an OPTIONAL feature. Kind regards Tilo Tobias Gondrom wrote: > Hello all, > > after a short and very good email exchange with Tilo yesterday evening, > we agreed to the status that we should address the request and > discussion for an option to order hashtrees by time of archiving > (instead of binary order) as an additional option for a future revision > of ERS (version 2) and will proceed with the current ERS as planned to > come to a release. > > Thanks, Tobias > > > > Ps.: please note that I also received an email from Mr. Damm-Goossen > (manager of the company of Tilo) who also asked to change the > specification so that it matches their current implementation. His main > reason is because they've already rolled out their own proprietary > solution to some customers and they would have to change this if we > would not adjust our WG draft to match their implementation. At the > moment this argument is only motivating me more to finally get ERS > released as standard ASAP, and not to change the draft. > 1. arguments on the mailing list are conclusive: Robert's arguments and > the other discussions give clear reasons why the draft (with binary > order of hash trees) is the right and best approach. (binary order is a > reliable criteria, the time of archiving is NOT, it is s.th. that can > neither be guaranteed nor really relied on - detailed discussion on > mailinglist at May 16th and 17th this year.) > 2. The request to change a draft to match a proprietary implementation > because there are deployments by one individual company who didn't care > about the draft at the design time and now wants to reduce any work > implied by their individual approach can not be a valid argument to > change a draft. If the WG/IETF would follow such a path we would never > be able to agree on a standard at all. > > > > > >>-----Original Message----- >>From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > >>On Behalf Of Tobias Gondrom >>Sent: Tuesday, October 17, 2006 10:19 PM >>To: Tilo Kienitz >>Cc: ietf-ltans@imc.org >>Subject: RE: next (hopefully final) revision (08) of ERS >> >> >>Hi Tilo, >> >>actually I did not intend to ignore your comment. I just thought that >>the answer Robert gave to your comment one day later was pretty good >>explaining why it does not make any real sense to sort the hashvalues > > by > >>date and not in binary order. (especially as I did not see any further >>answer from you on that) >> >>And I and the other authors fully agree with Robert's analysis and >>arguments... >> >>If Robert or I am wrong please let me know. >> >>Tobias >> >> >>Ps.: maybe there is also a misunderstanding about this issue, so if > > you > >>like to discuss this on the phone for a few minutes maybe we can >>exchange some arguments and see whether I missed s.th. or we can > > report > >>to the mailing list that the question could be resolved or we need >>further dispute on that. (if you like you can give me a call at >>+498946291816) >> >> >> >> >>>-----Original Message----- >>>From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] >>>Sent: Tuesday, October 17, 2006 11:39 AM >>>To: Tobias Gondrom >>>Cc: ietf-ltans@imc.org >>>Subject: Re: next (hopefully final) revision (08) of ERS >>> >>>Hello Tobias, >>> >>>if this is the final revision, then I assume that you do not intend >>>to answer on my e-mail from 16 June regarding the sorting of the >>>hash values? >>> >>>Kind regards >>>Tilo Kienitz Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9JDHbOJ064235; Thu, 19 Oct 2006 06:17:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9JDHbEl064234; Thu, 19 Oct 2006 06:17:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9JDHZBL064219 for ; Thu, 19 Oct 2006 06:17:36 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9JDHWLt014089; Thu, 19 Oct 2006 15:17:33 +0200 (MEST) 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="us-ascii" Subject: RE: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Date: Thu, 19 Oct 2006 15:17:32 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868704F6D@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next (hopefully final) revision (08) of ERS - discussion about order of hashtrees by time and not binary Thread-Index: Acbx0Bh18YMQSpcsSh6jKTbLd3Vy9gAWEvHQAFRqtQA= From: "Tobias Gondrom" To: "Tobias Gondrom" , "Tilo Kienitz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9JDHaBL064229 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello all, after a short and very good email exchange with Tilo yesterday evening, we agreed to the status that we should address the request and discussion for an option to order hashtrees by time of archiving (instead of binary order) as an additional option for a future revision of ERS (version 2) and will proceed with the current ERS as planned to come to a release. Thanks, Tobias Ps.: please note that I also received an email from Mr. Damm-Goossen (manager of the company of Tilo) who also asked to change the specification so that it matches their current implementation. His main reason is because they've already rolled out their own proprietary solution to some customers and they would have to change this if we would not adjust our WG draft to match their implementation. At the moment this argument is only motivating me more to finally get ERS released as standard ASAP, and not to change the draft. 1. arguments on the mailing list are conclusive: Robert's arguments and the other discussions give clear reasons why the draft (with binary order of hash trees) is the right and best approach. (binary order is a reliable criteria, the time of archiving is NOT, it is s.th. that can neither be guaranteed nor really relied on - detailed discussion on mailinglist at May 16th and 17th this year.) 2. The request to change a draft to match a proprietary implementation because there are deployments by one individual company who didn't care about the draft at the design time and now wants to reduce any work implied by their individual approach can not be a valid argument to change a draft. If the WG/IETF would follow such a path we would never be able to agree on a standard at all. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Tobias Gondrom > Sent: Tuesday, October 17, 2006 10:19 PM > To: Tilo Kienitz > Cc: ietf-ltans@imc.org > Subject: RE: next (hopefully final) revision (08) of ERS > > > Hi Tilo, > > actually I did not intend to ignore your comment. I just thought that > the answer Robert gave to your comment one day later was pretty good > explaining why it does not make any real sense to sort the hashvalues by > date and not in binary order. (especially as I did not see any further > answer from you on that) > > And I and the other authors fully agree with Robert's analysis and > arguments... > > If Robert or I am wrong please let me know. > > Tobias > > > Ps.: maybe there is also a misunderstanding about this issue, so if you > like to discuss this on the phone for a few minutes maybe we can > exchange some arguments and see whether I missed s.th. or we can report > to the mailing list that the question could be resolved or we need > further dispute on that. (if you like you can give me a call at > +498946291816) > > > > > -----Original Message----- > > From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] > > Sent: Tuesday, October 17, 2006 11:39 AM > > To: Tobias Gondrom > > Cc: ietf-ltans@imc.org > > Subject: Re: next (hopefully final) revision (08) of ERS > > > > Hello Tobias, > > > > if this is the final revision, then I assume that you do not intend > > to answer on my e-mail from 16 June regarding the sorting of the > > hash values? > > > > Kind regards > > Tilo Kienitz > > > > > > Tobias Gondrom wrote: > > > Hi, > > > > > > I just completed the next revision of ERS and submitted it to the > > > IETF-secretary. > > > > > > It contains the following changes as found by your reviews (thanks > to > > > Peter, Julien, Robert, Bill and Carl): > > > > > > 1. Split the reducedHashtree in SEQ of PartialHashtree for easier > > > reading and better understanding > > > > > > 2. Set the tags [0] and [1] to ArchiveTimeStamp structure (and > removed > > > the EXPLICIT tags again as they are no longer necessary with the [0] > and > > > [1] to guarantee unambiguousness). > > > > > > So the total change is from: > > > > > > ArchiveTimeStamp ::= SEQUENCE { > > > > > > digestAlgorithm AlgorithmIdentifier OPTIONAL, > > > > > > reducedHashtree ***** [0] EXPLICIT* SEQUENCE OF SEQUENCE OF OCTET > > > STRING OPTIONAL, > > > > > > timeStamp ContentInfo} > > > > > > > > > added tag to: > > > > > > ArchiveTimeStamp ::= SEQUENCE { > > > > > > digestAlgorithm***** [0]* AlgorithmIdentifier OPTIONAL, > > > > > > reducedHashtree***** [1]* SEQUENCE OF***** PartialHashtree* > OPTIONAL, > > > > > > timeStamp ContentInfo} > > > > > > > > > > > > *PartialHashtree ::= SEQUENCE OF OCTET STRING******* > > > > > > 3. Mentioned with the versioning of EvidenceRecord that default > value is > > > 1 and lower version numbers indicate it is a version prior this > released > > > document. > > > > > > 4. kept the IMPORTs as Russ made clear at the last WG meeting in > > > Montreal that to remove them would result in rejection by the AD at > > > submission. > > > > > > Thanks, Tobias Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9JC9l7u057797; Thu, 19 Oct 2006 05:09:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9JC9l8l057796; Thu, 19 Oct 2006 05:09:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9JC9jtX057786 for ; Thu, 19 Oct 2006 05:09:46 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9JC9hxa002282 for ; Thu, 19 Oct 2006 14:09:44 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F377.75B7587D" Subject: draft-ietf-ltans-validate-00.txt - first comments Date: Thu, 19 Oct 2006 14:09:43 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868704F3C@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ltans-validate-00.txt - first comments Thread-Index: Acbzd3XWrw/H95eUQaioWg6V0zry3A== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F377.75B7587D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, just received from Tilo the first two comments about typos in "validate": "In cases where an specailly accredited authority has issued the --------- the time stamp used in teh Evdience Record." Will be corrected in the next version. Thanks and open for any further input and review Thanks, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C6F377.75B7587D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ltans-validate-00.txt - first comments

Hello,

just = received from Tilo the first two comments about typos = in “validate”:

“In cases where an specailly accredited authority has issued = the

           &n= bsp;      ---------

the time stamp used in teh Evdience Record.”

Will = be corrected in the next version.

Thanks and open for any further input and review

Thanks, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

This = e-mail is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This e-mail may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above (“Authorized = Recipient”) for the purpose for which it was sent by OTC. All = other rights and licenses to this e-mail are fully reserved to OTC. If = you are not an Authorized Recipient, you are required to immediately = delete this e-mail in its entirety without printing, copying, using, = and/or re-transmitting this e-mail, either in whole or in part. The = transmission of this e-mail by OTC is not to be construed as a waiver by = OTC and/or the individual sending this e-mail on behalf of OTC of any of = their respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C6F377.75B7587D-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9ILP8bB073362; Wed, 18 Oct 2006 14:25:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9ILP8ng073361; Wed, 18 Oct 2006 14:25:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9ILP5FZ073338 for ; Wed, 18 Oct 2006 14:25:07 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9ILP4bL007423 for ; Wed, 18 Oct 2006 23:25:04 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F2FB.E001452B" Subject: ERS-08 - WG last call Date: Wed, 18 Oct 2006 23:25:01 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868704E8A@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS-08 - WG last call Thread-Index: Acby+97fuOJI2uOgQ/C3vFF9qDdS+Q== From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F2FB.E001452B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello,=20 as discussed on our last WG meeting in Montreal I again ask for a final WG last call to submit the document to the IESG. Please if possible send your comments until October 22. This way I can prepare a next version still within the cut-off day for San Diego on 23rd. Absolute deadline for the WG last call is two weeks: October 30th! Thanks, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C6F2FB.E001452B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ERS-08 - WG last call

Hello,

as = discussed on our last WG meeting in Montreal I again ask for a final WG = last call to submit the document to the IESG.

Please if possible send your comments = until October 22. = This way I can prepare a next version still within the cut-off day for = San Diego on 23rd.

Absolute deadline for the WG last call is two weeks: = October 30th!

Thanks, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

This = e-mail is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This e-mail may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above (“Authorized = Recipient”) for the purpose for which it was sent by OTC. All = other rights and licenses to this e-mail are fully reserved to OTC. If = you are not an Authorized Recipient, you are required to immediately = delete this e-mail in its entirety without printing, copying, using, = and/or re-transmitting this e-mail, either in whole or in part. The = transmission of this e-mail by OTC is not to be construed as a waiver by = OTC and/or the individual sending this e-mail on behalf of OTC of any of = their respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C6F2FB.E001452B-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJoFKD064313; Wed, 18 Oct 2006 12:50:15 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9IJoFcX064312; Wed, 18 Oct 2006 12:50:15 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJo7sT064257 for ; Wed, 18 Oct 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3D85F2ACEE; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001Ss-07; Wed, 18 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-validate-00.txt Message-Id: Date: Wed, 18 Oct 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Verification Data Author(s) : T. Gondrom Filename : draft-ietf-ltans-validate-00.txt Pages : 6 Date : 2006-10-18 Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-00.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-validate-00.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-validate-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18113905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-validate-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-validate-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18113905.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJoAxN064293; Wed, 18 Oct 2006 12:50:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9IJoAEl064292; Wed, 18 Oct 2006 12:50:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJo7Co064256 for ; Wed, 18 Oct 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 440592ACEF; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001Sv-0t; Wed, 18 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ari-00.txt Message-Id: Date: Wed, 18 Oct 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : LTANS Architecture Author(s) : T. Gondrom Filename : draft-ietf-ltans-ari-00.txt Pages : 10 Date : 2006-10-18 This documents outlines best practices how to use and integrate components based on the various specifications prepared by the LTANS WG for long term archiving and non-repudiation services can work together in a best practices environment. It especially takes care of the overall architecture and integration of the protocol and the data structures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ari-00.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-ari-00.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-ari-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18114322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ari-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ari-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18114322.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJo8vv064279; Wed, 18 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9IJo8Ib064278; Wed, 18 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9IJo7Jx064258 for ; Wed, 18 Oct 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3582C2ACEA; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQP-0001Sl-T2; Wed, 18 Oct 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-08.txt Message-Id: Date: Wed, 18 Oct 2006 15:50:01 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Evidence Record Syntax (ERS) Author(s) : R. Brandner, et al. Filename : draft-ietf-ltans-ers-08.txt Pages : 25 Date : 2006-10-18 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-08.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-08.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-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18113050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18113050.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I6qu8V085878; Tue, 17 Oct 2006 23:52:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9I6qukF085877; Tue, 17 Oct 2006 23:52:56 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9I6qtNl085865 for ; Tue, 17 Oct 2006 23:52:56 -0700 (MST) (envelope-from gm1970@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id C6E122A797C9 for ; Wed, 18 Oct 2006 08:52:48 +0200 (CEST) Received: from [87.123.31.193] (helo=[192.168.2.100]) by smtp05.web.de with asmtp (TLSv1:AES128-SHA:128) (WEB.DE 4.107 #114) id 1Ga5IG-0004li-00 for ietf-ltans@imc.org; Wed, 18 Oct 2006 08:52:48 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <41C67E25-0BE5-421A-AF07-004F742DDE93@web.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-ltans@imc.org From: =?ISO-8859-1?Q?Gerhard_M=FCller?= Subject: Date: Wed, 18 Oct 2006 08:52:44 +0200 X-Mailer: Apple Mail (2.752.2) X-Sender: gm1970@web.de Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: unsubscribe Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HKJDat039285; Tue, 17 Oct 2006 13:19:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9HKJDRT039284; Tue, 17 Oct 2006 13:19:13 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (mucmx02.ixos.de [149.235.128.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9HKJBTi039277 for ; Tue, 17 Oct 2006 13:19:12 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9HKJ8Lt020539; Tue, 17 Oct 2006 22:19:09 +0200 (MEST) 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="us-ascii" Subject: RE: next (hopefully final) revision (08) of ERS Date: Tue, 17 Oct 2006 22:19:08 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868704D75@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next (hopefully final) revision (08) of ERS Thread-Index: Acbx0Bh18YMQSpcsSh6jKTbLd3Vy9gAWEvHQ From: "Tobias Gondrom" To: "Tilo Kienitz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id k9HKJDTi039278 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Tilo, actually I did not intend to ignore your comment. I just thought that the answer Robert gave to your comment one day later was pretty good explaining why it does not make any real sense to sort the hashvalues by date and not in binary order. (especially as I did not see any further answer from you on that) And I and the other authors fully agree with Robert's analysis and arguments... If Robert or I am wrong please let me know. Tobias Ps.: maybe there is also a misunderstanding about this issue, so if you like to discuss this on the phone for a few minutes maybe we can exchange some arguments and see whether I missed s.th. or we can report to the mailing list that the question could be resolved or we need further dispute on that. (if you like you can give me a call at +498946291816) > -----Original Message----- > From: Tilo Kienitz [mailto:tk-tlslist@seccommerce.de] > Sent: Tuesday, October 17, 2006 11:39 AM > To: Tobias Gondrom > Cc: ietf-ltans@imc.org > Subject: Re: next (hopefully final) revision (08) of ERS > > Hello Tobias, > > if this is the final revision, then I assume that you do not intend > to answer on my e-mail from 16 June regarding the sorting of the > hash values? > > Kind regards > Tilo Kienitz > > > Tobias Gondrom wrote: > > Hi, > > > > I just completed the next revision of ERS and submitted it to the > > IETF-secretary. > > > > It contains the following changes as found by your reviews (thanks to > > Peter, Julien, Robert, Bill and Carl): > > > > 1. Split the reducedHashtree in SEQ of PartialHashtree for easier > > reading and better understanding > > > > 2. Set the tags [0] and [1] to ArchiveTimeStamp structure (and removed > > the EXPLICIT tags again as they are no longer necessary with the [0] and > > [1] to guarantee unambiguousness). > > > > So the total change is from: > > > > ArchiveTimeStamp ::= SEQUENCE { > > > > digestAlgorithm AlgorithmIdentifier OPTIONAL, > > > > reducedHashtree ***** [0] EXPLICIT* SEQUENCE OF SEQUENCE OF OCTET > > STRING OPTIONAL, > > > > timeStamp ContentInfo} > > > > > > added tag to: > > > > ArchiveTimeStamp ::= SEQUENCE { > > > > digestAlgorithm***** [0]* AlgorithmIdentifier OPTIONAL, > > > > reducedHashtree***** [1]* SEQUENCE OF***** PartialHashtree* OPTIONAL, > > > > timeStamp ContentInfo} > > > > > > > > *PartialHashtree ::= SEQUENCE OF OCTET STRING******* > > > > 3. Mentioned with the versioning of EvidenceRecord that default value is > > 1 and lower version numbers indicate it is a version prior this released > > document. > > > > 4. kept the IMPORTs as Russ made clear at the last WG meeting in > > Montreal that to remove them would result in rejection by the AD at > > submission. > > > > Thanks, Tobias Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9H9d7Yt074748; Tue, 17 Oct 2006 02:39:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9H9d7Qa074747; Tue, 17 Oct 2006 02:39:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail.seccommerce.de (mail.seccommerce.de [62.109.87.71]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9H9d4i6074739 for ; Tue, 17 Oct 2006 02:39:05 -0700 (MST) (envelope-from tk-tlslist@seccommerce.de) Received: (qmail 7373 invoked from network); 17 Oct 2006 09:45:04 -0000 Received: from unknown (HELO ?10.1.0.170?) (10.1.0.170) by 0 with RC4-MD5 encrypted SMTP; 17 Oct 2006 09:45:04 -0000 Message-ID: <4534A49F.4060604@seccommerce.de> Date: Tue, 17 Oct 2006 11:38:39 +0200 From: Tilo Kienitz User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Gondrom CC: ietf-ltans@imc.org Subject: Re: next (hopefully final) revision (08) of ERS References: <2666EB2A846BAC4BB2D7F593301A7868704BC9@MUCXGC2.opentext.net> In-Reply-To: <2666EB2A846BAC4BB2D7F593301A7868704BC9@MUCXGC2.opentext.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Tobias, if this is the final revision, then I assume that you do not intend to answer on my e-mail from 16 June regarding the sorting of the hash values? Kind regards Tilo Kienitz Tobias Gondrom wrote: > Hi, > > I just completed the next revision of ERS and submitted it to the > IETF-secretary. > > It contains the following changes as found by your reviews (thanks to > Peter, Julien, Robert, Bill and Carl): > > 1. Split the reducedHashtree in SEQ of PartialHashtree for easier > reading and better understanding > > 2. Set the tags [0] and [1] to ArchiveTimeStamp structure (and removed > the EXPLICIT tags again as they are no longer necessary with the [0] and > [1] to guarantee unambiguousness). > > So the total change is from: > > ArchiveTimeStamp ::= SEQUENCE { > > digestAlgorithm AlgorithmIdentifier OPTIONAL, > > reducedHashtree ***** [0] EXPLICIT* SEQUENCE OF SEQUENCE OF OCTET > STRING OPTIONAL, > > timeStamp ContentInfo} > > > added tag to: > > ArchiveTimeStamp ::= SEQUENCE { > > digestAlgorithm***** [0]* AlgorithmIdentifier OPTIONAL, > > reducedHashtree***** [1]* SEQUENCE OF***** PartialHashtree* OPTIONAL, > > timeStamp ContentInfo} > > > > *PartialHashtree ::= SEQUENCE OF OCTET STRING******* > > 3. Mentioned with the versioning of EvidenceRecord that default value is > 1 and lower version numbers indicate it is a version prior this released > document. > > 4. kept the IMPORTs as Russ made clear at the last WG meeting in > Montreal that to remove them would result in rejection by the AD at > submission. > > Thanks, Tobias Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9GBuKFq058955; Mon, 16 Oct 2006 04:56:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9GBuKt7058954; Mon, 16 Oct 2006 04:56:20 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9GBuIGB058944 for ; Mon, 16 Oct 2006 04:56:19 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from MUCXGC2.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id k9GBuFJO026019 for ; Mon, 16 Oct 2006 13:56:16 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F11A.154D31BD" Subject: next (hopefully final) revision (08) of ERS Date: Mon, 16 Oct 2006 13:56:15 +0200 Message-ID: <2666EB2A846BAC4BB2D7F593301A7868704BC9@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next (hopefully final) revision (08) of ERS Thread-Index: AcbxGhTFa46dmQJHSOeFsomvO0J5cg== From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F11A.154D31BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I just completed the next revision of ERS and submitted it to the IETF-secretary. It contains the following changes as found by your reviews (thanks to Peter, Julien, Robert, Bill and Carl): 1. Split the reducedHashtree in SEQ of PartialHashtree for easier reading and better understanding 2. Set the tags [0] and [1] to ArchiveTimeStamp structure (and removed the EXPLICIT tags again as they are no longer necessary with the [0] and [1] to guarantee unambiguousness). So the total change is from:=20 ArchiveTimeStamp ::=3D SEQUENCE { digestAlgorithm AlgorithmIdentifier OPTIONAL, reducedHashtree [0] EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING OPTIONAL, timeStamp ContentInfo} added tag to: ArchiveTimeStamp ::=3D SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} =20 PartialHashtree ::=3D SEQUENCE OF OCTET STRING 3. Mentioned with the versioning of EvidenceRecord that default value is 1 and lower version numbers indicate it is a version prior this released document. 4. kept the IMPORTs as Russ made clear at the last WG meeting in Montreal that to remove them would result in rejection by the AD at submission. Thanks, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 This e-mail is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This e-mail may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this e-mail are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this e-mail in its entirety without printing, copying, using, and/or re-transmitting this e-mail, either in whole or in part. The transmission of this e-mail by OTC is not to be construed as a waiver by OTC and/or the individual sending this e-mail on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C6F11A.154D31BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable next (hopefully final) revision (08) of ERS

Hi,

I = just completed the next revision of ERS and submitted it to = the IETF-secretary.

It = contains the following changes as found by your reviews (thanks to = Peter, Julien, Robert, Bill and Carl):

1. = Split the reducedHashtree in SEQ of PartialHashtree for easier reading = and better understanding

2. = Set the tags [0] and [1] to ArchiveTimeStamp structure (and removed the = EXPLICIT tags again as they are no longer necessary with the [0] and [1] = to guarantee unambiguousness).

So = the total change is from:

ArchiveTimeStamp ::=3D SEQUENCE {

  digestAlgorithm    AlgorithmIdentifier = OPTIONAL,

  reducedHashtree   [0] = EXPLICIT SEQUENCE OF SEQUENCE OF OCTET STRING   = OPTIONAL,

  timeStamp         = ContentInfo}


added = tag to:

ArchiveTimeStamp ::=3D SEQUENCE = {

  digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,

  reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,

  timeStamp       = ContentInfo}

    =

PartialHashtree ::=3D SEQUENCE OF OCTET = STRING

3. = Mentioned with the versioning of EvidenceRecord that default value is 1 = and lower version numbers indicate it is a version prior this released = document.

4. = kept the IMPORTs as Russ made clear at the last WG meeting in Montreal = that to remove them would result in rejection by the AD at = submission.

Thanks, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

This = e-mail is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This e-mail may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above (“Authorized = Recipient”) for the purpose for which it was sent by OTC. All = other rights and licenses to this e-mail are fully reserved to OTC. If = you are not an Authorized Recipient, you are required to immediately = delete this e-mail in its entirety without printing, copying, using, = and/or re-transmitting this e-mail, either in whole or in part. The = transmission of this e-mail by OTC is not to be construed as a waiver by = OTC and/or the individual sending this e-mail on behalf of OTC of any of = their respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C6F11A.154D31BD-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99LYb3O002447; Mon, 9 Oct 2006 14:34:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k99LYbBC002446; Mon, 9 Oct 2006 14:34:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99LYaZr002439 for ; Mon, 9 Oct 2006 14:34:37 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 3C1B52AC70; Mon, 9 Oct 2006 21:34:31 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX2lb-0001Ld-0Q; Mon, 09 Oct 2006 17:34:31 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Long-Term Archive Service Requirements' to Informational RFC (draft-ietf-ltans-reqs) Reply-To: iesg@ietf.org Cc: Message-Id: Date: Mon, 09 Oct 2006 17:34:31 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The IESG has received a request from the Long-Term Archive and Notary Services WG to consider the following document: - 'Long-Term Archive Service Requirements ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-09.txt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99Jo88V091155; Mon, 9 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k99Jo8QA091154; Mon, 9 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k99Jo8aj091140 for ; Mon, 9 Oct 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 89104175BC; Mon, 9 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GX18U-0007Qk-42; Mon, 09 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-09.txt Message-Id: Date: Mon, 09 Oct 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-Term Archive Service Requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-09.txt Pages : 19 Date : 2006-10-9 There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-09.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-reqs-09.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-reqs-09.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-9113900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-9113900.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96Jo8Ci089308; Fri, 6 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k96Jo8pc089306; Fri, 6 Oct 2006 12:50:08 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96Jo787089291 for ; Fri, 6 Oct 2006 12:50:08 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 4A58626E6B; Fri, 6 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVvhq-000225-3h; Fri, 06 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-08.txt Message-Id: Date: Fri, 06 Oct 2006 15:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Long-Term Archive Service Requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-08.txt Pages : 19 Date : 2006-10-6 There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-08.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-reqs-08.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-reqs-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-6110420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-6110420.I-D@ietf.org> --OtherAccess-- --NextPart--