From owner-ietf-ltans Fri Oct 1 05:44:50 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CiohC026060; Fri, 1 Oct 2004 05:44:50 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Cio1l026059; Fri, 1 Oct 2004 05:44:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CineZ026051 for ; Fri, 1 Oct 2004 05:44:49 -0700 (PDT) (envelope-from wwilbur@orionsec.com) Received: from wwwilbur (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i91Ciaql020490 for ; Fri, 1 Oct 2004 08:44:50 -0400 Message-Id: <200410011244.i91Ciaql020490@host13.websitesource.com> From: "Warren Wilbur" To: Subject: Proposal for using WebDAV to implement a trusted archive server Date: Fri, 1 Oct 2004 08:44:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C4A792.E9E8D2F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcSntGfq2EulBARZSiisZPDB5DHExQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C4A792.E9E8D2F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I'm new to the LTANS community but I understand that someone has suggested using the WebDAV protocol to implement a long term archive. I've spent some time thinking about whether this would be desirable/feasible and would like to hear your opinion on that. 1. Why use WebDAV? WebDAV is already supported on Microsoft Windows and Linux as a virtual mounted drive. The archive _could_ be designed to allow users the convenience of using their favorite application to file/save and file/load their data directly to and from the archive server. The popular Apache web server includes a module supporting WebDAV which allows the implementer to implement an arbitrary back end for WebDAV data storage (i.e. file system, database, etc.). WebDAV already provides the basic functionality of a file archive through it's GET, PUT, MKCOL (i.e. mkdir), COPY, MOVE, DELETE, LOCK, UNLOCK, PROPFIND (property find), and PROPPATCH (property write/create) operations. WebDAV properties can be associated with data objects and collection objects (i.e. collections are similar to directories). WebDAV creates a namespace very similar to the hierarchical directory structure used in a file-system but allows the user to declare and manage arbitrary properties for each file or collection. 2. How would the basic requirements of LTANS be implemented using WebDAV? Submit data - PUT (creates or overwrites a data object in the WebDAV archive) Retrieve data - GET (reads a data object in the WebDAV archive) Delete data - DELETE (removes a data object from the WebDAV archive) Specify/extend archivation period - PROPPATCH (store the 'archivation period' in metadata associated with data object) Request/response authentication - Using Apache with mod_dav to host WebDAV allows a large list of authentication methods for secure communication with users. Delete must be authenticated - Each individual WebDAV command (e.g. DELETE) may be individually restricted. Submitting data together with previously generated evidence - PUT and PROPPATCH (evidence placed in metadata associated with data object) Providing evidence records for data objects - PROPFIND (get the evidence in metadata associated with data object) Work efficiently even for large amounts of archived data objects - Using the Apache webserver to provide WebDAV allows the use of an industrial strength server. Support for evidence that applies to a collection of data objects - PROPPATCH/PROPFIND on the properties of the containing collection object NOTE: The 'archivation period' and 'evidence' associated with a data object should be implemented using WebDAV properties associated with each data object. Trusted archive client software would have to be provided to support WebDAV property management (i.e. using PROPFIND/PROPPATCH) for the data objects in the archive. NOTE2: For each WebDAV operation the URI of the resource must be specified. Most WebDAV operations will also work on a collection (i.e. dir) if that is specified. 3. How can we store binary evidence data using WebDAV properties? WebDAV stores unbound file metadata as XML properties. XML cannot store binary data without a conversion into one of the supported character sets specified in the XML standard. Binary data must be converted or the XML parser will halt with an error as soon as it encounters an invalid character for the specified character set. There are a number of common conversion methods (e.g. base64, Huffman coding, etc.) but none of them are as efficient as leaving the data in binary form. Having binary data in the data object isn't a problem. For the properties associated with the data object binary data must be converted. Summary: WebDAV can provide the basic archive services required for LTANS. Further work must be done to map the server's evidence preservation activities into the WebDAV model. This is just a rough cut at trying to provide a mapping of the LTANS requirements onto WebDAV. If this idea is accepted favorably then I would recommend additional research on WebDAV and the preparation of a more detailed proposal. It would be nice to have a proposal that includes detailed use cases to explain how WebDAV structures would be managed. I will look forward to your feedback and would be willing to further develop these concepts... Warren Wilbur Orion Security Solutions, Inc. wwilbur@orionsec.com 703-917-0060 x34 ------=_NextPart_000_0065_01C4A792.E9E8D2F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi,

Hi,

 

I’m new to the LTANS community but I understand = that someone has suggested using the WebDAV protocol to implement a long term = archive. I’ve spent some time thinking about whether this would be desirable/feasible and would like to hear your opinion on = that.

 

1. Why use WebDAV?

 

WebDAV is already supported on Microsoft Windows and = Linux as a virtual mounted drive. The archive _could_ be designed to allow = users the convenience of using their favorite application to file/save and = file/load their data directly to and from the archive server. The popular Apache = web server includes a module supporting WebDAV which allows the implementer = to implement an arbitrary back end for WebDAV data storage (i.e. file = system, database, etc.). WebDAV already provides the basic functionality of a = file archive through it’s GET, PUT, MKCOL (i.e. mkdir), COPY, MOVE, = DELETE, LOCK, UNLOCK, PROPFIND (property find), and PROPPATCH (property = write/create) operations. WebDAV properties can be associated with data objects and collection = objects (i.e. collections are similar to directories). WebDAV creates a = namespace very similar to the hierarchical directory structure used in a file-system = but allows the user to declare and manage arbitrary properties for each file = or collection.

 

2. How would the basic requirements of LTANS be = implemented using WebDAV?

 

Submit data – PUT (creates or overwrites a data = object in the WebDAV archive)

Retrieve data – GET (reads a data object in the = WebDAV archive)

Delete data – DELETE (removes a data object = from the WebDAV archive)

Specify/extend archivation period – PROPPATCH = (store the ‘archivation period’ in metadata associated with data = object)

Request/response authentication – Using Apache = with mod_dav to host WebDAV allows a large list of authentication methods for = secure communication with users.

Delete must be authenticated – Each individual = WebDAV command (e.g. DELETE) may be individually = restricted.

Submitting data together with previously generated = evidence – PUT and PROPPATCH (evidence placed in metadata associated with = data object)

Providing evidence records for data objects – = PROPFIND (get the evidence in metadata associated with data = object)

Work efficiently even for large amounts of archived = data objects – Using the Apache webserver to provide WebDAV allows the = use of an industrial strength server.

Support for evidence that applies to a collection of = data objects – PROPPATCH/PROPFIND on the properties of the containing collection object

 

NOTE: The ‘archivation period’ and ‘evidence’ associated with a data object should be = implemented using WebDAV properties associated with each data object. Trusted = archive client software would have to be provided to support WebDAV property = management (i.e. using PROPFIND/PROPPATCH) for the data objects in the = archive.

NOTE2: For each WebDAV operation the URI of the = resource must be specified. Most WebDAV operations will also work on a collection = (i.e. dir) if that is specified.

 

3. How can we store binary evidence data using WebDAV properties?

 

WebDAV stores unbound file metadata as XML = properties. XML cannot store binary data without a conversion into one of the supported = character sets specified in the XML standard. Binary data must be converted or the = XML parser will halt with an error as soon as it encounters an invalid = character for the specified character set. There are a number of common conversion methods (e.g. base64, Huffman coding, etc…) but none of them are = as efficient as leaving the data in binary form. Having binary data in the = data object isn’t a problem. For the properties associated with the = data object binary data must be converted.

 

Summary: WebDAV can provide the basic archive = services required for LTANS. Further work must be done to map the server’s evidence preservation activities into the WebDAV = model.

 

 

This is just a rough cut at trying to provide a mapping of the LTANS requirements onto = WebDAV. If this idea is accepted favorably then I would recommend additional = research on WebDAV and the preparation of a more detailed proposal. It would be nice = to have a proposal that includes detailed use cases to explain how WebDAV structures would be managed. I will look forward to your feedback and = would be willing to further develop these = concepts...

 

Warren Wilbur

Orion Security Solutions, Inc.

wwilbur@orionsec.com<= /span>

703-917-0060 x34

 

------=_NextPart_000_0065_01C4A792.E9E8D2F0-- From owner-ietf-ltans Fri Oct 1 08:11:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FBHdl034818; Fri, 1 Oct 2004 08:11:17 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FBHnH034817; Fri, 1 Oct 2004 08:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FBAmV034785 for ; Fri, 1 Oct 2004 08:11:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA39370; Fri, 1 Oct 2004 17:22:31 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100117110495:1397 ; Fri, 1 Oct 2004 17:11:04 +0200 Message-ID: <415D7388.3000003@bull.net> Date: Fri, 01 Oct 2004 17:11:04 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: ietf-ltans@imc.org CC: Tobias Gondrom , Carl Wallace Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <3C1BE8610E44734499EF92FB35F5B0702C6645@MUCXGC1.opentext.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:11:05, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:11:06, Serialize complete at 01/10/2004 17:11:06 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91FBCmV034805 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hello friends, > the first document of our working group is coming to a final state. > I asked Carl and the authors of the document to integrate the input of > the last discussions inspired by Denis into the document so that we get > to a final version. From my feeling the discussion here on the > mailing-list has come to the time of conclusion about the requirements > for long-term archive. I do no have that feeling yet. Until we agree on this document, a Last Call for the ERS document would be premature. > Many discussions and ideas have been presented. > For me it was very insightful and interesting to learn the different > views and requirements from all over the world. We took our time for all > the aspects, now I think we can move to a conclusion with this document > so that we can lead our discussions concerning the Notary Services > easier. We still need to agree on what is or is not a Notary Service, but we have not finished the discussion on the requirements for a long-term archive service. > I think that Carl, Ulrich and Ralf did a good job on this and > hope that you agree. > So I start the WG LAST CALL for our first WG document: > "draft-ietf-ltans-reqs-02.txt" > I declare WG Last Call (period 2 weeks) terminating at 7th October 2004 > 12:00 EST. You will find my comments below: It is believed that the last call was made to force comments to be done shortly, since the document is not yet mature. All the comments below are focussed on usage of cryptography for the short and long term, thus concerns like longevity of the storage media (although very important) are not considered. The following comments are thus offered: 1. Abstract The abstract is not correct and should be changed. The document misses to indicate that it is necessary to demonstrate the origin of the data and that the document has been placed in a storage before a given date so that even the system engineers in charge of the archive system do not have the possibility to modify any more stored documents. It is proposed to delete the present abstract and to replace it with: “This document specifies the technical requirement for long-term archive services able to support non repudiation of data origin with integrity and existence of data at a given time. Data to be stored and retrieved may include signed data. Long-term archive services operate under an archive policy which will need to be periodically redefined as the time goes. This document specifies the main constituents of an archive policy”. In fact the main constituents of an archive policy still need to be defined. The following comments focus on one of the components of an archiving policy, i.e. the cryptographic maintenance policy, so the work still needs to be done. 2. Introduction The second paragraph needs to be revisited (besides the two typos in the first sentence) because it is too vague. Proposed replacement: “A long term archive service accepts data from users. This data may be confidential data or public data. When it is confidential data, it is the responsibility of users only to take care of the confidentiality of the data they submit. If users care that their data shall not have its semantics disclosed to the system engineers from the long term archive service, then they shall take care themselves of the protection of their data. When data is confidential data, it is important that submitters can check for themselves: - that the data was placed in a server from the long-term archive service, - that the data has been unmodified since the time of its placement (*), and - that the data originates from them (either symmetric or asymmetric cryptography may be used). (*) more precisely a proof of existence of data at a given time preceding the archival time, to demonstrate that the data was placed in a server from the long-term archive before that time. When the data is public data, it is important to be able to demonstrate to someone else (i.e. obtain a non-repudiation evidence): - that the data was placed in a server from the long-term archive service, - that the data has been unmodified since the time of its placement, and - that the data originally placed originates from a given entity (different from servers belonging to the long-term archive service). Note: that entity may or may not be a Notary. Since the document addresses long term storage, transfer from one data storage unit to another may happen. Retrieval of data may thus be done from a server different from the server where the data was originally stored. It is therefor important to attach the security to the data itself and not to rely only on the security mechanisms and procedures performed by the server where the data is stored or retrieved. Two non-repudiation evidences will need to be provided: - a first one to demonstrate to third parties the data originally placed originates from a given entity, - a second one to demonstrate to third parties that the data was originally accepted for storage, at a given time, by a server belonging to a given long-term archive service. Since these evidences will be provided using cryptographic means, it is important to maintain the cryptographic quality of theses evidences, even if the signature policy under which the signatures have been done has expired. A signature policy cannot last longer than the resistance of the root keys used in that policy, so it will always be limited in time. Some CA keys used to validate an electronic signature may last in practice shorter that the end of the validity period of a signature policy. So it is important to be able to maintain their validity beyond the end of the validity period of the signature policy. This cryptographic maintenance activity is part of the responsibilities of a long-term archive service and will be performed according to one or more cryptographic maintenance policies.” 3. Introduction The third paragraph needs to be revisited because it is inappropriate. Validation of assertions of agreements originally asserted with digital signatures is not a task that is within the scope of a long-term archive service. Proposed replacement: “A long-term archive service may optionally support a service able to check an evidence demonstrating that an archive package has been originally accepted for storage, at a given time, by a server belonging to another given long-term archive service.” 4. Introduction The first sentence from last (i.e. fifth) paragraph from page 3 needs to be revisited because it is to vague (what is the “something ?”). Delete the first sentence. 5. Introduction The very last sentence from the paragraph from page 3 needs to be revisited because it is too vague. Since notarization is an undefined or controversial term, it cannot be said that it will or will not be covered in this document. It is proposed to delete that sentence and not to use the words notarization and notary at any place within this document. 6. Terminology The overall new terminology looks fine. However, it would be useful to introduce three new terms: Cryptographic maintenance policy: a named set of rules that defines how to maintain the validity of digitally signed objects should one of the hash functions or asymmetrical algorithm used to create a digital signature of a signed object become weak or one of the private keys used to create a digital signature of a signed object be compromised or become weak. Critical cryptographic parameters: collection of cryptographic parameters, together with their associated parameters, if any (e.g. key lengths), associated with data, to be used to maintain the validity of digitally signed objects under a cryptographic maintenance policy. Cryptographic maintenance parameters: Critical cryptographic parameters together with a reference to a cryptographic maintenance policy. 7. General Principles Starting from the second sentence on page 6, the text needs to be revisited, since the text is only addressing one case out of two. As mentioned previously two non-repudiation evidences may be attached to a given archived data object. These non-repudiation evidences will need to be maintained over time. If the data object that is submitted does not include an evidence to demonstrate to third parties the data originally placed originates from a given entity, then it is correct to say that the data object is opaque. However, this is no more the case, when the data object that is submitted includes an evidence to demonstrate to third parties the data originally placed originates from a given entity. The “conclusion” made in the third paragraph is therefor incorrect. A long-term archive service may need to operate in accordance with the content of the archived data objets. In addition, as said earlier, since notarization is an undefined or controversial term, it should not be used at any place within this document. Proposed replacement for both the second and third paragraphs: “A long-term archive service may operate in two modes: - a passive mode, where the archived data object is an opaque collection of bytes, or/and - an active mode, where the archived data object is associated with cryptographic maintenance parameters. When operating is the active mode, a long-term archive service has to apply a cryptographic maintenance policy on archived data objects using the critical cryptographic parameters associated with every archived data object. When operating either in the passive or the active mode, a long-term archive service has to apply a cryptographic maintenance policy on the archived packages using the cryptographic maintenance parameters associated with a set of archived packages”. 8. General Principles The text from the last sentence, on page 6, needs to be revisited. Proposed replacement: “ A long term archive service provides material that may be used to demonstrate the existence at a given time of archived data objects, and both the integrity and authenticity of these archived data objects (i.e. that they originate from servers under the responsibility of a given long term archive service.” 9. Section 4. Technical requirements This section describes, quite well, the functions dedicated to storage and retrieval. However, it currently misses to describe the functions associated with the use of cryptographic maintenance policies and cryptographic maintenance parameters which are always associated with archived packages and with critical security parameters which may be associated with archived data objects. In order to fill-in this gap, some text in provided below: “4.X Cryptographic maintenance 4.X.1 Functional requirements A long term archive service must maintain the cryptographic validity of its evidence records. It needs to perform the following basic operations: - attach cryptographic maintenance parameters to one or a set of archived packages, - apply the cryptographic maintenance policy referenced within the cryptographic maintenance parameters to maintain the validity of its evidence records using the critical cryptographic parameters, - periodically apply the original cryptographic maintenance policy using the critical cryptographic parameters, - periodically apply a new cryptographic maintenance policy should the previous cryptographic maintenance policy become weak or inappropriate. When an archived data objet is submitted to a long term archive service with cryptographic maintenance parameters, then the long term archive service shall either maintain the cryptographic validity of that archived data objet or refuse to accept the service. If it accepts, then it needs to perform the following basic operations: - apply the cryptographic maintenance policy requested by the submitter within the cryptographic maintenance parameters and maintain the validity of the archived data objet according to that cryptographic maintenance policy using the critical cryptographic parameters that are present in the cryptographic maintenance policy associated with the archived data objet, - periodically apply the original cryptographic maintenance policy that has been used in accordance with the critical cryptographic parameters, - periodically apply a new cryptographic maintenance policy if the previous cryptographic maintenance policy becomes too weak or inappropriate. 4.X.1 Rational Maintenance of the validity of archived packages is a necessary basic function of a long-term archive service. Maintenance of the validity of archived data objets is an optional function of a long-term archive service”. 10. A new section should be introduced to address the requirement of some data structures. Proposed text; “ Y. Requirements on some data objects Y.1 Requirements on cryptographic maintenance policies A cryptographic maintenance policy: - must be unambiguously identified by an object identifier (e.g. an OID), - must include a validity period, - must specify how the necessary bindings to the time scale will be guaranteed, for example it can specify the Time-Stamping Units (TSU) recognized under that policy, - may unambiguously reference a sequence of one or more previously defined cryptographic maintenance policies. Y.2 Requirements on critical cryptographic parameters Critical cryptographic parameters shall include data objects describing all the algorithms, and the associated key lengths used in the object to which the critical cryptographic parameters are associated. These data objects may be in the form of data objects identified using an OID, and may include one or more algorithm specific parameters. Y.3 Requirements on cryptographic maintenance parameters Cryptographic maintenance parameters shall include two components: - critical cryptographic parameters, and - an unambiguous reference to one cryptographic maintenance policy. 11. In formation should be added to address cryptographic maintenance issues in case a hash function exhibits collisions. Proposed text to be included in the security considerations section: “Cryptographic maintenance issues in case a hash function exhibits collisions Submitters may submit: 1) signed data and their associated signatures, or 2) signatures only (i.e. without the signed data). In case the hash function used to compute the digital signature over the original data exhibits collisions, it is necessary to recompute a hash of that original data using another hash function. This is not feasible if signatures only are submitted (i.e. without the signed data)”. 12. Minor comment on section 4.2.1. page 8. The first sentence is too vague since “non-repudiation of data” is not a well defined service. It is believed it is meant there something like: “non-repudiation of the fact that some data was placed in a server from the long-term archive service, and that the data has been unmodified since the time of its placement”. A similar change should be done in section 4.2.2. 13. Comment on section 4.3. page 8. This section is confusing since the previous one already covers data integrity. Its text should be merged with the previous section. 14. Comment on section 4.4.1 page 9. This section introduces the term “long-term archive service policy”. Since the concept of cryptographic maintenance policy has now be introduced, it would be more exact to say that the “characteristics such as quality of the time-stamps” are part of the cryptographic maintenance policy, which itself may be part of a long-term archive service policy. The text should be changed accordingly. 15. Comment on section 6 page 12. The second paragraph should be modified to refer to the cryptographic maintenance policy. Note: the very last sentence of the section is very true, but should be moved in the main body of the document with additional explanations, since the chain of policies has also to do with a chain of cryptographic maintenance policies. END OF COMMENTS Denis > Best regards > > Tobias > Chair of LTANS > > > > Ps.: Small remark: Soon after completion of this Last Call I prepare to > start the Last Call for the ERS document so that we can focus our work > fully on the notary services problems at the 61st IETF meeting in > November. > > > > >>-----Original Message----- >>From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > >>On Behalf Of Internet-Drafts@ietf.org >>Sent: Tuesday, September 21, 2004 9:39 PM >>To: i-d-announce@ietf.org >>Cc: ietf-ltans@imc.org >>Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Long-Term Archive and Notary Services >>Working Group of the IETF. >> >> Title : Long term archive service requirements >> Author(s) : C. Wallace, et al. >> Filename : draft-ietf-ltans-reqs-02.txt >> Pages : 17 >> Date : 2004-9-21 >> >>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 technical requirements >>for a long-term archive service to support such scenarios. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.txt >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the > >>message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the >>username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-ltans-reqs-02.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-ltans-reqs-02.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. > > From owner-ietf-ltans Fri Oct 1 08:35:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FZGUD036459; Fri, 1 Oct 2004 08:35:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FZGc4036458; Fri, 1 Oct 2004 08:35:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FZEXP036446 for ; Fri, 1 Oct 2004 08:35:15 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i91FYcNp001474; Fri, 1 Oct 2004 17:34:39 +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: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Date: Fri, 1 Oct 2004 17:34:36 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0702C694D@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Thread-Index: AcSnyO2DoDG7ilmtTgSZ0qgDLJ7gzAAAjO/Q From: "Tobias Gondrom" To: "Denis Pinkas" Cc: "Carl Wallace" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91FZFXP036451 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, a small remark to your first comment in advance Concerning your comments, I will not be able to study them before Monday, but maybe others are faster. > > the first document of our working group is coming to a final state. > > I asked Carl and the authors of the document to integrate the input of > > the last discussions inspired by Denis into the document so that we get > > to a final version. From my feeling the discussion here on the > > mailing-list has come to the time of conclusion about the requirements > > for long-term archive. > > I do no have that feeling yet. Until we agree on this document, a Last > Call for the ERS document would be premature. It seems that you misunderstood my mail: I have been talking about the discussion about the requirements document not the ERS (although this is also very stable too in my eyes) - Of course I want to open the last call for the ERS _after_ closing the last call for reqs and making sure that we finish this document first. Best regards Tobias From owner-ietf-ltans Fri Oct 1 08:55:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Ftk1d037612; Fri, 1 Oct 2004 08:55:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Ftkxh037611; Fri, 1 Oct 2004 08:55:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Ftjef037601 for ; Fri, 1 Oct 2004 08:55:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA21378; Fri, 1 Oct 2004 18:07:08 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100117554060:1417 ; Fri, 1 Oct 2004 17:55:40 +0200 Message-ID: <415D7DFC.4030509@bull.net> Date: Fri, 01 Oct 2004 17:55:40 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Tobias Gondrom CC: IETF LTANS Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <3C1BE8610E44734499EF92FB35F5B0702C694D@MUCXGC1.opentext.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:55:40, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:55:43, Serialize complete at 01/10/2004 17:55:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, > Denis, > a small remark to your first comment in advance > Concerning your comments, I will not be able to study them before. > Monday, but maybe others are faster. I would suggest that you wait until the end of the last call comment period before answering. >> the first document of our working group is coming to a final state. >> I asked Carl and the authors of the document to integrate the input >> of he last discussions inspired by Denis into the document so that we >> get to a final version. From my feeling the discussion here on the >> mailing-list has come to the time of conclusion about the >> requirements for long-term archive. >>I do no have that feeling yet. Until we agree on this document, a Last >>Call for the ERS document would be premature. > It seems that you misunderstood my mail: > I have been talking about the discussion about the requirements document > not the ERS (although this is also very stable too in my eyes) - > Of course I want to open the last call for the ERS _after_ closing > the last call for reqs and making sure that we finish this document > first. I guess you do not mean mean, "_after_ closing the last call for reqs" since it will be closed on tuesday, but until the reqs document has passed the IESG Last Call. This does not prevent to progress the ERS draft, as well as other drafts, if needed, but the focus should be kept first on the requirements. Regards, Denis > Best regards > > Tobias > From owner-ietf-ltans Fri Oct 1 09:53:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GruL7041630; Fri, 1 Oct 2004 09:53:56 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91GruOP041629; Fri, 1 Oct 2004 09:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GrtFF041599 for ; Fri, 1 Oct 2004 09:53:55 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i91GrkN08082; Fri, 1 Oct 2004 18:53:46 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 1 Oct 2004 18:53:46 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i91Grkp23823; Fri, 1 Oct 2004 18:53:46 +0200 (MEST) Date: Fri, 1 Oct 2004 18:53:46 +0200 (MEST) From: Peter Sylvester Message-Id: <200410011653.i91Grkp23823@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I seem to agree with many of Denis remarks, unfortuntely I don't have the time to answer before Tuesday, very late for personal reasons. So I just make one remark (a detail) > Since these evidences will be provided using cryptographic means, it is > important to maintain the cryptographic quality of theses evidences, even if > the signature policy under which the signatures have been done has expired. I seem to have a wording problem here: IMO The evidence may be PROTECTED by cryptographic means. Not provided? In general, the document seems mainly to address interfaces to some backend, and not really front end user interface, some elements being things mentioned by denis as: - a first one to demonstrate to third parties the data originally placed originates from a given entity, - a second one to demonstrate to third parties that the data was originally accepted for storage, at a given time, by a server belonging to a given long-term archive service. Denis proposes a lot of new text, which I think should be carefully read and combined with the current req if we agree all on that. Peter Off to homeland :-) From owner-ietf-ltans Sat Oct 2 14:11:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92LBhsk055642; Sat, 2 Oct 2004 14:11:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92LBhHx055623; Sat, 2 Oct 2004 14:11:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [64.18.1.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i92LBf1v055591 for ; Sat, 2 Oct 2004 14:11:41 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 14:11:43 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i92LBUbA022006 for ; Sat, 2 Oct 2004 14:11:35 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i92LBKkq024440 for ; Sat, 2 Oct 2004 14:11:30 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007DO6UVE3@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 02 Oct 2004 14:11:20 -0700 (PDT) Date: Sat, 02 Oct 2004 14:11:19 -0700 From: Larry Masinter Subject: editorial comments on draft-ietf-ltans-reqs-02.txt To: ietf-ltans@imc.org Message-id: <0I4Z007DP6UVE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSoxFwtXP/JKGrYSb+OFNlx1fxTAQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: These are mainly editorial comments; the only non-editorial comments are marked with ****. I also have a number of questions which might turn into substantive comments depending on what was meant. I'm sorry for the length, but I thought I should do a careful review: Title: Long-Term Archive Service Requirements It's traditional to capitalize words (except prepositions) in titles. I think "Long-Term" is better than "Long Term" throughout the document (used inconsistently). =============== Abstract In many scenarios, users need to be able to prove the existence of data at a given time and integrity of data, especially digitally signed data, in a common and reproducible way after an arbitrarily long period. This document specifies the technical requirements for a long-term archive service to support such scenarios. This is a little hard to parse and perhaps misleading; the document should describe long-term archive services and provide the technical requirements for Internet protocols that interact with such services. I would suggest: # There are many scenarios in which users, even after an arbitrarily # long period of time, will need to prove the original existance of # data and the integrity of that data in the duration. In addition, # there are requirements to prove the original validity of the # signatures of digitally signed data, even after an arbitrarily # long period. This document describes a class of long-term archive # services which support such scenarios, and the technical requirements # for protocols for interacting with such services. =============== 1. Introduction Digital data durability is undermined by continual progress and change on a number of fronts. The useful lifetime of data may exceed the life span of formats and mechanisms used to store the data. The lifetime of digitally signed data may exceed the validity periods of public-key certificates used to verify signatures or the cryptanalysis period of the cryptographic algorithms used to generate the signatures. I think you mean 'required lifetime' instead of 'useful lifetime' (in sentence 2) and 'lifetime' in sentence 3. =============== "...external service accessible via an internet" perhaps "via the Internet". =============== "... credible assertion of something that is currently asserted at points well into the future." I suggest # ... credible assertion, at points well into the future, of something # that is currently asserted. or just put a comma between "asserted at" above. =============== Section 2: I think this section could use a preface, e.g., # We define the following terms based on their usage in the archiving # community, in order to provide a vocabulary for describing requirements # and the standards around them. =============== "Arbitrator" is defined but not used. =============== An evidence record may include acknowledgements from a LTA I suggest writing out 'long-term archive service' here, since it is a forward reference. =============== You might want to define 'attestation'. =============== "Originator" is defined but not used. If you keep it, 'object.The' missing a space. =============== Timestamp: A signed attestation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies a structure for timestamps and a protocol for communicating with a Timestamp Authority (TSA). I think it would be better to use the definitions from RFC 3161 rather than redefine the terms. RFC 3161 uses "time-stamp" and not "timestamp", but defines 'time-stamp token'. Is it appropriate to insist that long-term archive services use RFC 3161 (i.e., are we defining a 'time-stamp' as a RFC 3161 signed time-stamp token) or are we just using RFC 3161 as an example? I would suggest # Time-stamp: An attestation generated by a Time Stamping # Authority (TSA) that a data item existed at a certain time. # For example, [RFC 3161] specifies a structure for signed # time-stamp tokens as part of a protocol for communicating # with a Time-Stamp Authority (TSA). # Time-Stamp Authority (TSA): A trusted service that provides # attestations of existance of data at particular points in # time. For example, [RFC 3161] defines protocol elements for # interacting with a TSA. =============== In general, we should double check spelling and terminology and try to be a little more consistent with RFC 3161, at least if the intent is to talk about the same thing. =============== 3. General principles A long-term archive service may accept any type of data for preservation, including digitally signed data, encrypted data, time stamped data, data that has not been the subject of any cryptographic processing, textual data or images. I think the last point "textual data or images" should be expanded, e.g., # A long-term archive service may accept any type of data for # preservation. The data might be in any format, whether textual # data, images, documents, applications, or compound packages # of multiple components. The data may be digitally # signed, time-stamped, encrypted, or not subject to any cryptographic # processing. *** Is this a requirement that all of these be accepted, or is this something where variability is allowed? What is the general principle here? =============== A long-term archive service does not operate upon evidence related to the content of archived data objects. Content-focused operations, including data format migration or translation, may be performed by a notary or notarization service. *** This sounds like you intent it to be disallowed for a long-term archive service to provide any content-focused operations. Shouldn't this be 'is not required to operate upon' rather than 'does not operate on'? In any case, even if it isn't the long-term archive service doing the operating, I think it should be left open whether the content-focused operations are performed by notary services or, at least in part, by some other third-party service. For example, there could be an (untrusted) content-transformation service whose output would be validated by a (trusted) notary service. So I suggest something like: # A long-term archive service is not required to operate upon evidence # related to the content of archived data objects. Content-focused operations, # including data format migration or translation, may be performed by a # other services, e.g., notary services. ================= A long-term archive service preserves archived data objects over arbitrarily long periods of time. This reads like it is a definition. You could have a service which only guarantees to preserve data for 30 years, not 'arbitrary long periods of time'. However, removing the word 'arbitrarily' leaves this general principle not actually saying much. Perhaps you mean something like: # Different long-term archive services may establish policies and procedures # for archiving data objects over different lengths of time. is meant? I'm not sure. ================= 4. Technical Requirements This section describes requirements for a long-term archive system. I think something like: # This section describes the requirements for the protocol for # accessing a long-term archive system. ================= - submit data and receive an acknowledgement or proof of deposit perhaps 'acknowledgement or evidence of deposit'? I'm uncomfortable because we haven't defined 'proof'. Is 'attestation' better than 'acknowledgement' here (assuming we define attestation)? Or is 'proof of deposit' just the definition of 'acknowledgement'? Perhaps something like # - submit data objects for archive and then, later, with the other requirements on 'the format for the acknowledgement' # When a data object is submitted for archive, an acknowledgement # is returned. The acknowledgement includes an attestation by the # archive service of the deposit of the data object. ================= - delete archived data objects/terminate archivation period for an archived data object. Later, you point out that 'deletion may not involve physical deletion'; so this is confusing. I think the first thing to do is to change "permit clients to perform the following" to "permit clients to request the following"; the client may request deletion, just as the client may submit data, but find that the LTA can't deposit it. **** May someone request the archivation period being shortened but not immediately? (E.g., employee records are usually kept 'for the length of employement plus N years', so at employment termination, you might request shortening the lifetime to N years.) Right now the only operations are 'delete' and 'extend'. ================== Submitters must be able to specify an archivation period. I would include this in the bulleted list above with a -. ======================== It should be possible to extend the archiving period after the initial submission. Who should be able to do this? ======================== Submitters should be able to specify metadata that, for example, can be used to enable retrievers to render the data correctly. I think this may be worthy of some amplification and clarification. Do you mean explicitly content-type or other MIME-like headers? **** Usually the word 'metadata' is also associated with indexing information (Title, Author, Date, etc.). Is that kind of metadata for long-term archived data included? Is it possible to search on metadata in the long-term archive? Or is it explicitly excluded, required to be part of the archived package or part of the archived data? ===================== Following submission, the service must provide a value that can be used to retrieve the archived data and/or associated evidence. It may be possible to retrieve archive packages by using a hash value of an archived data object. **** Is this value a capability? Or does it also require authorization? Is the requirement that this retrieval handle be generated by the submitter, the long-term archive service, or by both (when it uses a hash value of the archived data object)? While I think using a hash value of an archived data object is an interesting approach, I'm not sure why it's in the requirements. ======================= Deletion requests must be authorized and an authorization policy must be defined and observed by the long-term archive service (as part of an archive policy). I assume the authorization policy is not just for 'deletion'? I think this is just editorially talking about authorization policies. I'm not sure whether the policy is per LTA or per archived document, though. ======================= The format for the acknowledgements must allow the identification of the archiving provider. **** Why is this optional? Is it the identification of the operator of the LTA? Or of the LTA itself? ======================= The format for the acknowledgements must allow the identification of the participating client. **** I think this is a more substantial requirement, that the submitting client must identify itself, and that identity may (or must? or should?) be included in the acknowledgement? ======================== 4.1.2 Rationale Given that this is just once sentence (and most of the Rationale subsections are short), I would suggest readability might be improved by eliminating the section head. # 4.1 Requirements for LTA operations # # A long-term archive service must ... # # ... end of current 4.1.1.... # # Rationale: # Submission, retrieval and deletion of archived data objects # are necessary basic functions of a long-term archive service. # 4.2 Requirements to provide evidence records # # A long-term archive service.... ====================== 4.2 Provide evidence records I think this section could be expanded. For example, the term 'trust anchors' isn't defined in the document or referenced. And it isn't clear why 'trust anchors' have to be provided by other services, rather than just 'might be provided by other services'. I think this section puts some of the requirements in the 'Rationale'. (I'm running out of steam or I would try for a rewrite). I don't think the requirements outline sufficiently what is necessary to transfer data from one archive to another, and what it means to do that; it's not just the archived data, it's the evidence, and the requirements for creating a chain of evidence could be spelled out. Perhaps the transferability requirement belongs in 4.6 and not here. The 'Submitters must be able to specify metadata ...' belongs in 4.1 and not in 4.2, because it is a requirement that submitters should be allowed to specify metadata (or must be required to specify metadata?) =============================== 4.3 Again, some of the requirements seem to be in the 'Rationale', and I'm not sure why Content-focused operations are disallowed rather than just 'not required'. I'm not sure what it means to demonstrate data integrity without also providing evidence records. If you can't demonstrate that you had the data at a particular date, how can you demonstrate that the data you have is 'the same'? ================================= 4.4 Long-term archive policy I think a reference for 'certificate policy' is called for here, and needs to be spelled out. This probably goes back to the Long-term archive policy: A named set of rules that define operational characteristics of a long-term archive service. in the definitions: what is the namespace of rule set names? Do different LTAs share named archive policies? It may be that this section has a part that is defining what a Long-term archive service does (it operates according to a policy), and that the requirements are not operational requirements but interface requirements, e.g., providing information identifying the policies. I'm not sure what 'in use at any point in time'. Are services allowed to change their policies? Can you ask today 'what were your policies 10 years ago'? The policy may define characteristics such as the quality of timestamps obtained or generated by the long-term archive service or triggers for preservation activities, e.g. timestamp refresh or data format migration. So we need to invent protocol elements for describing such things? What is the measure of 'quality of time-stamp'? ================================= 4.5 Data confidentiality Again, this is a combination of description of what a long-term archive service is, coupled with some requirements for the interface to it. # Standard encryption algorithms and formats, e.g. AES and CMS, should # be supported. I'm not sure what this means -- is this an operational requirement for how the LTA operates internally, or a protocol requirement for the submitter/retriever <-> LTA protocol. Elsewhere it said that transport security might be used to provide confidentiality, which might not use AES or CMS. ================================== 4.6 Data and evidence transferability See notes for 4.2 above. I think that it might be possible to be clearer about what the actual functional requirements are to 'support the transfer'. In fact, 'transfer' isn't really an accurate description of the operation, because when the archived data object may actually be 'transferred', most attestations and elements of trust will require another layer.' ===================================== 4.7 Supporting Groups I would put into this category "a document and its translation into another format". Consider all of the subcategories of multipart: multipart/alternative, multipart/mixed, multipart/signed... to cover the important cases. ======================= 8. References Current practice is to separate informative vs. normative references. I suppose all of these are informative. I believe that it would be very useful to provide additional informative references to records management practices. From owner-ietf-ltans Sat Oct 2 17:42:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i930g5Cu068956; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i930g57P068955; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob2.obsmtp.com [64.18.1.212]) by above.proper.com (8.12.11/8.12.9) with SMTP id i930g5N2068949 for ; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob2.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 17:42:09 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i930fobA024352; Sat, 2 Oct 2004 17:41:55 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i930fokq029786; Sat, 2 Oct 2004 17:41:50 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007HKGLPE3@mailsj-v1.corp.adobe.com>; Sat, 02 Oct 2004 17:41:50 -0700 (PDT) Date: Sat, 02 Oct 2004 17:41:50 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> To: "'Richard Hansberger'" , ietf-ltans@imc.org Message-id: <0I4Z007HLGLPE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSWBPi37cC6KZyTThCl59ulnT982wAALaMg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net From owner-ietf-ltans Sat Oct 2 19:32:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i932WTbK076635; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i932WTAn076634; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob3.obsmtp.com [64.18.1.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i932WTnV076628 for ; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 19:32:02 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i932W3Nf004726; Sat, 2 Oct 2004 19:32:03 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i932W3kq002526; Sat, 2 Oct 2004 19:32:03 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007BQLPEE3@mailsj-v1.corp.adobe.com>; Sat, 02 Oct 2004 19:32:03 -0700 (PDT) Date: Sat, 02 Oct 2004 19:32:02 -0700 From: Larry Masinter Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt In-reply-to: <415D7388.3000003@bull.net> To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org Message-id: <0I4Z007BRLPEE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSnypBV7SZdS/NcR1uWk9JbDjzAPgBFzcsw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for not reviewing your comments carefully before writing my own. In several places we make conflicting suggestions for what should be done with the text. I suppose with editorial suggestions that the editors have the final call, but where there are areas of technical disagreement, the working group should comment. I think it's appropriate to respond to comments when they are received, rather than waiting for the end of the 'last call' period. Here are my comments on yours; we should work to resolve conflicts where we've made different suggestions: > The document misses to indicate that it is necessary to demonstrate the > origin of the data The submitter? Or the originator? Or both? > and that the document has been placed in a storage before > a given date so that even the system engineers in charge of > the archive system do not have the possibility to modify any more stored > documents. Is this a requirement of the protocol, or a definition of a long-term archive system? > It is proposed to delete the present abstract and to replace it with: > > "This document specifies the technical requirement for long-term archive > services able to support non repudiation of data origin with integrity and > existence of data at a given time. Data to be stored and retrieved may > include signed data. Long-term archive services operate under an archive > policy which will need to be periodically redefined as the time goes. This > document specifies the main constituents of an archive policy". This still doesn't distinguish between the description of an archive service and the requirements for the protocol for interacting with it. To be honest, it's usually fruitless to focus on the abstract if there is disagreement about the substance, so we should come back to the abstract later. I like most of what you wrote. I still don't understand exactly what is meant by an 'archive policy' and whether it is a service-wide policy or a document-specific policy. Can one archive service provider proxy for many different ones, each of which with its own policy? > In fact the main constituents of an archive policy still need > to be defined. Yes, please. > The following comments focus on one of the components of an archiving > policy, i.e. the cryptographic maintenance policy, so the > work still needs to be done. Perhaps you could be more explicit, or give some references, to an example of what such a complete policy might be? > 2. Introduction > > The second paragraph needs to be revisited (besides the two > typos in the first sentence) because it is too vague. > Proposed replacement: > > "A long term archive service accepts data from users. This data may be > confidential data or public data. When it is confidential data, it is the > responsibility of users only to take care of the confidentiality of the data > they submit. If users care that their data shall not have its semantics > disclosed to the system engineers from the long term archive service, then > they shall take care themselves of the protection of their data. Is this really the idea? That the long-term archive has no responsibility to keep its archived data private??!? I could imagine different archives with different service guarantees, but it's hard to imagine a scenario where there is no requirement for confidentiality by the service provider, e.g., if I don't want my identity and the amount of data I've archived to be made public. So, if privacy from traffic analysis is a requirement, why is privacy in general not a requirement? > When data is confidential data, it is important that > submitters can check for themselves: Is it the submitters that want to check, or some third party to which the submitters wish to provide evidence? A submitter knows what was submitted, no? > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement (*), and > > - that the data originates from them (either symmetric > or asymmetric cryptography may be used). I think the comment about cryptography is perhaps out of place. It is a mechanism, not a requirement. Or is there a requirement to use cryptography? Or to support one or the other or both? > (*) more precisely a proof of existence of data at a given > time preceding the archival time, to demonstrate that the data was placed in > a server from the long-term archive before that time. I think there's a case where a malicious (or hacked) LTA might provide unmodified data to some retrievers and modified data to others, so it's useful to be clear about WHICH data has been 'unmodified'. > When the data is public data, it is important to be able to > demonstrate to someone else (i.e. obtain a non-repudiation evidence): Non-repudiation is important whether or not the data is public. > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement, and > > - that the data originally placed originates from a given entity > (different from servers belonging to the long-term archive > service). Note: that entity may or may not be a Notary. I don't understand the use case where a Notary might be the 'originator'. Surely the Notary is another party whose role is to add assurances, not an originator. Or do you imagine a real (human) Notary using a LTA service? > Since the document addresses long term storage, transfer from > one data storage unit to another may happen. Retrieval of data may > thus be done from a server different from the server where the data was > originally stored. It is therefor important to attach the security to the data > itself and not to rely only on the security mechanisms and procedures performed > by the server where the data is stored or retrieved. I don't think this follows. It's important for the storage to be secure operationally, and that any transfers be performed securely. One way to do that would be to encrypt the data and rely on the encryption during the transfer, but this has its difficulties, especially if the data is accompanied by meta-data (oh, access control policies) that might also be confidential. > Two non-repudiation evidences will need to be provided: > > - a first one to demonstrate to third parties the data originally > placed originates from a given entity, > > - a second one to demonstrate to third parties that the data was > originally accepted for storage, at a given time, by a server > belonging to a given long-term archive service. This is a good separation. I'm still a little uncomfortable with 'originates', since the demonstration isn't really of the origination but an initial attestation. > Since these evidences will be provided using cryptographic > means, Must they be provided using cryptographic means? There are no other means? How about 'When these evidences are provided ...'. > Some CA keys used to validate an electronic signature may last in practice > shorter that the end of the validity period of a signature policy. So it is > important to be able to maintain their validity beyond the end of the > validity period of the signature policy. I'm unclear about whose validity 'maintain their validity' applies to. The CA keys? You're going to maintain the validity of the keys beyond the end of the validity period of the keys? > This cryptographic maintenance activity is part of the responsibilities of a > long-term archive service and will be performed according to one or more > cryptographic maintenance policies." I think cryptographic maintenance activities are one way of providing long-term assurance, certainly. > > 3. Introduction > > The third paragraph needs to be revisited because it is inappropriate. > > Validation of assertions of agreements originally asserted with digital > signatures is not a task that is within the scope of a long-term archive > service. Proposed replacement: > > "A long-term archive service may optionally support a service able to check > an evidence demonstrating that an archive package has been originally > accepted for storage, at a given time, by a server belonging to another > given long-term archive service." I'm not sure why it is out of scope. It seems like a natural service for long-term archive services to offer. > 4. Introduction > 5. Introduction I think my suggestions here are more explicit than yours, but I hope I've accomplished the same goal. > 6. Terminology ... > Cryptographic maintenance policy: a named set of rules that > defines how to maintain the validity of digitally signed objects > should one of the hash functions or asymmetrical algorithm used > to create a digital signature of a signed object become weak or > one of the private keys used to create a > digital signature of a signed object be compromised or become weak. When there is a 'named set of rules', what is the namespace? Who maintains it? Note that all of the maintenance should happen BEFORE 'hash functions or asymmetrical algorithms become week' and BEFORE private keys are compromised or become weak and not after. > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I think what you're saying is that cryptographic maintenance is an option for providing long-term assurance. Of course, you could consider this 'two modes', but calling them 'active' and 'passive' is misleading. There may be other operational ways of providing long-term assurance that don't involve cryptographic maintenance but are still 'active'. > When operating is the active mode, a long-term archive service has to apply > a cryptographic maintenance policy on archived data objects using the > critical cryptographic parameters associated with every archived data object. > > When operating either in the passive or the active mode, a long-term archive > service has to apply a cryptographic maintenance policy on the archived > packages using the cryptographic maintenance parameters associated with a > set of archived packages". Cryptographic maintenance is only applied when cryptographic maintenance is applied, though. So how could a service with opaque data and no information about its signatures apply a cryptographic maintenance policy? From owner-ietf-ltans Sun Oct 3 06:03:46 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93D3kQj022305; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i93D3kTn022304; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93D3jMT022297 for ; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i93D3eql011466 for ; Sun, 3 Oct 2004 09:03:40 -0400 From: "Santosh Chokhani" To: Subject: RE: Notary services requirements -- directions? Date: Sun, 3 Oct 2004 09:03:34 -0400 Message-ID: <00a601c4a949$66df3f30$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <0I4Z007HLGLPE3@mailsj-v1.corp.adobe.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I vote for Larry's proposal for the scope of Electronic Notary services. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter Sent: Saturday, October 02, 2004 8:42 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net From owner-ietf-ltans Sun Oct 3 23:45:28 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i946jSV8032607; Sun, 3 Oct 2004 23:45:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i946jSGu032606; Sun, 3 Oct 2004 23:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail4.telekom.de (mail4.telekom.de [195.243.210.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i946jQTL032480 for ; Sun, 3 Oct 2004 23:45:27 -0700 (PDT) (envelope-from ErnstG.Giessmann@t-systems.com) Received: from u9jwn.mgb01.telekom.de by mail2.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Mon, 4 Oct 2004 08:44:55 +0200 Received: from mailgate9.telekom.de (mailgate9.telekom.de [164.20.161.140]) by u9jwn.mgb01.telekom.de with ESMTP for ietf-ltans@imc.org; Mon, 4 Oct 2004 08:45:11 +0200 Received: from bach.bln05.telekom.de by mailgate9.telekom.de (8.8.8/1.1.8.2/02Aug95-1122AM) id IAA0000004393; Mon, 4 Oct 2004 08:45:04 +0200 (MET DST) Received: from [172.23.7.12] ([172.23.7.12]) by bach.bln05.telekom.de (8.8.8+Sun/8.8.8) with ESMTP id IAA06650 for ; Mon, 4 Oct 2004 08:47:16 +0200 (MET DST) Message-Id: <4160F158.80803@t-systems.com> Date: Mon, 04 Oct 2004 08:44:40 +0200 From: Ernst G Giessmann User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <200410011653.i91Grkp23823@chandon.edelweb.fr> In-Reply-To: <200410011653.i91Grkp23823@chandon.edelweb.fr> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, I would like to support Peter Sylvester, he wrote: ... > Denis proposes a lot of new text, which I think should be carefully read > and combined with the current req if we agree all on that. There is one point Denis raised, that is very important. I guess that we can compare it with the digital/electronic signature issue: The technical solutions for digital signatures (hash'n'sign) are quite clear and I would say finalized, whereas the answer on the question what a electronic signature as the future replacement for handwritten signatures is can not be given as easily. The cryptographic maintenance policy is one of the crucial points as it is the signature policy for electronic signatures. This policy may be explicit or implicit, but it *must* be there. So I would suggst to extend a bit the discussion time. It is for Long-Term and don't hurry up ;-) Regards, Ernst -- Ernst G Giessmann T-Systems GmbH ITC-Security Goslarer Ufer 35, D-10589 Berlin phone:+49-30-3497-4342 mailto:ErnstG.Giessmann@t-systems.com From owner-ietf-ltans Mon Oct 4 03:28:56 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94ASuOW011274; Mon, 4 Oct 2004 03:28:56 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94ASuLx011272; Mon, 4 Oct 2004 03:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout02.datevnet.de (mailout02.datevnet.de [193.27.50.77]) by above.proper.com (8.12.11/8.12.9) with SMTP id i94ASsjL011192 for ; Mon, 4 Oct 2004 03:28:55 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 15430 invoked from network); 4 Oct 2004 10:28:44 -0000 Received: from mail01.services.datevnet.de (10.252.80.78) by mailout02.services.datevnet.de with SMTP; 4 Oct 2004 10:28:44 -0000 Received: (qmail 7997 invoked from network); 4 Oct 2004 10:28:44 -0000 Received: from localhost (HELO mail01.services.datev.de) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 4 Oct 2004 10:28:44 -0000 Received: (qmail 7994 invoked from network); 4 Oct 2004 10:28:43 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 4 Oct 2004 10:28:43 -0000 From: "Michael Tielemann" To: Subject: WG LAST CALL: draft-ietf-ltans-req Date: Mon, 4 Oct 2004 12:31:52 +0200 Message-ID: <002f01c4a9fd$5d007e70$9c01fb0a@P25823E0> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i94ASujL011265 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, watching the discussion here in LTANS I would like to emphasis that a couple of companies are waiting for results to implement long-term archive services within the near future. Since several years we have already electronic signed documents according to our german signaure law circulating. Most sites responsible for cryptographic security, especially trust center in the sense of our signature law are in charge to implement a long-term archive. Hence, it's of course important to discuss the wording but please don't go over the top. We need technical facts a.s.a.p. to start implementation. Mit freundlichen Grüßen With kind regards -Michael Tielemann ---------------------------------------------------------------------- + Dr. Michael Tielemann Tel: ++49 / (0)911 / 276 / 6476 + DATEV eG, Dep. P34 System Design eMail: michael.tielemann@datev.de + 90329 Nürnberg Germany GSM: ++49 / (0)172 / 8120 223 + Paumgartnerstrasse 6-14 Fax: ++49 / (0)911 / 147 / 05544 From owner-ietf-ltans Mon Oct 4 11:57:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IvEuw091031; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94IvE3q091028; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IvDP1090973 for ; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W94J3KHJ0000091C; Mon, 04 Oct 2004 11:56:53 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <4C6QYD78>; Mon, 4 Oct 2004 11:57:05 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368CFDF@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: RE: Notary services requirements -- directions? Date: Mon, 4 Oct 2004 11:57:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 9e3e68efd77b8bee62c4ca443c40dfcc Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain I appreciate the feedback. I would suggest, however, that because the term "Notary" is legally defined and most states actually have criminal penalties for misappropriating the term or claiming to be a Notary when one is not, the term is less flexible than you suggest. In fact, we are facing a serious problem right now in the Western states over the issue of using the term "Notario Publico" inappropriately. In Latin America, a Notario Publico is, generally speaking, an attorney; in the US, a Notary Public is a ministerial official of the court. Many citizens are being misled by scam artists preying upon general confusion of the two terms. We ran into this same problem when the US Federal "E-Sign" Act was passed in 2000. A number of vendors offered "Digital Notary Services" that represented their services as replacements for human Notaries. Obviously, as a professional association we have our biases, but the term "Notary" is used by US states to refer to a human witness to a transaction of legal or financial significance. Human Notaries exist in large part to bear witness to a signer's intent/willingness/capacity in the event a court or other state official (e.g., in a trial proceeding or similar venue) needs that kind of confirmation. Just further food for thought...I don't mean to derail any good work being done. Take care, Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Saturday, October 02, 2004 4:42 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- From owner-ietf-ltans Tue Oct 5 00:06:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9576wga009191; Tue, 5 Oct 2004 00:06:58 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9576wDB009190; Tue, 5 Oct 2004 00:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9576ud3009128 for ; Tue, 5 Oct 2004 00:06:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA37112; Tue, 5 Oct 2004 09:18:10 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100509063828:20 ; Tue, 5 Oct 2004 09:06:38 +0200 Message-ID: <416247FD.3030701@bull.net> Date: Tue, 05 Oct 2004 09:06:37 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Richard Hansberger CC: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: Re: Notary services requirements -- directions? References: <561F9357D239EB428AE3A4F14244431368CFDF@Louise2> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/10/2004 09:06:38, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/10/2004 09:06:40, Serialize complete at 05/10/2004 09:06:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, > I appreciate the feedback. I would suggest, however, that because the term > "Notary" is legally defined and most states actually have criminal penalties > for misappropriating the term or claiming to be a Notary when one is not, > the term is less flexible than you suggest. In fact, we are facing a serious > problem right now in the Western states over the issue of using the term > "Notario Publico" inappropriately. In Latin America, a Notario Publico is, > generally speaking, an attorney; in the US, a Notary Public is a ministerial > official of the court. Many citizens are being misled by scam artists > preying upon general confusion of the two terms. This is a real problem indeed. Why not use the term eNotary or e-Notary instead ? Denis > We ran into this same problem when the US Federal "E-Sign" Act was passed in > 2000. A number of vendors offered "Digital Notary Services" that represented > their services as replacements for human Notaries. > > Obviously, as a professional association we have our biases, but the term > "Notary" is used by US states to refer to a human witness to a transaction > of legal or financial significance. Human Notaries exist in large part to > bear witness to a signer's intent/willingness/capacity in the event a court > or other state official (e.g., in a trial proceeding or similar venue) needs > that kind of confirmation. > > Just further food for thought...I don't mean to derail any good work being > done. > > Take care, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > > -----Original Message----- > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Saturday, October 02, 2004 4:42 PM > To: 'Richard Hansberger'; ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > >>In answer to your first question, we've always understood the >>term "Notary Service" to be a technology that Notaries could use, not a >>technology that others can use in lieu of notarization. If that >>means the name of the service needs to change, I'll leave that >>decision in more capable hands. > > > While "Notary Service" might be ambiguous, I don't think > this means we have to rename it. After all, the ways in which > one noun can modify another is ambiguous: steak knife, steel > knife, boy-scout knife use different kinds of modification. > (From the Addams Family movie, about Girl Scout cookies: > "Are they made from real Girl Scouts?") > > In the context of LTANS, "notary service" seems to have been > intended as something much more narrow than what a Notary does. > > http://www.ietf.org/html.charters/ltans-charter.html > > focuses on a fairly narrow set of workflows: > > In many scenarios, users need to be able to ensure and prove the > existence and validity of data, especially digitally signed data, in a > common and reproducible way over a long and possibly undetermined period > of time. > > ... > > Long-term non-repudiation of digitally signed data is an important > aspect of PKI-related standards. Standard mechanisms are needed to > handle routine events, such as expiry of signer's public key certificate > and expiry of trusted time stamp authority certificate. > > I think we should stick to a narrow definition for notary service > requirements, and focus on those services that can reasonably be > accomplished without manual (human) intervention;the use of 'notary' > in the title is evocative (notary-like services; just like a > 'stone lion' is a lion-like stone). > > I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome > and related web pages, that there is an industry focused on tools > that Notaries can use, including for support of notarization in > electronic workflows. > > I suggest we do not include these in the notary service requirements. > > Larry > > > ------------------------------------------------------------------------ > > This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. From owner-ietf-ltans Tue Oct 5 08:54:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Fs6w0025710; Tue, 5 Oct 2004 08:54:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Fs6nE025709; Tue, 5 Oct 2004 08:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Fs1Ps025672 for ; Tue, 5 Oct 2004 08:54:04 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i95FrqN01497; Tue, 5 Oct 2004 17:53:52 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 5 Oct 2004 17:53:52 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i95Frpl05845; Tue, 5 Oct 2004 17:53:51 +0200 (MEST) Date: Tue, 5 Oct 2004 17:53:51 +0200 (MEST) From: Peter Sylvester Message-Id: <200410051553.i95Frpl05845@chandon.edelweb.fr> To: rhansberger@nationalnotary.org, Denis.Pinkas@bull.net Subject: Re: Notary services requirements -- directions? Cc: LMM@acm.org, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Richard, > > > I appreciate the feedback. I would suggest, however, that because the term > > "Notary" is legally defined and most states actually have criminal penalties > > for misappropriating the term or claiming to be a Notary when one is not, > > the term is less flexible than you suggest. In fact, we are facing a serious > > problem right now in the Western states over the issue of using the term > > "Notario Publico" inappropriately. In Latin America, a Notario Publico is, > > generally speaking, an attorney; in the US, a Notary Public is a ministerial > > official of the court. Many citizens are being misled by scam artists > > preying upon general confusion of the two terms. > > This is a real problem indeed. Why not use the term eNotary or e-Notary > instead ? > Would this change a lot? A little bit of history: C. Adams(Entrust Technologies) R. Zuccherato(Entrust Technologies) February 27, 1997 Notary Protocols became: C. Adams(Entrust Technologies) R. Zuccherato(Entrust Technologies) June 4, 1998 Data Certification Server Protocols and later Network Working Group C. Adams Request for Comments: 3029 Entrust Technologies Category: Experimental P. Sylvester EdelWeb SA - Groupe ON-X Consulting M. Zolotarev Baltimore Technologies Pty Limited R. Zuccherato Entrust Technologies February 2001 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols I don't know why the first change occured, but at least it avoids at least two problems. From owner-ietf-ltans Tue Oct 5 10:57:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvKlT037650; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvK7D037649; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvJQN037641 for ; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqp010708 for ; Tue, 5 Oct 2004 13:57:21 -0400 Message-Id: <200410051757.i95HvCqp010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Archive policy-related comments Date: Tue, 5 Oct 2004 13:57:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBMK+Pp8YwvYQRYiRn1ml0QmNcw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A number of comments on the -02 requirements draft relate to archive policy. This thread collects the policy-related questions/comments and offers an initial set of archive policy components and a few responses. 1) What are the primary components of an Archive Policy? - Based on the comments, a few candidate archive policy components based on the discussion are: types of data accepted by an LTA; types of data operated upon by an LTA and nature of that operation; access control policy; refresh operation triggers; types and characteristics of refresh mechanisms used. 2) Are archive policies enforced on a per document basis or per LTA basis? - It seems like there are some policy components that should be per document (e.g. archivation period) and others that are LTA-wide (e.g. TSA used to generate timestamps, 3) If archive policies are named, what is the namespace? 4) What components of an archive policy can be specified by a submitter (or modifier)? 5) Do different LTAs share named archive policies? - This seems like a likely scenario. 6) Cryptographic maintenance policies were described in detail (see below with responses). > "4.X Cryptographic maintenance > > 4.X.1 Functional requirements > > A long term archive service must maintain the cryptographic > validity of its evidence records. It needs to perform the > following > basic operations: > > - attach cryptographic maintenance parameters to one or a set > of archived packages, > > - apply the cryptographic maintenance policy referenced within > the cryptographic maintenance parameters to maintain the > validity of its evidence records using the critical > cryptographic parameters, > > - periodically apply the original cryptographic maintenance > policy using the critical cryptographic parameters, "Original" should be "current". Once the policy is changed the original policy won't be reapplied. > - periodically apply a new cryptographic maintenance policy > should the previous cryptographic maintenance policy become > weak or inappropriate. > > When an archived data objet is submitted to a long term archive > service with cryptographic maintenance parameters, then the long > term archive service shall either maintain the cryptographic > validity of that archived data objet or refuse to accept the > service. If it accepts, then it needs to perform the following > basic operations: > > > > 4.X.1 Rational > > Maintenance of the validity of archived packages is a necessary basic > function of a long-term archive service. > > Maintenance of the validity of archived data objets is an > optional function > of a long-term archive service". > > > 10. A new section should be introduced to address the > requirement of some > data structures. Proposed text; > > " Y. Requirements on some data objects > > Y.1 Requirements on cryptographic maintenance policies > > A cryptographic maintenance policy: > > - must be unambiguously identified by an object identifier > (e.g. an OID), Suggest "must be unambiguously identified (e.g. an OID)". No need to require OIDs. > - must include a validity period, > > - must specify how the necessary bindings to the time scale will > be guaranteed, for example it can specify the > Time-Stamping Units > (TSU) recognized under that policy, > > - may unambiguously reference a sequence of one or more previously > defined cryptographic maintenance policies. For what purpose? > > Y.2 Requirements on critical cryptographic parameters > > Critical cryptographic parameters shall include data objects > describing all > the algorithms, and the associated key lengths used in the > object to which > the critical cryptographic parameters are associated. These > data objects may > be in the form of data objects identified using an OID, and > may include one > or more algorithm specific parameters. > > Y.3 Requirements on cryptographic maintenance parameters > > Cryptographic maintenance parameters shall include two components: > > - critical cryptographic parameters, and > > - an unambiguous reference to one cryptographic > maintenance policy. > > > 11. In formation should be added to address cryptographic > maintenance issues > in case a hash function exhibits collisions. Proposed text to > be included in > the security considerations section: > > "Cryptographic maintenance issues in case a hash function > exhibits collisions > > Submitters may submit: > > 1) signed data and their associated signatures, or > 2) signatures only (i.e. without the signed data). > > In case the hash function used to compute the digital > signature over the > original data exhibits collisions, it is necessary to > recompute a hash of > that original data using another hash function. This is not > feasible if > signatures only are submitted (i.e. without the signed data)". From owner-ietf-ltans Tue Oct 5 10:57:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvE6x037626; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvEWv037625; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvEJT037617 for ; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqm010708 for ; Tue, 5 Oct 2004 13:57:13 -0400 Message-Id: <200410051757.i95HvCqm010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Editorial comments Date: Tue, 5 Oct 2004 13:57:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBLywsYZo5CVPR/aFqXb73/xxLQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This thread captures the editorial comments from Larry's and Denis' emails regarding the -02 draft of the long-term archive service requirements document. For each item, an indication of acceptance or a response is provided. The comments have been numbered sequentially prefaced by document section number. Non-editorial comments will be addressed in separate threads. Front Matter FM-1) Capitalize words in the title - Accepted FM-2) Use "Long-Term" instead of "Long Term" throughout the document. - Accepted Section 1 1-1) In the first paragraph of the introduction, use 'required lifetime' instead of 'useful lifetime' (in sentence 2) and 'lifetime' in sentence 3 instead of "lifetime of digitally signed data" - Rejected. I think "useful", or possibly "valuable", is preferable to "required" in this case. In sentence 3, "lifetime of digitally signed data" is necessary to establish the context for the remainder of the sentence. 1-2) Change "...via an internet" to "...via the Internet" - Accepted 1-3) Put a comma between "asserted at" - Accepted 1-4) There are two (unspecified) typos in the first sentence - Partially accepted. The spelling of technical was corrected. What's the other typo? 1-5) The third paragraph needs to be revisited because it is inappropriate. - Rejected. The paragraph does not state that the LTA is performing the validation. It states that the LTA is supporting validation (presumably through provision of evidence). However, I would see LTA-side validation as being a reasonable service. 1-6) Delete the first sentence in the fifth paragraph. What is "something"? - Partially accepted. Replaced something with "a claim" and left the sentence in place. 1-7) Delete the last sentence of the fifth paragraph and refrain from using the words notary and notarization. - Pending. References to notaries and notarization remain pending further discussion on the list regarding notaries and notarization. 1-8) Add three new terms - Pending. New terms will be added pending further discussion on the list regarding archive policies. Section 2 2-1) Section 2 needs a preface. - Suggested text accepted. 2-2) "Arbitrator" is defined but not used. - Pending. Other text may need to change to support the inclusion of this definition. 2-3) Write out 'long-term archive service' since it is a forward reference - Accepted 2-4) Define 'attestation' - May drop usage of the term (one of two instances has already been replaced). 2-5) "Originator" is defined but not used. - Pending. Other text may need to change to support the inclusion of this definition. 2-6) Various RFC3161, TSA and timestamp suggestions - All accepted Section 3 3-1) In General Principles, expand on "textual data or images". - Suggested text accepted 3-2) The statement "a long-term archive service preserves archived data objects over arbitrarily long periods of time" reads like a definition and seems to preclude services from only offering to preserve data for a specified period of time. - Suggested text accepted Section 3-3) Replace the last sentence on page 6 with the following: "A long term archive service provides material that may be used to demonstrate the existence at a given time of archived data objects, and both the integrity and authenticity of these archived data objects (i.e. that they originate from servers under the responsibility of a given long term archive service." - Why does it matter what servers the data objects originate from? The integrity is since submission (regardless of the servers that have handled the data) or before submission in the case of signed data. Section 4 4-1) Replace "This section describes requirements for a long-term archive system" with "This section describes the requirements for the protocol for # accessing a long-term archive system." - Partially accepted. The requirements aren't limited strictly to accessing a long-term archive system. Appended "and for the data formats associated with data preservation" to the suggested text. 4-2) Change "permit clients to perform the following" to "permit clients to request the following" - Accepted 4-3) Change "submit data and receive an acknowledgement or proof of deposit" to "submit data objects for archive" - Accepted 4-4) Move "submitters must be able to specify an archivation period" to bulleted list - Accepted 4-5) Remove the "Rationale" subsection heading - Pending. May remove or may provide additional detail under the Rationale subsections. 4-6) Add text describing new terms (e.g. cryptographic maintenance and related terms) - Pending. Will add additional sections pending outcome of list discussion regarding archive policy. Section 4.2 4.2-1) "Non-repudiation of data" is not a well defined service. - Accepted with alternative text. Appended "existence at and integrity since a point in time" to "non-repudiation of data". Section 4.3 4.3-1) Some of the requirements are in the rationale section - Pending. Some sections may be significantly rewritten depending on the discussing related to content-focused operations. 4.3-2) This section should be merged with the previous section. - Pending. Integrity-focused text will be merged with previous section. New text regarding content-focused operations may be added here. Section 4.4 4.4-1) A reference for certificate policy is called for. - Accepted. Added a reference to the CP/CPS framework. 4.4-2) Text should be changed to reference "cryptographic maintenance policy". - Pending. Text will be modified pending list discussion regarding archive policy. Section 4.5 4.5-1) Comment regarding support for AES and CMS is confusing - Accepted. Removed sentence. Section 4.6 4.6-1) Need to state functional requirements for transfer more clearly - Accepted. Will rework this section. Section 4.7 4.7-1) Add "a document and its translation into another format" to the items considered in this section - Accepted Section 6) 6.1) Text should be modified to refer to the cryptographic maintenance policy. - Pending. Text will be modified pending list discussion regarding archive policy. Section 8 8-1) Split references into normative and informative - Accepted. All references have been categorized. 8-2) Add references to records management practices. - Pending. Any particular references in mind? From owner-ietf-ltans Tue Oct 5 10:57:19 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvJc5037642; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvJBD037640; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvIM6037618 for ; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCql010708 for ; Tue, 5 Oct 2004 13:57:12 -0400 Message-Id: <200410051757.i95HvCql010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Overview of comments Date: Tue, 5 Oct 2004 13:57:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C4AAE3.36B842C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBLn04ITtsg7eRPa0Ph8H8J/DPQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C4AAE3.36B842C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have received over 21(!) pages of comments so far. In an attempt to respond to each comment and to focus list discussion, I have reorganized the comments into four categories and will be sending a series of email messages shortly with the comments grouped into these categories along with some initial responses and a number of outstanding questions. The categories are: - Editorial comments - Archive policy-related comments - Abstract-related comments - Miscellaneous non-editorial comments Carl ------=_NextPart_000_0034_01C4AAE3.36B842C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ltans-reqs-02.txt: Overview of comments

We have received over 21(!) pages of = comments so far.  In an attempt to respond to each comment and to = focus list discussion, I have reorganized the comments into four = categories and will be sending a series of email messages shortly with = the comments grouped into these categories along with some initial = responses and a number of outstanding questions.  The categories = are:

        - Editorial comments
        - Archive policy-related comments
        - Abstract-related comments
        - Miscellaneous non-editorial comments

Carl   

------=_NextPart_000_0034_01C4AAE3.36B842C0-- From owner-ietf-ltans Tue Oct 5 10:57:23 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvNLn037670; Tue, 5 Oct 2004 10:57:23 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvNk4037669; Tue, 5 Oct 2004 10:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvMC6037663 for ; Tue, 5 Oct 2004 10:57:22 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqn010708 for ; Tue, 5 Oct 2004 13:57:15 -0400 Message-Id: <200410051757.i95HvCqn010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Miscellaneous non-editorial comments Date: Tue, 5 Oct 2004 13:57:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBL5w2T/K6EDwQ8aGBD31Uw+wHw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This thread collects various non-editorial comments and provides some responses. > The document misses to indicate that it is necessary to demonstrate the origin of the data I don't think 'origin of data' is a service an LTA can provide. The best an LTA can do towards proof of origin is collection and preservation of materials required for source authentication and this can only occur in the 'active' mode of operation. Data handled in a 'passive' manner may contain sufficient information to authenticate a source of the data with the LTA having no knowledge of (or possibly even access to) that information. An LTA may operate such that it will only accept data for which a source can be authenticated. This provides an extra measure against LTA administrators altering data (by substituting timestamps for example). > # A long-term archive service may accept any type of data for > # preservation. The data might be in any format, whether textual > # data, images, documents, applications, or compound packages > # of multiple components. The data may be digitally > # signed, time-stamped, encrypted, or not subject to any > cryptographic > # processing. > > *** Is this a requirement that all of these be accepted, or > is this something where variability is allowed? What is the > general principle here? There is no requirement expressed w.r.t. the type of archived data an LTA must accept from a submitter. This will be clarified by introducing the listed possibilities as examples. The types of permissible data may be a policy component. > *** This sounds like you intent it to be disallowed for a > long-term archive service to provide any content-focused operations. > > Shouldn't this be 'is not required to operate upon' rather > than 'does not operate on'? > > In any case, even if it isn't the long-term archive service > doing the operating, I think it should be left open whether > the content-focused operations are performed by notary > services or, at least in part, by some other third-party service. > For example, there could be an (untrusted) > content-transformation service whose output would be > validated by a (trusted) notary service. So I suggest something like: > > # A long-term archive service is not required to operate upon > evidence # related to the content of archived data objects. > Content-focused operations, # including data format migration > or translation, may be performed by a # other services, e.g., > notary services. The intent was to preclude content-focused operations under the LTA banner, recognizing that related capabilities might operate on content (e.g. to verify signatures contained in the content or to translate the content in some way). The suggested text conveys the intent more accurately. If the end user experiences this as an LTA service (and it seems reasonable to expect that to be the case), perhaps this note should simply be deleted. Section 4 > **** May someone request the archivation period being > shortened but not immediately? (E.g., employee records are > usually kept 'for the length of employment plus N years', so > at employment termination, you might request shortening the > lifetime to N years.) Right now the only operations are > 'delete' and 'extend'. Archivation period shortening should be identified as a possible operation (and has been in the working copy of the draft). This introduces a new type of actor, e.g. modifier in addition to submitter/retriever. > Submitters should be able to specify metadata that, for > example, can be used to enable retrievers to render the data > correctly. > > I think this may be worthy of some amplification and clarification. > Do you mean explicitly content-type or other MIME-like headers? > > **** Usually the word 'metadata' is also associated with > indexing information (Title, Author, Date, etc.). Is that > kind of metadata for long-term archived data included? Is it > possible to search on metadata in the long-term archive? Or > is it explicitly excluded, required to be part of the > archived package or part of the archived data? Content type and MIME-like headers are certainly examples. Others might be specific to a particular system or application (e.g. classification code), general support for searching (e.g. keywords) or other generic information (e.g. contributors, title, author, date). It seems likely that an implementation would support searching on at least some of these. A question we ran into working on the (unpublished) protocol spec was whether or not there needed to be support for "archived" and "unarchived" metadata, i.e. like signed and unsigned CMS attributes. We should probably have a profile of such attributes for which support is required. Should ability to search on particular types of metadata be mandated? If metadata is not an appropriate term, attribute could be substituted. > ===================== > Following submission, the service must provide a value that can be > used to retrieve the archived data and/or associated evidence. It > may be possible to retrieve archive packages by using a > hash value of > an archived data object. > > **** Is this value a capability? Or does it also require > authorization? > Is the requirement that this retrieval handle be generated by the > submitter, the long-term archive service, or by both (when > it uses a hash value of the archived data object)? > > While I think using a hash value of an archived data object is > an interesting approach, I'm not sure why it's in the requirements. I'd viewed this as a server-generated value (even in cases where the client could predict the value beforehand, e.g. hash). A client could specify an identifier as a metadata/attribute value. I did not view possession of the value as authorization to perform any action related to the associated archived data object or evidence. > ======================= > The format for the acknowledgements must allow the > identification of > the archiving provider. > > **** Why is this optional? Is it the identification of the > operator of the LTA? Or of the LTA itself? The intent was LTA itself. The statement indicates that the formats must support specification of the LTA. > ======================= > The format for the acknowledgements must allow the > identification of > the participating client. > > **** I think this is a more substantial requirement, that the > submitting client must identify itself, and that identity may > (or must? or should?) be included in the acknowledgement? So submissions must be authenticated? Section 4.4 > It may be that this section has a part that is defining what > a Long-term archive service does (it operates according to a > policy), and that the requirements are not operational > requirements but interface requirements, e.g., providing > information identifying the policies. > > I'm not sure what 'in use at any point in time'. Are services > allowed to change their policies? Can you ask today 'what > were your policies 10 years ago'? It seems likely that services will have to change policies over time. Good question as to whether it should be possible to ask for policies in use at time X. It may be overkill to require an interface for this. Instead the formats must include a means of indicating the policy in use. Thus, the policies applied to a specific object at a particular point in time can be determined but not the policies in use at a particular time. > The policy may define characteristics > such as the quality of timestamps obtained or generated by the > long-term archive service or triggers for preservation activities, > e.g. timestamp refresh or data format migration. > > So we need to invent protocol elements for describing such > things? What is the measure of 'quality of time-stamp'? We need to determine what aspects of policy should be applied on a per document basis and/or what aspects should be controlled explicitly by a submitter. Protocol elements would be necessary for the latter, at least. The "quality of timestamp" phrase should be replaced by "characteristics of timestamps" (possibly to include duration, key size, specific TSA). > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I like the idea of distinguishing between data that is operated upon by an LTA and data that is not. However, these are modes of operation for an LTA w.r.t to an archived data object (i.e. an LTA could operate in a passive mode for some objects and an active mode for others). Passive v. active as applied to data evokes ongoing preservation activities, however. Opaque vs. transparent may be a suitable alternative. From owner-ietf-ltans Tue Oct 5 10:57:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvL3A037659; Tue, 5 Oct 2004 10:57:21 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvLco037658; Tue, 5 Oct 2004 10:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvKq0037652 for ; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqo010708 for ; Tue, 5 Oct 2004 13:57:18 -0400 Message-Id: <200410051757.i95HvCqo010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Abstract-related comments Date: Tue, 5 Oct 2004 13:57:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBMAzqIisDJ7RS36xOsSow+minw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We received two suggested rewrites of the abstract. Both are presented below along with the abstract from the -02 draft. As Larry suggested, it may be better to table the abstract and focus on the other issues for the moment. Larry suggested the following: # There are many scenarios in which users, even after an arbitrarily # long period of time, will need to prove the original existance of # data and the integrity of that data in the duration. In addition, # there are requirements to prove the original validity of the # signatures of digitally signed data, even after an arbitrarily # long period. This document describes a class of long-term archive # services which support such scenarios, and the technical requirements # for protocols for interacting with such services. Denis suggested the following: "This document specifies the technical requirement for long-term archive services able to support non repudiation of data origin with integrity and existence of data at a given time. Data to be stored and retrieved may include signed data. Long-term archive services operate under an archive policy which will need to be periodically redefined as the time goes. This document specifies the main constituents of an archive policy". -02 draft text: In many scenarios, users need to be able to prove the existence of data at a given time and integrity of data, especially digitally signed data, in a common and reproducible way after an arbitrarily long period. This document specifies the technical requirements for a long-term archive service to support such scenarios. From owner-ietf-ltans Wed Oct 6 08:29:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FTbRi067905; Wed, 6 Oct 2004 08:29:37 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FTbeL067904; Wed, 6 Oct 2004 08:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FTZS9067884 for ; Wed, 6 Oct 2004 08:29:36 -0700 (PDT) (envelope-from ulrich.pordesch@zv.fraunhofer.de) Received: from PCTOM (pc-tom [141.12.87.62]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id RAA14502; Wed, 6 Oct 2004 17:29:32 +0200 (MET DST) Message-Id: <200410061529.RAA14502@sonne.sit.fraunhofer.de> From: To: Cc: Subject: draft-ietf-ltans-reqs-02.txt: comments Date: Wed, 6 Oct 2004 17:33:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSrudDvWLcHn3xfRk2cUE90haXhBA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias At the moment I can not answer to all the comments from Denis in detail, as the comments are submitted quite shortly and although vehemently argued, but unfortunately in many cases missing arguments why such things are needed and what the benefit for specific use cases is. As far as I understand, Denis basically has two concerns most of his proposed changes are based on: 1. He wants a cryptographically secured proof of origin for the data, that can be used for an infinite time which user has submitted the data and to which archive provider the data has been submitted. Such a proof is not necessary for the named urging practical use cases as the conservation of evidence (value of proof) of signed documents, but would call for unnecessarily complex procedures/solutions. For the submitting entity itself a signed document that confirms that he has submitted the data is not usable for the long term, as the value of proof of such a signature will also loose its value because of the known and discussed reasons. Possibly some particular use cases exist, which require to be able to proof to a third party that data is from a specific person, as e.g. specific notary services for intellectual property or copy right questions. But those should be treated and solved separately. 2. Denis is introducing the term "Maintenance Policy", that should become a part of the Archive Policy. This term for a concept that has already been mentioned in the paper is ok, but I think the definition of parameters, the intermixture with Signature Policies and other proposals are problematic and should be discussed in detail. The requirements paper is not the right place to discuss this topic in detail. We can incorporate this term and some ideas, but should leave the specification of the details to a separate paper especially dedicated to this question. From owner-ietf-ltans Thu Oct 7 22:31:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i985VvY8073815; Thu, 7 Oct 2004 22:31:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i985VvVf073813; Thu, 7 Oct 2004 22:31:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i985VnS0073696 for ; Thu, 7 Oct 2004 22:31:49 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 07 Oct 2004 22:31:11 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i985UlbA017972; Thu, 7 Oct 2004 22:30:52 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i985UhTk012879; Thu, 7 Oct 2004 22:30:47 -0700 (PDT) Received: from MasinterT40 ([130.248.178.254]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5900M703B7AQ@mailsj-v1.corp.adobe.com>; Thu, 07 Oct 2004 22:30:43 -0700 (PDT) Date: Thu, 07 Oct 2004 22:30:42 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410051553.i95Frpl05845@chandon.edelweb.fr> To: "'Peter Sylvester'" , rhansberger@nationalnotary.org, Denis.Pinkas@bull.net Cc: ietf-ltans@imc.org Message-id: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcSq84878hn3zaADSV6SifZKRlRSswCAxnjw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was unaware of RFC 3029. Should we add a reference to RFC 3029 as an example of what is intended in the requirements document? Would it be reasonable to rename the document: Data Validation and Certification Protocol Requirements and replace 'Notary' with 'Data Validation or Certification Service' as appropriate? RFC 3029 contains a few uses of the word 'notary', but only in descriptions of patents and relationship to prior work. Larry From owner-ietf-ltans Fri Oct 8 02:25:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i989PjEe090841; Fri, 8 Oct 2004 02:25:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i989PjwS090839; Fri, 8 Oct 2004 02:25:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i989Phss090739 for ; Fri, 8 Oct 2004 02:25:44 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA08029; Fri, 8 Oct 2004 11:24:43 +0200 (MET DST) Message-ID: <41665CDA.9080502@sit.fraunhofer.de> Date: Fri, 08 Oct 2004 11:24:42 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: Denis Pinkas CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? References: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> <416652E3.3070900@bull.net> In-Reply-To: <416652E3.3070900@bull.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: Denis, certain examples in the form of scenarios and use-cases are necessary *in the beginning* of this requirements document to delineate the scope, clarify the subject, and provide rationales for the requirements proper. What we have now, including two suggestions I posted earlier on, could already be sufficient if we make good use of RFC3029 as a secondary reference. "e-Certification Serivces" to me seems overly clumsy - reading that title one might wonder what such a thing might do *more* than a CA or a Timestamping Service. At the moment I cannot think of a solid name which avoids the conflicts with the legal domain of notaries public, and still has some impact. How about "Electronic Notary (e-Notary) Services". Still I think we should keep some relation to the title of the WG and not make an ad hoc change which might then persist. With regard to the abstract I would like to stick to Larry's last proposal. AUS Denis Pinkas wrote: > > Larry, > >> I was unaware of RFC 3029. Should we add a reference to >> RFC 3029 as an example of what is intended in the requirements >> document? > > > A requirements document should not simply be a collection of examples. > Examples can certainly be mentionned in informative annexes, but the > core document would still need to say what needs to be supported. > > RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 > would certainly makes sense once we have define the document filling > the requirements (which still need to be defined). RFC 3029 contains > solutions to many problems, but it is not a requirements document. > > Besides the vocabulary problem about the use of the term "notary", we > would have first to define what would be the title and the topic of > the requirements document. I would propose something along the > following strawman proposal: > > "e-Certification Services requirements > > Abstract > > This document defines the requirements for e-Certification services. > Such services may be used when there is a need to register one or many > documents and to certify that these documents have been duly > semantically verified by a given person prior to registration. These > persons may or may not be Notaries, as understood by Civil Law or > Common Law. The document to be certified may or may not contain > electronic signatures from other persons." > > Denis > >> Would it be reasonable to rename the document: >> >> Data Validation and Certification Protocol Requirements >> >> and replace 'Notary' with 'Data Validation or >> Certification Service' as appropriate? >> >> RFC 3029 contains a few uses of the word 'notary', but >> only in descriptions of patents and relationship to >> prior work. >> >> Larry > > > > From owner-ietf-ltans Fri Oct 8 01:43:51 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i988hplw073375; Fri, 8 Oct 2004 01:43:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i988hp8e073373; Fri, 8 Oct 2004 01:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i988hlW8073321 for ; Fri, 8 Oct 2004 01:43:49 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA13760; Fri, 8 Oct 2004 10:55:07 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100810433444:401 ; Fri, 8 Oct 2004 10:43:34 +0200 Message-ID: <416652E3.3070900@bull.net> Date: Fri, 08 Oct 2004 10:42:11 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Larry Masinter CC: ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? References: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/10/2004 10:43:34, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/10/2004 10:43:37, Serialize complete at 08/10/2004 10:43:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Larry, > I was unaware of RFC 3029. Should we add a reference to > RFC 3029 as an example of what is intended in the requirements > document? A requirements document should not simply be a collection of examples. Examples can certainly be mentionned in informative annexes, but the core document would still need to say what needs to be supported. RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 would certainly makes sense once we have define the document filling the requirements (which still need to be defined). RFC 3029 contains solutions to many problems, but it is not a requirements document. Besides the vocabulary problem about the use of the term "notary", we would have first to define what would be the title and the topic of the requirements document. I would propose something along the following strawman proposal: "e-Certification Services requirements Abstract This document defines the requirements for e-Certification services. Such services may be used when there is a need to register one or many documents and to certify that these documents have been duly semantically verified by a given person prior to registration. These persons may or may not be Notaries, as understood by Civil Law or Common Law. The document to be certified may or may not contain electronic signatures from other persons." Denis > Would it be reasonable to rename the document: > > Data Validation and Certification Protocol Requirements > > and replace 'Notary' with 'Data Validation or > Certification Service' as appropriate? > > RFC 3029 contains a few uses of the word 'notary', but > only in descriptions of patents and relationship to > prior work. > > Larry From owner-ietf-ltans Fri Oct 8 06:41:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98DfZji037894; Fri, 8 Oct 2004 06:41:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98DfZnO037893; Fri, 8 Oct 2004 06:41:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98DfYhL037871 for ; Fri, 8 Oct 2004 06:41:34 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i98DfSN22607 for ; Fri, 8 Oct 2004 15:41:28 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 8 Oct 2004 15:41:28 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i98DfSq19213 for ietf-ltans@imc.org; Fri, 8 Oct 2004 15:41:28 +0200 (MEST) Date: Fri, 8 Oct 2004 15:41:28 +0200 (MEST) From: Peter Sylvester Message-Id: <200410081341.i98DfSq19213@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I was unaware of RFC 3029. Something maybe worth to read from the PKIX list almost 4 years ago explaining the status of DVCS = RFC3029 At that time I was tempted to simplify the services in DVCS and to combine the validation of of signed data and certificates into some common thing, i.e., to perform some validation on some document whose structure and semantics are known, and for which a validation procedure is defined. Even with 3029 one has already some bricks of such procedures, one for signed documents, one for attestations itself, several for public key certs where one can distinguish between signature and encryption, etc., ... Furthermore, the validation algorithm itself may include that external services are required, e.g., to archive each "document" and obtain the attestations from someone else. It is not clear (to me) whether such procedures need to implemented as code or as more or less complicated parameters to some generic algorithm. I wonder whether such a technical system is somethig we are looking for as an 'functional architecture of a technical system to support activities of notaries and others' Peter ---- From: Carlisle Adams To: "'kent@bbn.com'" , "'wpolk@nist.gov'" Cc: ietf-pkix@imc.org Subject: The future of DVCS... Date: Wed, 11 Oct 2000 15:40:25 -0400 Hi, Over the past year or more, the question has arisen in various contexts as to the status and role of the DVCS draft, especially with respect to TSP, OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in the future. DVCS precedes and, at some level, encompasses all of these other protocols. However, these protocols -- many of them targeted for the standards track -- have been defined for the twin purposes of simplicity and rapid implementation. They are small and clearly defined; each one tries to solve essentially one problem. DVCS, on the other hand, is intended to be general, embracing the sometimes abstract notion of the validation and certification of arbitrary data. The actual content of the data (the payload) in a sense defines the function of the server (i.e., if the data is a hash of something, then the server is providing a time stamp function; if the data is a certificate, then the server is providing an OCSP or SCVP/DPV function; if the data is a contract or legal document, then the server is providing what (at least in North America) might be called a notarization function; etc.). It's not quite as loose as that, but that's the basic idea. In discussing this protocol with the other authors and with various members of the community, I sense "rough consensus" on two things. Firstly, it makes sense to allow the more clearly-defined subsets of the DVCS functionality to be handled by these other protocols (TSP, OCSP, etc.) since they are relatively well-understood and implementations are already either completed or underway. Secondly, most real-world environments are not yet ready to incorporate notarization functions for other data formats. This higher-layer purpose of DVCS is perhaps too early as a concept to engage serious review and debate within the wider PKIX group right now. Consequently, the authors of DVCS are recommending to the chairs that this specification be preserved as an Experimental RFC. It has received some discussion (both public and private) over the years, but probably not sufficient to warrant progression along the standards track. Furthermore, we are aware of only a single implementation at this time, so any interoperability testing is out of the question, at least at the moment. But enough work has gone into this protocol that letting it expire as an Internet Draft and disappear completely seems inappropriate, especially if (as we suspect) this higher-layer functionality will begin to be required in PKI environments in the one- to three-year time frame. We would like to see the specification frozen and preserved for now; it can always be re-visited later (and even re-targeted for the standards track) if the need arises. In light of this recommendation, further revisions to this document seem unnecessary; the authors are satisfied with the text in this -07 version going to "Experimental" status. Steve, Tim: any comments or alternate suggestions? Carlisle. From owner-ietf-ltans Sun Oct 10 09:23:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AGNdIv076863; Sun, 10 Oct 2004 09:23:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9AGNdld076862; Sun, 10 Oct 2004 09:23:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AGNZah076851 for ; Sun, 10 Oct 2004 09:23:36 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9AGNbN15545; Sun, 10 Oct 2004 18:23:37 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 10 Oct 2004 18:23:37 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9AGNZ624626; Sun, 10 Oct 2004 18:23:35 +0200 (MEST) Date: Sun, 10 Oct 2004 18:23:35 +0200 (MEST) From: Peter Sylvester Message-Id: <200410101623.i9AGNZ624626@chandon.edelweb.fr> To: LMM@acm.org, Denis.Pinkas@bull.net Subject: Re: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Abstract > > This document defines the requirements for e-Certification services. Such > services may be used when there is a need to register one or many documents > and to certify that these documents have been duly semantically verified by > a given person prior to registration. These persons may or may not be > Notaries, as understood by Civil Law or Common Law. The document to be > certified may or may not contain electronic signatures from other persons." > Independant of the usage of the word "e-certification service" I am not sure that the description is what we have in mind as services to be supported by a protocol. What is meant by 'registration'? My understanding was that we can access to a service that performs certain aspects of a semantical verification, and does not only rely on a person doing this, or else, what is proposed looks to me as a front end to an archiving system (which may still be one of the use cases). At best, the title is one possible use case IMO. But I may be wrong. Futhermore, it doesn't seem to me that we have agreement about whether we talk about requirements for a protocol or for a service. To me we arec talking about protocol requirements, i.e. by what means can we access to the services and the functions it provides, and what information we can submit or and what do we obtain. Peter From owner-ietf-ltans Mon Oct 11 03:21:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BAL6Hr064756; Mon, 11 Oct 2004 03:21:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9BAL6jw064755; Mon, 11 Oct 2004 03:21:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BAL4w4064739 for ; Mon, 11 Oct 2004 03:21:05 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9BAL4N25814 for ; Mon, 11 Oct 2004 12:21:04 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 11 Oct 2004 12:21:04 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9BAL4p26805 for ietf-ltans@imc.org; Mon, 11 Oct 2004 12:21:04 +0200 (MEST) Date: Mon, 11 Oct 2004 12:21:04 +0200 (MEST) From: Peter Sylvester Message-Id: <200410111021.i9BAL4p26805@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: draft-ietf-ltans-reqs-02.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have some comments to the "archive service requirements": > Abstract > In many scenarios, users need to be able to prove the existence of > data at a given time and integrity of data, especially digitally > signed data, in a common and reproducible way after an arbitrarily > long period. This document specifies the technical requirements for > a long-term archive service to support such scenarios. Somehow I'd like to see the word "protocol" here. "after an arbitrarily long" is a pretty arbitary term avoid to say nothing precise :-) it seems slightly misleading since we forget that some data MUST be destroyed after a defined time in certain scenarious. This could be explained later in the use cases which could benefit from some important case of let's say a telephone company or an ISP who has to safely store connection data for a definitely limited time, ot certified accountants, "exterts compatbles" "Steuerberater" who must store their raw data for some years but not eternally. Thus the following: > Deletion requests must be authorized and an authorization policy must > be defined and observed by the long-term archive service (as part of > an archive policy). In some cases, deletion may not involve physical > deletion and instead may simply be an early termination of the > archivation period. is somewhat the contrary of what I'd say: Shortening of an archiving period seems to me rather exceptional, but extension must be ensured in case of a conflict between the involved parties. Extension may have some influence of how data can be deleted on some media, if one stores all data of one months for all customers of a telephone company, then not deleting data of one customer may involve that no data are deleted. Such a situation seems bad to me. The requirement should be IMO that when an extension of an archiving period occurs, the archiver service should implement a technique that limits the need of extending other data. Reading Larry's comment, I think defining a good abstract may come in a yoyo technique following the actual texts. I stop here, since I prefer that we first "digest" Denis and Larry's comments in some way. From owner-ietf-ltans Mon Oct 11 18:36:02 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C1a24e061025; Mon, 11 Oct 2004 18:36:02 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9C1a28j061024; Mon, 11 Oct 2004 18:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C1a0x9060992 for ; Mon, 11 Oct 2004 18:36:00 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W9C21Y7N00000A0C; Mon, 11 Oct 2004 18:34:43 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <43VFDB87>; Mon, 11 Oct 2004 18:35:16 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368D14B@Louise2> From: Richard Hansberger To: Andreas.U.Schmidt@sit.fraunhofer.de, Denis Pinkas Cc: Larry Masinter , ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Date: Mon, 11 Oct 2004 18:35:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: fecfb005fa4fbfdc258e42ee1683c84b Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Andreas, The term "Electronic Notary" is perhaps a bit awkward for US Notaries. It might work well in other countries, but in the U.S. we have model legislation that regulates the "Electronic Notary," which a number of states have adopted already. Thus, I could see confusion resulting from this service. "eCertification Services" or "e-certification service" isn't all that clumsy and is, in fact, more acceptable to US Notaries. In the US, we have long recognized that the certification services human Notaries now provide will gradually be replaced by machine services that provide better certification guarantees. Notaries witness; machines certify. It makes sense to me. Rich Hansberger National Notary Association -----Original Message----- From: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@sit.fraunhofer.de] Sent: Friday, October 08, 2004 2:25 AM To: Denis Pinkas Cc: Larry Masinter; ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? Denis, certain examples in the form of scenarios and use-cases are necessary *in the beginning* of this requirements document to delineate the scope, clarify the subject, and provide rationales for the requirements proper. What we have now, including two suggestions I posted earlier on, could already be sufficient if we make good use of RFC3029 as a secondary reference. "e-Certification Serivces" to me seems overly clumsy - reading that title one might wonder what such a thing might do *more* than a CA or a Timestamping Service. At the moment I cannot think of a solid name which avoids the conflicts with the legal domain of notaries public, and still has some impact. How about "Electronic Notary (e-Notary) Services". Still I think we should keep some relation to the title of the WG and not make an ad hoc change which might then persist. With regard to the abstract I would like to stick to Larry's last proposal. AUS Denis Pinkas wrote: > > Larry, > >> I was unaware of RFC 3029. Should we add a reference to >> RFC 3029 as an example of what is intended in the requirements >> document? > > > A requirements document should not simply be a collection of examples. > Examples can certainly be mentionned in informative annexes, but the > core document would still need to say what needs to be supported. > > RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 > would certainly makes sense once we have define the document filling > the requirements (which still need to be defined). RFC 3029 contains > solutions to many problems, but it is not a requirements document. > > Besides the vocabulary problem about the use of the term "notary", we > would have first to define what would be the title and the topic of > the requirements document. I would propose something along the > following strawman proposal: > > "e-Certification Services requirements > > Abstract > > This document defines the requirements for e-Certification services. > Such services may be used when there is a need to register one or many > documents and to certify that these documents have been duly > semantically verified by a given person prior to registration. These > persons may or may not be Notaries, as understood by Civil Law or > Common Law. The document to be certified may or may not contain > electronic signatures from other persons." > > Denis > >> Would it be reasonable to rename the document: >> >> Data Validation and Certification Protocol Requirements >> >> and replace 'Notary' with 'Data Validation or >> Certification Service' as appropriate? >> >> RFC 3029 contains a few uses of the word 'notary', but >> only in descriptions of patents and relationship to >> prior work. >> >> Larry > > > > ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- From owner-ietf-ltans Tue Oct 12 08:14:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFECfS042255; Tue, 12 Oct 2004 08:14:12 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CFECnm042254; Tue, 12 Oct 2004 08:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFE9h0042245 for ; Tue, 12 Oct 2004 08:14:10 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9CFEHN21500; Tue, 12 Oct 2004 17:14:17 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 12 Oct 2004 17:14:17 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9CFEGs01737; Tue, 12 Oct 2004 17:14:16 +0200 (MEST) Date: Tue, 12 Oct 2004 17:14:16 +0200 (MEST) From: Peter Sylvester Message-Id: <200410121514.i9CFEGs01737@chandon.edelweb.fr> To: Andreas.U.Schmidt@sit.fraunhofer.de, Denis.Pinkas@bull.net, rhansberger@nationalnotary.org Subject: RE: Notary services requirements -- directions? Cc: LMM@acm.org, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Merriam-Webster is sometimes helpful: 'notarization' = 1. the act, process, or an instance of notarising. 2. the notarial certificate appended to a document. 'notarize' = to acknowledge or attest as notary public. 'notarial' = 1. of relating to, or characteristic of a notary public 2. donce or executed by a notary public. 'notary public' = a public officer who attests or certifies writings (as a deed) to make them authentic, and takes affidavits, depositions, and protests of negotiable paper. It seems that indeed the words notarXXX are heavily connected to one profession, and, as I conclude from this discussion, notaries don't like someone else playing in their garden. :-) So be it. :-) (As far as I understand from French dictionaries, the words notarisation or notariser seem not to exist in French. I haven't contacted the Acedemy Francaise. It was (maybe) a mistake (of mime?) to have the word in the name of the working group. How can we (escape from)/remedy this situation? We could add a remark "the term is a French word". But, well, before making a title, it seems to me that we may first come to an agreement about *what* protocol we are doing, i.e., the ones between machines that 'certify' something, my view: - act as a more or less automatic tool to perform some defined validation activity - a to 'certify' the result, i.e. authenticating the data. - used in workflows. Note that protocol is meant in a large sense, not just the 'access protocol', there are components for auditable operational requirements, i.e. a service must play the game in the right way, and cannot just pretend to do something. Is it that what we are talking about? It seems that this is what Larry was proposing? Since more than 15 years or 20, we call some beasts 'certification authority', and not 'e-certification authority', I am not sure whether the remark 'clumsy' is related to the prefix 'e-' or to 'e-certification' as a buzzword. "Protocol requirements for (data?) certification services" seems another possibilities, also long and maybe 'clumsy', too. ("Data" in order to avoid a confusion with public key certification) I hope not having added too much confusion to the discussion. Peter From owner-ietf-ltans Tue Oct 12 09:51:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CGpXxY054198; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CGpXI0054197; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CGpXV0054190 for ; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-70-18-234-230.res.east.verizon.net [70.18.234.230]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9CGpZ88027346 for ; Tue, 12 Oct 2004 12:51:36 -0400 Message-Id: <200410121651.i9CGpZ88027346@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Notary services requirements -- directions? Date: Tue, 12 Oct 2004 12:51:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXA In-Reply-To: <200410121514.i9CFEGs01737@chandon.edelweb.fr> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > But, well, before making a title, it seems to me that we may > first come to an agreement about *what* protocol we are > doing, i.e., the ones between machines that 'certify' > something, my view: > > - act as a more or less automatic tool to perform some defined > validation activity > - a to 'certify' the result, i.e. authenticating the data. > - used in workflows. > > Note that protocol is meant in a large sense, not just the > 'access protocol', there are components for auditable > operational requirements, i.e. a service must play the game > in the right way, and cannot just pretend to do something. It seems like we are settling on a few avenues (with existing protocol correlations in parentheses): - long-term signature formats (e.g. ERS) - long-term signature format protocols (e.g. machine-to-machine a la WebDAV or DVCS variant) - server-based data certification protocols (e.g. machine-to-machine a la DVCS) Is there an additional need to define means for representing notarial acts performed by humans? Has anyone been following the OASIS work that was discussed during the San Diego meeting? From owner-ietf-ltans Tue Oct 12 16:25:08 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNP8qV086652; Tue, 12 Oct 2004 16:25:08 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CNP8xs086651; Tue, 12 Oct 2004 16:25:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CNP7ma086645 for ; Tue, 12 Oct 2004 16:25:07 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 12 Oct 2004 16:25:02 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i9CNP2bA000539; Tue, 12 Oct 2004 16:25:07 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9CNP10S024290; Tue, 12 Oct 2004 16:25:02 -0700 (PDT) Received: from MasinterT40 (c-130-169.corp.adobe.com [153.32.130.169]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5H009DLVPPWA@mailsj-v1.corp.adobe.com>; Tue, 12 Oct 2004 16:25:01 -0700 (PDT) Date: Tue, 12 Oct 2004 16:25:01 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410121651.i9CGpZ88027346@host13.websitesource.com> To: "'Carl Wallace'" Cc: ietf-ltans@imc.org Message-id: <0I5H009DMVPPWA@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Personally, I don't think we get into too much trouble using the word 'Notary' in the title of the working group or even in the title of a document here and there, as long as we're clear -- after all, it's a term that's been used already in the industry, and we're not particularly offering those services for sale, in any case. I think the requirements document might note that the term may have restricted use in some legal jurisdictions, and I think it is reasonable to add some wording to that effect. Are time-stamping services associated with unsigned data out of scope, because they're already covered? Are combined archive-and-certification services (which archive data and also provide for the certification of the data archived) out of scope? Larry From owner-ietf-ltans Tue Oct 12 16:35:16 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNZGaJ087104; Tue, 12 Oct 2004 16:35:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CNZG6A087103; Tue, 12 Oct 2004 16:35:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNZFwE087096 for ; Tue, 12 Oct 2004 16:35:15 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace ([70.21.11.69]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9CNZQ88015582; Tue, 12 Oct 2004 19:35:26 -0400 Message-Id: <200410122335.i9CNZQ88015582@host13.websitesource.com> From: "Carl Wallace" To: "'Larry Masinter'" Cc: Subject: RE: Notary services requirements -- directions? Date: Tue, 12 Oct 2004 19:35:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnAAAFwFIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <0I5H009DMVPPWA@mailsj-v1.corp.adobe.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Tuesday, October 12, 2004 7:25 PM > Subject: RE: Notary services requirements -- directions? > > Personally, I don't think we get into too much trouble using > the word 'Notary' in the title of the working group or even > in the title of a document here and there, as long as we're > clear -- after all, it's a term that's been used already in > the industry, and we're not particularly offering those > services for sale, in any case. I don't mind the title either. > I think the requirements document might note that the term > may have restricted use in some legal jurisdictions, and I > think it is reasonable to add some wording to that effect. > > Are time-stamping services associated with unsigned data out > of scope, because they're already covered? I'm not sure what you mean out of scope. If you mean outside the scope for new specification work, I think so. If you mean outside the scope of what we may refer to as a notary service, I don't think so. Timestamping seems like a fundamental component. We've explicitly included support for unsigned data in the archive discussion and since those have so far been discussed pretty much solely in terms timestamp solutions, I think this is in scope (if already covered elsewhere). > Are combined archive-and-certification services (which > archive data and also provide for the certification of the > data archived) out of scope? I think this combination is very much in scope. It seems natural for the data certification service we define to be capable of verifying the structures defined for long-term archive purposes. For some purposes, this combination may be invest too much trust in a single entity. For other purposes, it seems like the ideal pairing (e.g. a binding that verified the evidence record upon data retrieval). > > Larry > From owner-ietf-ltans Thu Oct 14 04:27:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBR6Ol067890; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBR6b2067889; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBR547067843 for ; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9EBQsN21858; Thu, 14 Oct 2004 13:26:54 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 14 Oct 2004 13:26:54 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9EBQs109572; Thu, 14 Oct 2004 13:26:54 +0200 (MEST) Date: Thu, 14 Oct 2004 13:26:54 +0200 (MEST) From: Peter Sylvester Message-Id: <200410141126.i9EBQs109572@chandon.edelweb.fr> To: LMM@acm.org Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Personally, I don't think we get into too much trouble > using the word 'Notary' in the title of the working group > or even in the title of a document here and there, as long > as we're clear -- after all, it's a term that's been used > already in the industry, and we're not particularly offering > those services for sale, in any case. I tend to agree. > > I think the requirements document might note that the > term may have restricted use in some legal jurisdictions, > and I think it is reasonable to add some wording to that effect. Would someone mind writing down a small paragraph that could explain the issue, i.e., resume the last exchange of messages, so we have something to be put into the RFCs but also I can add this in a kind of disclaimer section in the web server in order to avoid that in a few months new participants ... > > Are time-stamping services associated with unsigned > data out of scope, because they're already covered? - Time stamping of signed data, i.e. digital signature is also already covered by existing proposals. - I think we have several questions to clarify, like - what are "our" requirements of the stability of time stamps, i.e., currently they are at best the 'lifetime' of a hash function. - what means does archiving provide (or not), to cover long term, e.g., if I just have to archive invoices for about three months, i can live withe short term time stamping. (to be a litle bit provocative, current time stamps are not good for long term IMO, since they were never intended as such) > Are combined archive-and-certification services > (which archive data and also provide for the certification > of the data archived) out of scope? - If we make it right, then we have just a combination of three quarks: Notarisation (voluntarily written with an s), Archiving, and Evidence creation/recording to do this. Or, in other words, it is a particular use case of a combination of basic techniques. - The role of such a notary can just be "I perform the archiving, and certify that the "reference" returned from the archive. Whether one consider this minimal notarisation as a front end client related service of the archive or as an independant service, seems to me an organisational matter, or, in other words, it depends on the client needs. - There may be a lot of cases where the information (the references) provided by the archiver does not need to be "secured" at lot when given to the client. That's why I think it is important to clearly distinguish between (more or less real time) security measures and the payload. - As far as I have understood from discussions with notaries there is some particular kind of archive+notary application which is based on the observation that notaries (at least in some places) perform some information reduction, for example, a 'signature validation' can be done in such a way that the notary collects all the validation data, performs the validation, time stamps all that, archives them, but just delivers a statement that everything is of+the refereces to the archive. in fact, the archived data correspond to his activity log. This is somehow the exact opposite operation of what is provided by some profile of DVCS or by SCVP, where the validation data are returned by a service. Again, an information reducing notary would be able to ask an information collecting service (+ a validator) to provide the information, then all this can be archived, and a 'reduced' result produced. If one looks at such use cases as molecules, I wonder where are our atoms. Peter From owner-ietf-ltans Thu Oct 14 10:00:24 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EH0OCV020187; Thu, 14 Oct 2004 10:00:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EH0OiL020186; Thu, 14 Oct 2004 10:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EH0KJQ020166 for ; Thu, 14 Oct 2004 10:00:23 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9EH0KN26694; Thu, 14 Oct 2004 19:00:20 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 14 Oct 2004 19:00:20 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9EH0KS10805; Thu, 14 Oct 2004 19:00:20 +0200 (MEST) Date: Thu, 14 Oct 2004 19:00:20 +0200 (MEST) From: Peter Sylvester Message-Id: <200410141700.i9EH0KS10805@chandon.edelweb.fr> To: ietf-ltans@imc.org, cwallace@orionsec.com Subject: RE: Notary services requirements -- directions? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Is there an additional need to define means for representing notarial acts > performed by humans? > No. The best is to have the equivalent of a framework paper that has a free form text place where the nature of the notarial act and anything else can be noted. These elements are not subject to automatic treatment by our core protocol it may be useful to more than "free' text, i.e. some schema or oid based document piece like for soap content or CMS content types, in order to allow plugin logic do additional work for semantic validation in a correct way. This represents 'go to office number 1234 and obtains forms type XA-856b ...' :-) From owner-ietf-ltans Thu Oct 14 11:02:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EI2Zlx030729; Thu, 14 Oct 2004 11:02:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EI2ZhH030728; Thu, 14 Oct 2004 11:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EI2YTJ030722 for ; Thu, 14 Oct 2004 11:02:34 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (97.sub-166-180-59.myvzw.com [166.180.59.97]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9EI2Xfn027935; Thu, 14 Oct 2004 14:02:34 -0400 Message-Id: <200410141802.i9EI2Xfn027935@host13.websitesource.com> From: "Carl Wallace" To: "'Peter Sylvester'" , Subject: RE: Notary services requirements -- directions? Date: Thu, 14 Oct 2004 14:02:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200410141700.i9EH0KS10805@chandon.edelweb.fr> Thread-Index: AcSyEOOLPoyriYt8SMauU+iDWoljrwABe5jg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Is there an additional need to define means for > representing notarial > > acts performed by humans? > > > No. The best is to have the equivalent of a framework paper > that has a free form text place where the nature of the > notarial act and anything else can be noted. > > These elements are not subject to automatic treatment by our > core protocol > > it may be useful to more than "free' text, i.e. some schema > or oid based document piece like for soap content or CMS > content types, in order to allow plugin logic do additional > work for semantic validation in a correct way. Seems like part of you says "No" and another part says "Yes":-) A schema, or some such, might be a useful parallel to the signature formats, bindings and certification protocol. From owner-ietf-ltans Fri Oct 15 03:13:12 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FADCgt058302; Fri, 15 Oct 2004 03:13:12 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FADCSI058301; Fri, 15 Oct 2004 03:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FAD8DE058275 for ; Fri, 15 Oct 2004 03:13:11 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9FAD9N07623; Fri, 15 Oct 2004 12:13:09 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 15 Oct 2004 12:13:09 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9FAD8E13467; Fri, 15 Oct 2004 12:13:08 +0200 (MEST) Date: Fri, 15 Oct 2004 12:13:08 +0200 (MEST) From: Peter Sylvester Message-Id: <200410151013.i9FAD8E13467@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, cwallace@orionsec.com Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Is there an additional need to define means for > > representing notarial > > > acts performed by humans? > > > > > No. The best is to have the equivalent of a framework paper > > that has a free form text place where the nature of the > > notarial act and anything else can be noted. > > > > These elements are not subject to automatic treatment by our > > core protocol > > > > it may be useful to more than "free' text, i.e. some schema > > or oid based document piece like for soap content or CMS > > content types, in order to allow plugin logic do additional > > work for semantic validation in a correct way. > > Seems like part of you says "No" and another part says "Yes":-) A schema, > or some such, might be a useful parallel to the signature formats, bindings > and certification protocol. It seems to me that your question has two aspects: - The content to be notarized - The notarization (envelope) I am just saying that we probably would not go further down that having a common envelope for some 'ANY DEFINED BY' (to use some obsolete terminology), a 'signature format' if one prefers this term. it looks like we have a similarity with the problem of archive transformation and metadata, i.e., the extent to which an archiver has knowledge about the relationship of 'outer' metadata and some 'inner' structure of the data. From owner-ietf-ltans Fri Oct 15 09:20:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FGKhk9010201; Fri, 15 Oct 2004 09:20:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FGKg4f010200; Fri, 15 Oct 2004 09:20:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.98.ixos.de [149.235.31.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FGKfPk010190 for ; Fri, 15 Oct 2004 09:20:41 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id i9FGKXRX019954; Fri, 15 Oct 2004 18:20:34 +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: Notary services requirements -- directions? Date: Fri, 15 Oct 2004 18:20:26 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B07049D74E@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notary services requirements -- directions? Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnAAAFwFIACH0DhQ From: "Tobias Gondrom" To: "Carl Wallace" , "Larry Masinter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9FGKgPk010195 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > From: Larry Masinter [mailto:LMM@acm.org] > > Sent: Tuesday, October 12, 2004 7:25 PM > > Subject: RE: Notary services requirements -- directions? > > > > Personally, I don't think we get into too much trouble using > > the word 'Notary' in the title of the working group or even > > in the title of a document here and there, as long as we're > > clear -- after all, it's a term that's been used already in > > the industry, and we're not particularly offering those > > services for sale, in any case. > > I don't mind the title either. I also agree. I can understand possible problems when a company sells a notary service and is not allowed to, but this is neither the case with the name of the WG or the Name of the requirements - basically I like to call the things by the best fitting name if I find one at all... ;-) So I see no problem calling a document requirements for notary services, e.g. > > > I think the requirements document might note that the term > > may have restricted use in some legal jurisdictions, and I > > think it is reasonable to add some wording to that effect. Full ACK, although I wouldn't add too much - there will always be one place in the world where some wording might cause legal conflicts and it is always up to the companies to resolve these conflicts when the implement things and sell products to local customers. > > Are time-stamping services associated with unsigned data out > > of scope, because they're already covered? > > I'm not sure what you mean out of scope. If you mean outside the scope > for > new specification work, I think so. If you mean outside the scope of what > we may refer to as a notary service, I don't think so. Timestamping seems > like a fundamental component. We've explicitly included support for > unsigned data in the archive discussion and since those have so far been > discussed pretty much solely in terms timestamp solutions, I think this is > in scope (if already covered elsewhere). > > > Are combined archive-and-certification services (which > > archive data and also provide for the certification of the > > data archived) out of scope? > > I think this combination is very much in scope. It seems natural for the > data certification service we define to be capable of verifying the > structures defined for long-term archive purposes. For some purposes, > this > combination may be invest too much trust in a single entity. For other > purposes, it seems like the ideal pairing (e.g. a binding that verified > the > evidence record upon data retrieval). I also agree with Carl - this is a possible but not necessary combination. Tobias From owner-ietf-ltans Fri Oct 15 11:52:48 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FIqm6q032946; Fri, 15 Oct 2004 11:52:48 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FIqmeQ032945; Fri, 15 Oct 2004 11:52:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FIqhbQ032915 for ; Fri, 15 Oct 2004 11:52:43 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W9FJ2G4F00000980; Fri, 15 Oct 2004 11:52:04 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <48NKMTN5>; Fri, 15 Oct 2004 11:52:08 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> From: Richard Hansberger To: "'Tobias Gondrom'" , "'Carl Wallace'" , "'Larry Masinter'" Cc: "'ietf-ltans@imc.org'" Subject: RE: Notary services requirements -- directions? Date: Fri, 15 Oct 2004 11:52:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 78da53b36e0a1dbb172d7c3334a0c957 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Respectfully, I'll disagree with the determination that "notary service" is an appropriate term. Here in the states, we went through a similar debate when major CAs and others offered "digital notary services" in the wake of passage of the Federal "E-Sign" Act. Personally, I think it had a detrimental effect overall and all these "services" have since closed up shop or been renamed, but that's just my opinion. What Notaries do, in other words, has little to do with the certification that a document is a true and original copy. Notaries witness signings, take oaths and affirmations, and perform other in-person kinds of functions. I guess I'm just sensitive to the appropriation of the word as an adjective. Notary is a noun;-) Regardless, if the majority feels it is appropriate then I'll oblige and say no more. Thanks, Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Tobias Gondrom [mailto:tobias@ixos.de] Sent: Friday, October 15, 2004 8:20 AM To: Carl Wallace; Larry Masinter Cc: ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > > From: Larry Masinter [mailto:LMM@acm.org] > > Sent: Tuesday, October 12, 2004 7:25 PM > > Subject: RE: Notary services requirements -- directions? > > > > Personally, I don't think we get into too much trouble using > > the word 'Notary' in the title of the working group or even > > in the title of a document here and there, as long as we're > > clear -- after all, it's a term that's been used already in > > the industry, and we're not particularly offering those > > services for sale, in any case. > > I don't mind the title either. I also agree. I can understand possible problems when a company sells a notary service and is not allowed to, but this is neither the case with the name of the WG or the Name of the requirements - basically I like to call the things by the best fitting name if I find one at all... ;-) So I see no problem calling a document requirements for notary services, e.g. > > > I think the requirements document might note that the term > > may have restricted use in some legal jurisdictions, and I > > think it is reasonable to add some wording to that effect. Full ACK, although I wouldn't add too much - there will always be one place in the world where some wording might cause legal conflicts and it is always up to the companies to resolve these conflicts when the implement things and sell products to local customers. > > Are time-stamping services associated with unsigned data out > > of scope, because they're already covered? > > I'm not sure what you mean out of scope. If you mean outside the scope > for > new specification work, I think so. If you mean outside the scope of what > we may refer to as a notary service, I don't think so. Timestamping seems > like a fundamental component. We've explicitly included support for > unsigned data in the archive discussion and since those have so far been > discussed pretty much solely in terms timestamp solutions, I think this is > in scope (if already covered elsewhere). > > > Are combined archive-and-certification services (which > > archive data and also provide for the certification of the > > data archived) out of scope? > > I think this combination is very much in scope. It seems natural for the > data certification service we define to be capable of verifying the > structures defined for long-term archive purposes. For some purposes, > this > combination may be invest too much trust in a single entity. For other > purposes, it seems like the ideal pairing (e.g. a binding that verified > the > evidence record upon data retrieval). I also agree with Carl - this is a possible but not necessary combination. Tobias ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- From owner-ietf-ltans Fri Oct 15 21:18:07 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9G4I7VC024118; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9G4I7MW024117; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9G4I4Vm024102 for ; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I5N00KS3S9FI0@igw.noorhome.net> for ietf-ltans@imc.org; Fri, 15 Oct 2004 20:56:03 -0700 (PDT) Date: Fri, 15 Oct 2004 21:17:56 -0700 From: Arshad Noor Subject: Re: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> To: "'ietf-ltans@imc.org'" Message-id: <4170A0F4.7030801@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 References: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seems to me, the list is struggling with two different issues: 1) the protocols and standards associated with verifying the authenticity of a document over very long periods; and 2) the potential use of such technology to maintain the legal validity of documents that were presumably electronically notarized by human notaries. I believe it is possible for the WG to achieve #1 without being concerned about #2. If specific business groups (Notaries) wish to create legal bindings around the technical protocols, so be it. The technical standards should support that outcome without being concerned about what human notaries do - value-added integrators, software & hardware vendors will worry about that using the standards & protocols established by this WG. Since legitimate businesses - even outside the notarial areas - will have use for such technology, it behooves this group to maintain focus on #1 without being concerned about #2. I would recommend the use of something along the lines of "Long-term Data Validation Protocol" to remain industry-neutral. Arshad Noor StrongAuth, Inc. Richard Hansberger wrote: > Respectfully, I'll disagree with the determination that "notary service" is > an appropriate term. Here in the states, we went through a similar debate > when major CAs and others offered "digital notary services" in the wake of > passage of the Federal "E-Sign" Act. Personally, I think it had a > detrimental effect overall and all these "services" have since closed up > shop or been renamed, but that's just my opinion. > > What Notaries do, in other words, has little to do with the certification > that a document is a true and original copy. Notaries witness signings, take > oaths and affirmations, and perform other in-person kinds of functions. I > guess I'm just sensitive to the appropriation of the word as an adjective. > Notary is a noun;-) > > Regardless, if the majority feels it is appropriate then I'll oblige and say > no more. > > Thanks, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > From owner-ietf-ltans Sat Oct 16 11:37:15 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GIbE7D025240; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9GIbEEn025239; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GIbDiS025202 for ; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from [172.0.0.1] ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 16 Oct 2004 13:37:15 -0500 Received: from no.name.available by [172.0.0.1] via smtpd (for [200.57.34.107] [200.57.34.107]) with ESMTP; Sat, 16 Oct 2004 13:33:21 -0600 From: "Miguel Rodriguez" To: Subject: RE: Notary services requirements -- directions? Date: Sat, 16 Oct 2004 13:33:11 -0500 Message-ID: <001001c4b3ae$97aa7a70$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4170A0F4.7030801@strongauth.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 16 Oct 2004 18:37:15.0703 (UTC) FILETIME=[28B84470:01C4B3AF] Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Mr Moor's point of view. Miguel A Rodriguez SeguriData Mexico > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Arshad Noor > Sent: Friday, October 15, 2004 11:18 PM > To: 'ietf-ltans@imc.org' > Subject: Re: Notary services requirements -- directions? > > > > Seems to me, the list is struggling with two different issues: > > 1) the protocols and standards associated with verifying the > authenticity of a document over very long periods; and > > 2) the potential use of such technology to maintain the legal > validity of documents that were presumably electronically > notarized by human notaries. > > I believe it is possible for the WG to achieve #1 without being > concerned about #2. If specific business groups (Notaries) wish > to create legal bindings around the technical protocols, so be it. > The technical standards should support that outcome without being > concerned about what human notaries do - value-added integrators, > software & hardware vendors will worry about that using the > standards & protocols established by this WG. > > Since legitimate businesses - even outside the notarial areas - > will have use for such technology, it behooves this group to > maintain focus on #1 without being concerned about #2. > > I would recommend the use of something along the lines of > "Long-term Data Validation Protocol" to remain industry-neutral. > > Arshad Noor > StrongAuth, Inc. From owner-ietf-ltans Mon Oct 18 00:09:14 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I79EiB092470; Mon, 18 Oct 2004 00:09:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I79EZ4092469; Mon, 18 Oct 2004 00:09:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout01.datevnet.de (mailout01.datevnet.de [193.27.50.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9I79CZo092372 for ; Mon, 18 Oct 2004 00:09:13 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 12187 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from mail01.services.datevnet.de (10.252.80.78) by mailout01.services.datevnet.de with SMTP; 18 Oct 2004 07:08:55 -0000 Received: (qmail 16772 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from localhost (HELO mail01.services.datev.de) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 18 Oct 2004 07:08:55 -0000 Received: (qmail 16767 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 18 Oct 2004 07:08:55 -0000 From: "Michael Tielemann" To: Subject: AW: Notary services requirements -- directions? Date: Mon, 18 Oct 2004 09:09:00 +0200 Message-ID: <001a01c4b4e1$57d2a380$9c01fb0a@P25823E0> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4170A0F4.7030801@strongauth.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9I79DZo092462 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That's it. A technical standard should be open for different scenarios. It's up to the standard to provide a common basis for implementing applications on top of it. We should understand the wg group results as a vehicle for any technical approach, e.g #1 I guess the recommandation "Long-term Data Validation Protocol" is a good one. -Michael Tielemann > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Arshad Noor > Gesendet: Samstag, 16. Oktober 2004 06:18 > An: 'ietf-ltans@imc.org' > Betreff: Re: Notary services requirements -- directions? > > > > Seems to me, the list is struggling with two different issues: > > 1) the protocols and standards associated with verifying the > authenticity of a document over very long periods; and > > 2) the potential use of such technology to maintain the legal > validity of documents that were presumably electronically > notarized by human notaries. > > I believe it is possible for the WG to achieve #1 without > being concerned about #2. If specific business groups > (Notaries) wish to create legal bindings around the technical > protocols, so be it. The technical standards should support > that outcome without being concerned about what human > notaries do - value-added integrators, software & hardware > vendors will worry about that using the standards & protocols > established by this WG. > > Since legitimate businesses - even outside the notarial areas > - will have use for such technology, it behooves this group > to maintain focus on #1 without being concerned about #2. > > I would recommend the use of something along the lines of > "Long-term Data Validation Protocol" to remain industry-neutral. > > Arshad Noor > StrongAuth, Inc. > > Richard Hansberger wrote: > > Respectfully, I'll disagree with the determination that "notary > > service" is an appropriate term. Here in the states, we > went through a > > similar debate when major CAs and others offered "digital notary > > services" in the wake of passage of the Federal "E-Sign" Act. > > Personally, I think it had a detrimental effect overall and > all these > > "services" have since closed up shop or been renamed, but > that's just > > my opinion. > > > > What Notaries do, in other words, has little to do with the > > certification that a document is a true and original copy. Notaries > > witness signings, take oaths and affirmations, and perform other > > in-person kinds of functions. I guess I'm just sensitive to the > > appropriation of the word as an adjective. Notary is a noun;-) > > > > Regardless, if the majority feels it is appropriate then > I'll oblige > > and say no more. > > > > Thanks, > > > > Richard J. Hansberger > > Director of eNotarization > > National Notary Association > > 818-739-4027 > > > > > From owner-ietf-ltans Mon Oct 18 00:54:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I7sdIZ009484; Mon, 18 Oct 2004 00:54:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I7sdwk009483; Mon, 18 Oct 2004 00:54:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I7sbp9009404 for ; Mon, 18 Oct 2004 00:54:38 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA80236; Mon, 18 Oct 2004 10:06:07 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101809542352:1603 ; Mon, 18 Oct 2004 09:54:23 +0200 Message-ID: <41737645.6010507@bull.net> Date: Mon, 18 Oct 2004 09:52:37 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Richard Hansberger CC: "'ietf-ltans@imc.org'" Subject: Re: Notary services requirements -- directions? References: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 09:54:23, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 09:54:25, Serialize complete at 18/10/2004 09:54:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, I do understand that it is important to say exactly what means "notary service" or "Notary service". The first sentence of the abstract of the draft on "Notary Services requirements" is is too vague and thus does not provide an adequate explanation: Notary services are available today in a wide variety for paper based processes and documents. Until we agree on a definition of "notary service" or "Notary service", we will have endless discussions. The current text states: The functions of notaries include the attestation of documents and certification of their due execution, administering of oaths, witnessing affidavits and statutory declarations, certification of copy documents, noting and protesting of bills of exchange and the preparation of ships' protests. This tells what the functions of notaries are, but still does not tell what notary services are or will be. Later on the text says: A notary service should support and enable a human notary to fullfill his tasks with electronic documents as well as he already does with paper based documents and processes. This is is closer but still does not tell what "notary services" are or will be. Finally we have: Notary service: electronic service that supports a human notary to provide his/her services on electronic based processes and documents. Is this definition sufficient ? I do not think so, since it is too broad and is not self-descriptive. I understand that the "notaries services" that we will consider will only cover a *subset* of all the services a (human) Notary can perform, and we have not yet identified that subset of services and both the different or common characteristics of that subset. So I ask the editor (or others) to propose a strawman definition that we can discuss. Denis > Respectfully, I'll disagree with the determination that "notary service" is > an appropriate term. Here in the states, we went through a similar debate > when major CAs and others offered "digital notary services" in the wake of > passage of the Federal "E-Sign" Act. Personally, I think it had a > detrimental effect overall and all these "services" have since closed up > shop or been renamed, but that's just my opinion. > > What Notaries do, in other words, has little to do with the certification > that a document is a true and original copy. Notaries witness signings, take > oaths and affirmations, and perform other in-person kinds of functions. I > guess I'm just sensitive to the appropriation of the word as an adjective. > Notary is a noun;-) > > Regardless, if the majority feels it is appropriate then I'll oblige and say > no more. > > Thanks, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias@ixos.de] > Sent: Friday, October 15, 2004 8:20 AM > To: Carl Wallace; Larry Masinter > Cc: ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > > > > >>>From: Larry Masinter [mailto:LMM@acm.org] >>>Sent: Tuesday, October 12, 2004 7:25 PM >>>Subject: RE: Notary services requirements -- directions? >>> >>>Personally, I don't think we get into too much trouble using >>>the word 'Notary' in the title of the working group or even >>>in the title of a document here and there, as long as we're >>>clear -- after all, it's a term that's been used already in >>>the industry, and we're not particularly offering those >>>services for sale, in any case. >> >>I don't mind the title either. > > > I also agree. I can understand possible problems when a company sells a > notary service and is not allowed to, but this is neither the case with > the name of the WG or the Name of the requirements - basically I like to > call the things by the best fitting name if I find one at all... ;-) > > So I see no problem calling a document requirements for notary services, > e.g. > > >>>I think the requirements document might note that the term >>>may have restricted use in some legal jurisdictions, and I >>>think it is reasonable to add some wording to that effect. >> > > Full ACK, although I wouldn't add too much - there will always be one > place in the world where some wording might cause legal conflicts and it > is always up to the companies to resolve these conflicts when the > implement things and sell products to local customers. > > > >>>Are time-stamping services associated with unsigned data out >>>of scope, because they're already covered? >> >>I'm not sure what you mean out of scope. If you mean outside the > > scope > >>for >>new specification work, I think so. If you mean outside the scope of > > what > >>we may refer to as a notary service, I don't think so. Timestamping > > seems > >>like a fundamental component. We've explicitly included support for >>unsigned data in the archive discussion and since those have so far > > been > >>discussed pretty much solely in terms timestamp solutions, I think > > this is > >>in scope (if already covered elsewhere). >> >> >>>Are combined archive-and-certification services (which >>>archive data and also provide for the certification of the >>>data archived) out of scope? >> >>I think this combination is very much in scope. It seems natural for > > the > >>data certification service we define to be capable of verifying the >>structures defined for long-term archive purposes. For some purposes, >>this >>combination may be invest too much trust in a single entity. For > > other > >>purposes, it seems like the ideal pairing (e.g. a binding that > > verified > >>the >>evidence record upon data retrieval). > > > I also agree with Carl - this is a possible but not necessary > combination. > > Tobias > > > ------------------------------------------------------------------------ > > This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. From owner-ietf-ltans Mon Oct 18 09:14:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGETD2051739; Mon, 18 Oct 2004 09:14:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGETVk051738; Mon, 18 Oct 2004 09:14:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.98.ixos.de [149.235.31.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGERG2051708 for ; Mon, 18 Oct 2004 09:14:28 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from samxg01.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id i9IGDnXi019459; Mon, 18 Oct 2004 18:13:51 +0200 (MEST) Received: from MUCXGC1.opentext.net ([149.235.128.13]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Oct 2004 09:13:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Notary services requirements -- directions? Date: Mon, 18 Oct 2004 18:13:43 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B07049D898@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notary services requirements -- directions? Thread-Index: AcS06XnetMoLKwFLRimESNSXkJs/NQAQzDFw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Denis Pinkas" , "Richard Hansberger" Cc: X-OriginalArrivalTime: 18 Oct 2004 16:13:49.0058 (UTC) FILETIME=[7395F620:01C4B52D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9IGESG2051731 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I fully agree with Denis statement that we need to clarify more what kind of services should be offered per example. E.g. should there be a service for administering of oaths (just to choose one) - how would it look like ? Please, this is the question for me to the mailing list: What kind of use case/scenario do you see ? I would really appreciate a first version of a strawman definition so that we can focus again on gaining a hold on what the definition should be. Tobias > The current text states: > > The functions of notaries > include the attestation of documents and certification of their due > execution, administering of oaths, witnessing affidavits and > statutory declarations, certification of copy documents, noting and > protesting of bills of exchange and the preparation of ships' > protests. > > This tells what the functions of notaries are, but still does not tell > what > notary services are or will be. > > Later on the text says: > > A notary service should support and enable a human notary to fullfill > his tasks with electronic documents as well as he already does with > paper based documents and processes. > > This is is closer but still does not tell what "notary services" are or > will be. > > Finally we have: > > Notary service: electronic service that supports a human notary > to provide his/her services on electronic based processes and > documents. > > Is this definition sufficient ? I do not think so, since it is too broad > and > is not self-descriptive. > > I understand that the "notaries services" that we will consider will only > cover a *subset* of all the services a (human) Notary can perform, and we > have not yet identified that subset of services and both the different or > common characteristics of that subset. > > So I ask the editor (or others) to propose a strawman definition that we > can > discuss. > > Denis From owner-ietf-ltans Mon Oct 18 11:04:04 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II44kS073908; Mon, 18 Oct 2004 11:04:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9II44ki073907; Mon, 18 Oct 2004 11:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II42lD073895 for ; Mon, 18 Oct 2004 11:04:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9II45N22365; Mon, 18 Oct 2004 20:04:05 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 18 Oct 2004 20:04:05 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9II44p23059; Mon, 18 Oct 2004 20:04:04 +0200 (MEST) Date: Mon, 18 Oct 2004 20:04:04 +0200 (MEST) From: Peter Sylvester Message-Id: <200410181804.i9II44p23059@chandon.edelweb.fr> To: Denis.Pinkas@bull.net, rhansberger@nationalnotary.org, tobias@ixos.de Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, I thought that the discussion of last days indicated that the protocols for 'notarisation' (voluntarily written with an s) are NOT there to define all and everything what a 'notary' can do or DOES and exclusively a notary, but rather technical services that can/may be used by notaries but also by other people/services. ==> more use cases necessary, not just 'a notary'. e.g. B&B a "service" in a company that needs to countersign all outgoing invoices, contracts, letters, whatever (this service talks to a company archiver). A service can be implemented by a machine process combined with some persons who 'confirm'. Here some concrete text. - The protocol intends to have a 'client' delegate some validation and procedural activity to some entity that will deliver an attestation concerning the operation. - An attestation contains payload data and may eventually contain a security envelope. - The payload can occur in at least two flavors: - An information collection attestation, including all things that have been done. (signed document is valid because the follwing CAs are trustworthy, and I have performed the validation against CRL etc etc) - An information reduction attestation, i.e. 'this document is valid according to policy, details of my activities concerning this statement may be obtained via reference xyz' - Security envelopes of attestion can come from persons or machines (with the common understanding of 'a person making a digital signature' - Since we seem to operate in context of digital signature, some particular 'validation policy' concerns the validity of digital signatures and, in particular, for attestations. - ERS and archives techniques are most likely used in order to ensure long term validity (if necessary), either explicitly towards the clients, or internally to the service (securing and archiving an activity log). - The protocol is not intended to replace whatever activity of a notary by a totally automated process. Well, my few cents. Peter BTW: http://www.edelweb.fr/EdelStuff/EdelNews/#first Thanks in advance PS: I'd like to know how others are preparing the drafts, I have good experience with Marshall Rose' XML based tool, if this could be used, I propose to make the xml version available in the web server, contributions seem easier to make, not even speaking about the work that we canb save to the rfc editor. The reverse engineering of a draft to an nroff input creates a horrible amount of pbs. From owner-ietf-ltans Mon Oct 18 16:25:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9INPf2c029929; Mon, 18 Oct 2004 16:25:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9INPfxQ029928; Mon, 18 Oct 2004 16:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [64.18.1.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9INPchD029909 for ; Mon, 18 Oct 2004 16:25:38 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 18 Oct 2004 16:25:13 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9INPYNf015379; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9INPYTk014766; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Received: from MasinterT40 (c-130-169.corp.adobe.com [153.32.130.169]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S003Q3ZQMJV@mailsj-v1.corp.adobe.com>; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Date: Mon, 18 Oct 2004 16:25:34 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410181804.i9II44p23059@chandon.edelweb.fr> To: "'Peter Sylvester'" Cc: ietf-ltans@imc.org Message-id: <0I5S003Q4ZQMJV@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcS1PqckElJM22c7RZmbKT7U7EwLpAAKjAjA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I and the other editors of the notary services requirements draft will be attempting to take feedback so far and integrate it into the document. I already converted the document to XML a while back, but there's nothing to be posted yet. I hope we'll have a new version before the Monday cutoff. Larry -- http://larry.masinter.net From owner-ietf-ltans Fri Oct 22 16:10:57 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNAvYg035754; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNAv9J035753; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob5.obsmtp.com [64.18.1.215]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MNAvU0035742 for ; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Fri, 22 Oct 2004 16:10:45 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9MNB0ph002976 for ; Fri, 22 Oct 2004 16:11:00 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9MNAx0S012927 for ; Fri, 22 Oct 2004 16:11:00 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I60003T8DQB9T@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Fri, 22 Oct 2004 16:10:59 -0700 (PDT) Date: Fri, 22 Oct 2004 16:10:59 -0700 From: Larry Masinter Subject: Document submitted for draft-ietf-ltans-notareq-01.txt To: ietf-ltans@imc.org Message-id: <0I60003T9DQB9T@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcS4jGR+4QH4daWZRHubySDoeWrq2A== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: After some discussion with co-editors of the document (and some subsequent reorganization on my own), I've submitted a new version of the 'notareq' document. The title is now 'Requirements for Certification Services'. Most of the document is significantly rewritten. There is still need for quite a bit of work. If you would like a preview before the internet draft is available, you may find this at: http://larry.masinter.net/ltans-notary-req.txt (plain text, what was submitted) http://larry.masinter.net/ltans-notary-req.xml (source xml, should view) http://larry.masinter.net/ltans-notary-req.html (html transformation) Larry From owner-ietf-ltans Sun Oct 24 14:53:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLrhkY099741; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLrhYo099740; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLrgAh099731 for ; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-70-17-123-202.res.east.verizon.net [70.17.123.202]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9OLrij0018767 for ; Sun, 24 Oct 2004 17:53:53 -0400 Message-Id: <200410242153.i9OLrij0018767@host13.websitesource.com> From: "Carl Wallace" To: Subject: -03 reqs draft and agenda requests Date: Sun, 24 Oct 2004 17:53:44 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C4B9F2.6CAF0490" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS6E+7G2iyngfv9TD6UKK2nNZU1wA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C4B9F2.6CAF0490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The -03 version of the archive requirements draft has been submitted. It addresses all of the editorial comments and many of the non-editorial comments. I adopted Larry's suggestion to include bracketed notes in the draft to highlight areas that require further list discussion. Also, if anyone would like a slot on the agenda during the LTANS session at the IETF meeting let me know. We're currently scheduled for a two hour slot starting at 1PM on Nov. 11th. ------=_NextPart_000_0013_01C4B9F2.6CAF0490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -03 reqs draft and agenda requests

The -03 version of the archive = requirements draft has been submitted.  It addresses all of the = editorial comments and many of the non-editorial comments.  I = adopted Larry's suggestion to include bracketed notes in the draft to = highlight areas that require further list discussion.

Also, if anyone would like a slot on = the agenda during the LTANS session at the IETF meeting let me = know.  We're currently scheduled for a two hour slot starting at = 1PM on Nov. 11th. 

------=_NextPart_000_0013_01C4B9F2.6CAF0490-- From owner-ietf-ltans Mon Oct 25 00:37:40 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7bekx038319; Mon, 25 Oct 2004 00:37:40 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P7bepx038318; Mon, 25 Oct 2004 00:37:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7bc2Y038268 for ; Mon, 25 Oct 2004 00:37:39 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA36534; Mon, 25 Oct 2004 09:49:16 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102509372617:2530 ; Mon, 25 Oct 2004 09:37:26 +0200 Message-ID: <417CACBD.9000409@bull.net> Date: Mon, 25 Oct 2004 09:35:25 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Larry Masinter CC: ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I60003T9DQB9T@mailsj-v1.corp.adobe.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 09:37:26, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 09:37:27, Serialize complete at 25/10/2004 09:37:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Larry, > After some discussion with co-editors of the document (and some > subsequent reorganization on my own), I've submitted a new > version of the 'notareq' document. > The title is now 'Requirements for Certification Services'. This new title will add even more confusion with the PKIX working group. Once you proposed: "Data Validation and Certification Protocol Requirements". The word "data" has been dropped in the new proposal. "Requirements for Data Certification Services" could be appropriate, but "Requirements for Certification Services" is not. Denis > Most of the document is significantly rewritten. There is still > need for quite a bit of work. > > If you would like a preview before the internet draft is > available, you may find this at: > > http://larry.masinter.net/ltans-notary-req.txt (plain text, what was > submitted) > http://larry.masinter.net/ltans-notary-req.xml (source xml, should view) > http://larry.masinter.net/ltans-notary-req.html (html transformation) > > Larry > > > > > From owner-ietf-ltans Mon Oct 25 06:20:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDKXTB038033; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDKXdE038032; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDKWFc038024 for ; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (218.sub-166-180-50.myvzw.com [166.180.50.218]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9PDKXHt015653 for ; Mon, 25 Oct 2004 09:20:34 -0400 Message-Id: <200410251320.i9PDKXHt015653@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: -03 reqs draft and agenda requests Date: Mon, 25 Oct 2004 09:20:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C4BA73.E1EA4A90" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200410242153.i9OLrij0018767@host13.websitesource.com> Thread-Index: AcS6E+7G2iyngfv9TD6UKK2nNZU1wAAgN7aQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C4BA73.E1EA4A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI, Peter Sylvester has posted the updated requirements doc at: http://ltans.edelweb.fr/draft-ietf-ltans-reqs-03.html. The IETF publication may not occur for a few days. All of the WG drafts, and various other docs, are available at http://ltans.edelweb.fr. ------=_NextPart_000_0052_01C4BA73.E1EA4A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -03 reqs draft and agenda requests
FYI, Peter Sylvester has posted the updated = requirements=20 doc at: http://ltans.edelweb.fr/draft-ietf-ltans-reqs-03.html= .  The IETF publication may not occur = for a few=20 days.  All of the WG drafts, and various other docs, are = available at=20 http://ltans.edelweb.fr.
------=_NextPart_000_0052_01C4BA73.E1EA4A90-- From owner-ietf-ltans Mon Oct 25 09:29:29 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGTTC6064629; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGTTY7064628; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob5.obsmtp.com [64.18.1.215]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PGTTNC064622 for ; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 25 Oct 2004 09:28:36 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9PGSvph000689; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9PGSvTk014217; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Received: from MasinterT40 ([130.248.176.23]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6500669F48KP@mailsj-v1.corp.adobe.com>; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Date: Mon, 25 Oct 2004 09:28:56 -0700 From: Larry Masinter Subject: RE: Document submitted for draft-ietf-ltans-notareq-01.txt In-reply-to: <417CACBD.9000409@bull.net> To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org Message-id: <0I650066CF48KP@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcS6Z/sTgPshzjbfSjeNxkrNbh8EvgARsr+A Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > This new title will add even more confusion with the PKIX > working group. I'm sorry about the confusion over the title. We had put off working through the document, so there was some rush to get a new version out. I'm a little uneasy about "Data Validation and Certification" because in many of the use cases, the thing being validated or certified isn't so much "data" as it is an "event" -- an oath was administered, an agreement was understood, etc. If we keep these use cases, can you think of other alternatives? Larry From owner-ietf-ltans Mon Oct 25 10:00:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH03hM073457; Mon, 25 Oct 2004 10:00:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PH03aD073456; Mon, 25 Oct 2004 10:00:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGxvNa073415 for ; Mon, 25 Oct 2004 09:59:58 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9PGxPD07686; Mon, 25 Oct 2004 18:59:25 +0200 (MEST) Message-ID: <417D30ED.7090600@edelweb.fr> Date: Mon, 25 Oct 2004 18:59:25 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Larry Masinter CC: "'Denis Pinkas'" , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> In-Reply-To: <0I650066CF48KP@mailsj-v1.corp.adobe.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040707070805090509080202" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms040707070805090509080202 Content-Type: multipart/alternative; boundary="------------050505080105040404080303" This is a multi-part message in MIME format. --------------050505080105040404080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Larry Masinter -- a dit, - le 25/10/2004 18:28: >>This new title will add even more confusion with the PKIX=20 >>working group. >> =20 >> > >I'm sorry about the confusion over the title. We had put off >working through the document, so there was some rush to get >a new version out. > >I'm a little uneasy about "Data Validation and Certification" >because in many of the use cases, the thing being validated >or certified isn't so much "data" as it is an "event" -- an >oath was administered, an agreement was understood, etc. > =20 > On one hand, you are right, in many cases what will be certified will=20 not be an document, but as you say a fact or an event, but on the other=20 hand, we are dealing with information systems and "facts" or "events"=20 will have to be represented and it will be by some "data" (a combination = of what, when, by whom ...) As far as my understanding of the english language is correct, "data",=20 as being the more general word(even vague, here it is a clear advantage=20 over a more "accurate" or "connotated" term) is definitely the more=20 appropriate. We can probably have a shortexplanation in the foreword of the document, = stating that in this document the word "data" has to be understood as=20 the "electronic representation" of a "fact" (or "event") . One specific case of such a "fact" is the submission or validation of a=20 document at a given date and time (optionnaly by a specific user), one=20 specific subcase being the validation of a X.509 certificate. Another case being for example the receipt notification by a Long Term=20 Archive service, or the the "approval" of a document at a given time by at least 67% of=20 the members of a given list of users. Regards, -- PAP >If we keep these use cases, can you think of other alternatives? > >Larry > > > > > =20 > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050505080105040404080303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Larry Masinter --  a dit,  - le 25/10/2004 18:28: 
This new title will add even more confusion with the PKIX 
working group.
    

I'm sorry about the confusion over the title. We had put off
working through the document, so there was some rush to get
a new version out.

I'm a little uneasy about "Data Validation and Certification"
because in many of the use cases, the thing being validated
or certified isn't so much "data" as it is an "event" -- an
oath was administered, an agreement was understood, etc.
On one hand, you are right, in many cases what will be certified will not be an document, but as you say a fact or an event, but on the other hand, we are dealing with information systems and "facts" or "events" will have to be represented and it will be by some "data" (a combination of what, when, by whom ...)

As far as my understanding of the english language is correct, "data", as being the more general word(even vague, here it is a clear advantage over a more "accurate" or "connotated" term) is definitely the more appropriate.

We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event") .
One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate.
Another case being for example the receipt notification by a Long Term Archive service,
or the the "approval" of a document at a given time by at least 67% of the members of a given list of users.

Regards,

-- PAP
If we keep these use cases, can you think of other alternatives?

Larry

--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050505080105040404080303-- --------------ms040707070805090509080202 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI1MTY1OTI1 WjAjBgkqhkiG9w0BCQQxFgQUEJCRv7zchnp0nYT9Z/QJ5DK1+S4wUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BVYWh7hisdlx3MzpDY78oUlcZAIoNctWwQOdf0ix708PasEYBGydx8+MxmFhy4AQAr9hyJgi yP1EX/qfAPw8UMGOFM9hm5ag1gdpHamRPRehiwhq1A+zic1ElvGDisOAOZK/qrvf07Ez/Npy nAd8Dm02AAqiu7zMewjqLSyzyKa3SptVmwfxuo5B4SaA2Jv6AAAAAAAA --------------ms040707070805090509080202-- From owner-ietf-ltans Mon Oct 25 10:01:55 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH1tM0073913; Mon, 25 Oct 2004 10:01:55 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PH1tRp073912; Mon, 25 Oct 2004 10:01:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH1rcf073903 for ; Mon, 25 Oct 2004 10:01:54 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9PH1uD07726; Mon, 25 Oct 2004 19:01:56 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 25 Oct 2004 19:01:56 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9PH1tH22688; Mon, 25 Oct 2004 19:01:55 +0200 (MEST) Date: Mon, 25 Oct 2004 19:01:55 +0200 (MEST) From: Peter Sylvester Message-Id: <200410251701.i9PH1tH22688@chandon.edelweb.fr> To: Denis.Pinkas@bull.net, LMM@acm.org Subject: RE: Document submitted for draft-ietf-ltans-notareq-01.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > If we keep these use cases, can you think of other alternatives? > We can add a text in the requirement saying that we have to find a good name for the protocol and a text: The protocol should be called 'xyz' because of this and that reason. (which can be repeated in the introductions). From owner-ietf-ltans Mon Oct 25 13:03:54 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3sPD017304; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK3sDQ017303; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3svH017297 for ; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29379; Mon, 25 Oct 2004 16:03:55 -0400 (EDT) Message-Id: <200410252003.QAA29379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-notareqs-01.txt Date: Mon, 25 Oct 2004 16:03:55 -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 : Requirements for Certification Services Author(s) : T. Gondrom, et al. Filename : draft-ietf-ltans-notareqs-01.txt Pages : 11 Date : 2004-10-25 This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. It establishes the need for components to be used in addition to long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-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-notareqs-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-notareqs-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: <2004-10-25162134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-notareqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-notareqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162134.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ltans Mon Oct 25 13:03:33 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3Xs2017223; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK3Xhw017220; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3WMc017214 for ; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29302; Mon, 25 Oct 2004 16:03:34 -0400 (EDT) Message-Id: <200410252003.QAA29302@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-03.txt Date: Mon, 25 Oct 2004 16:03:34 -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-03.txt Pages : 21 Date : 2004-10-25 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-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-reqs-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-reqs-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: <2004-10-25162129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162129.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ltans Wed Oct 27 00:51:05 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7p4vf030867; Wed, 27 Oct 2004 00:51:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R7p4Um030866; Wed, 27 Oct 2004 00:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7p2gn030817 for ; Wed, 27 Oct 2004 00:51:03 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA57794; Wed, 27 Oct 2004 10:02:36 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102709504458:342 ; Wed, 27 Oct 2004 09:50:44 +0200 Message-ID: <417F52D7.8070207@bull.net> Date: Wed, 27 Oct 2004 09:48:39 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> <417D30ED.7090600@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:50:44, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:50:47, Serialize complete at 27/10/2004 09:50:47 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9R7p4gn030860 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, You said: "We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event")." This is fully correct and I support this. However thenafter you added: "One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate". I wonder about this. Someone (e.g. a notary) can testify hundreds of facts or events. There are millions of such facts or events. So we should neither focus on "submission or validation of a document at a given date and time" nor on "validation of a X.509 certificate". Denis > -- Larry Masinter -- a dit, - le 25/10/2004 18:28: > >>>This new title will add even more confusion with the PKIX >>>working group. >>> >>> >> >>I'm sorry about the confusion over the title. We had put off >>working through the document, so there was some rush to get >>a new version out. >> >>I'm a little uneasy about "Data Validation and Certification" >>because in many of the use cases, the thing being validated >>or certified isn't so much "data" as it is an "event" -- an >>oath was administered, an agreement was understood, etc. >> >> > On one hand, you are right, in many cases what will be certified will > not be an document, but as you say a fact or an event, but on the other > hand, we are dealing with information systems and "facts" or "events" > will have to be represented and it will be by some "data" (a combination > of what, when, by whom ...) > > As far as my understanding of the english language is correct, "data", > as being the more general word(even vague, here it is a clear advantage > over a more "accurate" or "connotated" term) is definitely the more > appropriate. > > We can probably have a shortexplanation in the foreword of the document, > stating that in this document the word "data" has to be understood as > the "electronic representation" of a "fact" (or "event") . > One specific case of such a "fact" is the submission or validation of a > document at a given date and time (optionnaly by a specific user), one > specific subcase being the validation of a X.509 certificate. > Another case being for example the receipt notification by a Long Term > Archive service, > or the the "approval" of a document at a given time by at least 67% of > the members of a given list of users. > > Regards, > > -- PAP > >>If we keep these use cases, can you think of other alternatives? >> >>Larry >> >> >> >> >> >> > > -- > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de > Dion Bouton - 92816 Puteaux cedex > Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > > From owner-ietf-ltans Wed Oct 27 03:19:34 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RAJYFt001165; Wed, 27 Oct 2004 03:19:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RAJYQd001163; Wed, 27 Oct 2004 03:19:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RAJWjh001136 for ; Wed, 27 Oct 2004 03:19:32 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9RAIrD05575; Wed, 27 Oct 2004 12:18:53 +0200 (MEST) Message-ID: <417F760B.3030303@edelweb.fr> Date: Wed, 27 Oct 2004 12:18:51 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Denis Pinkas CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> <417D30ED.7090600@edelweb.fr> <417F52D7.8070207@bull.net> In-Reply-To: <417F52D7.8070207@bull.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020007040100030806080201" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020007040100030806080201 Content-Type: multipart/alternative; boundary="------------050608050208070705090402" This is a multi-part message in MIME format. --------------050608050208070705090402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Denis Pinkas -- a dit, - le 27/10/2004 09:48: > > Paul-Andr=E9, > > You said: > > "We can probably have a shortexplanation in the foreword of the=20 > document, stating that in this document the word "data" has to be=20 > understood as the "electronic representation" of a "fact" (or "event").= " > > This is fully correct and I support this. perfect > > However thenafter you added: > > "One specific case of such a "fact" is the submission or validation of = > a document at a given date and time (optionnaly by a specific user),=20 > one specific subcase being the validation of a X.509 certificate". > > I wonder about this. > > Someone (e.g. a notary) can testify hundreds of facts or events. There = > are millions of such facts or events. So we should neither focus on=20 > "submission or validation of a document at a given date and time" nor=20 > on "validation of a X.509 certificate". I never said that the groupe "should focus" on "validation of a=20 certificate" and I am sorry if my wording was so obscure that it could=20 be understood as such. Nevertheless, I still pretend that the ability to obtain from a "Data =20 Certification Service" some form of "evidence", by means of a "data=20 cert" (dated and signed by the DCS authority) that one has indeed=20 verified at a given date and time that an X.509 certificate was checked=20 and validated is indeed one example of "user's requirement" from such a=20 service. Don't read that this should be the goal (main goal, unique goal) of =20 LTANS, just that it cann't be excluded and it makes sense in addition to = such services as OCSP. The "data cert" will "prove" for example that the = signature attached to a given document had been verified by a specific=20 user, at a given date (different from the signature date) using a given=20 "validation service". The actual role of the "Data Certification=20 Service" will not be to perform "itself" the validation work but to=20 certify that is has been done in the specific context (that is the=20 "fact" that is certified") Same could be said about "document validation and submission", the role=20 of the DCS must be to deliver such a data cert and need not to include=20 the actual perfomance of the validation itself. Exactly as a "notary"=20 could establish a certificate that one of is customers has deposited=20 some amount of money at a bank for a specific purpose, that the=20 banknotes had been validated -by the bank- and that this bank has=20 delivered a receipt. The "data-cert" certifies a fact and comes in=20 addition to the bank receipt. This being said, for the purpose of sharing the understanding, I agree=20 that that mentionning "X509 certs validation" too early in the document=20 and as a purpose and not as an example might be confusing, and I=20 certainly do no invite the group to mention this use case event if I=20 still claim that it belongs to the myriads of use cases relevant of such = a service. regards, -- PAP > > Denis > > >> -- Larry Masinter -- a dit, - le 25/10/2004 18:28: >> >>>> This new title will add even more confusion with the PKIX working=20 >>>> group. >>>> =20 >>> >>> >>> I'm sorry about the confusion over the title. We had put off >>> working through the document, so there was some rush to get >>> a new version out. >>> >>> I'm a little uneasy about "Data Validation and Certification" >>> because in many of the use cases, the thing being validated >>> or certified isn't so much "data" as it is an "event" -- an >>> oath was administered, an agreement was understood, etc. >>> =20 >>> >> On one hand, you are right, in many cases what will be certified will = >> not be an document, but as you say a fact or an event, but on the=20 >> other hand, we are dealing with information systems and "facts" or=20 >> "events" will have to be represented and it will be by some "data" (a = >> combination of what, when, by whom ...) >> >> As far as my understanding of the english language is correct,=20 >> "data", as being the more general word(even vague, here it is a clear = >> advantage over a more "accurate" or "connotated" term) is definitely=20 >> the more appropriate. >> >> We can probably have a shortexplanation in the foreword of the=20 >> document, stating that in this document the word "data" has to be=20 >> understood as the "electronic representation" of a "fact" (or "event")= . >> One specific case of such a "fact" is the submission or validation of = >> a document at a given date and time (optionnaly by a specific user),=20 >> one specific subcase being the validation of a X.509 certificate. >> Another case being for example the receipt notification by a Long=20 >> Term Archive service, >> or the the "approval" of a document at a given time by at least 67%=20 >> of the members of a given list of users. >> >> Regards, >> >> -- PAP >> >>> If we keep these use cases, can you think of other alternatives? >>> >>> Larry >>> >>> >>> >>> >>> =20 >>> >> >> --=20 >> Edelweb >> Groupe ON-X P=F4le S=E9curit=E9 >> paul-andre.pays@edelweb.fr papays@on-x.com >> http://www.edelweb.fr/ http://www.on-x.com/ >> >> Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai = >> de Dion Bouton - 92816 Puteaux cedex >> Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr= /=20 >> vous permet d'obtenir le certificat de l'autorit=E9 et la LCR. >> >> >> > > > > > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050608050208070705090402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Denis Pinkas --  a dit,  - le 27/10/2004 09:48:

Paul-André,

You said:

"We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event")."

This is fully correct and I support this.
perfect

However thenafter you added:

"One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate".

I wonder about this.

Someone (e.g. a notary) can testify hundreds of facts or events. There are millions of such facts or events. So we should neither focus on "submission or validation of a document at a given date and time" nor on "validation of a X.509 certificate".
I never said that the groupe "should focus" on "validation of a certificate" and I am sorry if my wording was so obscure that it could be understood as such.
Nevertheless, I still pretend that  the ability to obtain from a "Data  Certification Service" some form of "evidence", by means of a "data cert" (dated and signed by the DCS authority) that one has indeed verified at a given date and time that an X.509 certificate was checked and validated is indeed one example of "user's requirement" from such a service.
Don't read that this should be the goal (main goal, unique goal) of  LTANS, just that it cann't be excluded and it makes sense in addition to such services as OCSP. The "data cert" will "prove" for example that the signature attached to a given document had been verified by a specific user, at a given date (different from the signature date) using a given "validation service".  The actual role of the "Data Certification Service" will not be to perform "itself" the validation work but to certify that is has been done in the specific context (that is the "fact" that is certified")

Same could be said about "document validation and submission", the role of the DCS must be to deliver such a data cert and need not to include the actual perfomance of the validation itself. Exactly as a "notary" could establish a certificate that one of is customers has deposited some amount of money at a bank for a specific purpose, that the banknotes had been validated -by the bank- and that this bank has delivered a receipt. The "data-cert" certifies a fact and comes in addition to the bank receipt.

This being said, for the purpose of sharing the understanding, I agree that that mentionning "X509 certs validation" too early in the document and as a purpose and not as an example might be confusing, and I certainly do no invite the group to mention this use case event if I still claim that it belongs to the myriads of use cases relevant of such a service.

regards,

-- PAP

Denis


 -- Larry Masinter --  a dit,  - le 25/10/2004 18:28:

This new title will add even more confusion with the PKIX working group.
  

I'm sorry about the confusion over the title. We had put off
working through the document, so there was some rush to get
a new version out.

I'm a little uneasy about "Data Validation and Certification"
because in many of the use cases, the thing being validated
or certified isn't so much "data" as it is an "event" -- an
oath was administered, an agreement was understood, etc.
 

On one hand, you are right, in many cases what will be certified will not be an document, but as you say a fact or an event, but on the other hand, we are dealing with information systems and "facts" or "events" will have to be represented and it will be by some "data" (a combination of what, when, by whom ...)

As far as my understanding of the english language is correct, "data", as being the more general word(even vague, here it is a clear advantage over a more "accurate" or "connotated" term) is definitely the more appropriate.

We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event") .
One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate.
Another case being for example the receipt notification by a Long Term Archive service,
or the the "approval" of a document at a given time by at least 67% of the members of a given list of users.

Regards,

-- PAP

If we keep these use cases, can you think of other alternatives?

Larry




 


-- 
Edelweb
Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/

Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.









--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050608050208070705090402-- --------------ms020007040100030806080201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTAxODUx WjAjBgkqhkiG9w0BCQQxFgQUxvQLu3rnEWIvt2DES1yDsgJUokkwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ AdNExAnDyIqAFB3bZSLh9s8gG8gul33m7CNLNemWsdLGGo0e5CnsMujwEfMlGfN6ED1BAJZi O33sVE7pXPlCH8q9XWB498Jc2Rc7YKS6UytkqyVH9jgId8DsLqg+4tZjJm9IMBNr2WsNEmtv GL14b1c4GFD9C6ug1PtDemdxWp0Weq0lGDCtfD2/c043H0ZNAAAAAAAA --------------ms020007040100030806080201-- From owner-ietf-ltans Wed Oct 27 09:00:10 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RG09bU095165; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RG090G095164; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RG09H2095135 for ; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Wed, 27 Oct 2004 08:59:30 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i9RFxo85021425 for ; Wed, 27 Oct 2004 08:59:55 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9RFxo0U025183 for ; Wed, 27 Oct 2004 08:59:50 -0700 (PDT) Received: from MasinterT40 ([130.248.178.62]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I69003IU33PK7@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Wed, 27 Oct 2004 08:59:50 -0700 (PDT) Date: Wed, 27 Oct 2004 08:59:49 -0700 From: Larry Masinter Subject: Discussion of notareqs document In-reply-to: <417F760B.3030303@edelweb.fr> To: ietf-ltans@imc.org Message-id: <0I69003IV33PK7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=iso-8859-1 Thread-index: AcS8EQeHzNmztPZBTaOxPCVvEq0kkwAJ9+Xw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RG09H2095159 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Note that my email said 'draft-ietf-ltans-notareq-01' but the actual document name is 'draft-ietf-ltans-notareqs-01' with an s; the internet-drafts editor fixed this). I think there is no problem changing the title again to "Data Validation and Certification Service Requirements". On the technical content of the document, I am hoping we can have a good discussion at the IETF meeting about some of these points: Use cases: The use cases in the document are fairly general. We've had some suggestions for more specific use cases, from Paul-André Pays: - validation of an X.509 certificate - validation of a receipt notification by a Long-Term Archive service - "approval" of a document at a given time by at least 67% of the members of a given list of users and from Peter Sylvester (originally at IETF Vienna): - Certify three events of an SMIME message sent (prepare message, receipt of message, receipt of acknowledgement) If we are to include these, we will need to describe them clearly. Are there any problems with including these? * Are there other use cases? * Should any of the use cases be omitted? * What other elements of these use cases should be elaborated? (I think it would be useful to elaborate the 'long term' elements of the use cases, e.g., "after 10 years, someone needs to prove A having sent the message") Requirements: What are the actual requirements corresponding to these use cases, as far as the network protocol or data structures necessary to communicate with an agent performing these services? I think we want to document requirements in the same way that we've been moving the long-term archive requirements document. Security considerations: I think a "Long-Term" service needs some expansion about the requirements for long-term security. For example, over a 30-year period, what is feasible with a "brute force" attack is different than what might be expected over a 2-year period, because of indetermined increases in computing power available to attackers, and the sheer amount of time available to do brute force. Operational considerations: It seems that there are two main purposes to this section -- to be clear about the scaling and performance requirements, and to lay out the operational security measures necessary. I think this could be clearer in the document. References: I had meant to add references to DVCS and ERS and to reference them in the introduction as some prior work in the area. And the reference to the long-term archive requirements could be to RFC XXXX assuming it will be published first (or at least, simultaneously). Larry -- http://larry.masinter.net From owner-ietf-ltans Wed Oct 27 10:23:06 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHN6Fg013762; Wed, 27 Oct 2004 10:23:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RHN6w3013761; Wed, 27 Oct 2004 10:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHN5LH013754 for ; Wed, 27 Oct 2004 10:23:05 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (172.sub-166-180-42.myvzw.com [166.180.42.172]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9RHN78J021264 for ; Wed, 27 Oct 2004 13:23:07 -0400 Message-Id: <200410271723.i9RHN78J021264@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Discussion of notareqs document Date: Wed, 27 Oct 2004 13:22:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <0I69003IV33PK7@mailsj-v1.corp.adobe.com> Thread-index: AcS8EQeHzNmztPZBTaOxPCVvEq0kkwAJ9+XwAAPQiyA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > * Should any of the use cases be omitted? I don't think we should include a use case that simply consists of reporting the validation status of an X.509 certificate. SCVP is well underway and serves that purpose. That cert validity is reported as part of a data certification operation seems OK but establishing an alternative to SCVP is not in our scope. From owner-ietf-ltans Wed Oct 27 10:55:39 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHtd4b022163; Wed, 27 Oct 2004 10:55:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RHtdTu022162; Wed, 27 Oct 2004 10:55:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHtbLV022154 for ; Wed, 27 Oct 2004 10:55:38 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9RHtcD11937; Wed, 27 Oct 2004 19:55:38 +0200 (MEST) Message-ID: <417FE118.2080409@edelweb.fr> Date: Wed, 27 Oct 2004 19:55:36 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Carl Wallace CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> In-Reply-To: <200410271723.i9RHN78J021264@host13.websitesource.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030807030001030000060000" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030807030001030000060000 Content-Type: multipart/alternative; boundary="------------050700000607020902090004" This is a multi-part message in MIME format. --------------050700000607020902090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Carl Wallace -- a dit, - le 27/10/2004 19:22: > > =20 > >>* Should any of the use cases be omitted? >> =20 >> > >I don't think we should include a use case that simply consists of repor= ting >the validation status of an X.509 certificate. SCVP is well underway an= d >serves that purpose. That cert validity is reported as part of a data >certification operation seems OK but establishing an alternative to SCVP= is >not in our scope. > =20 > I fully agree, but the use case I presented and proposed -in my last mail= - : * is not "/simply of reporting the validation status of an X.509 certificate/" * is not "Yet Another SCVP" * but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be assured that the "DVC service" (or ntotary) will keep a detailed and certified -and securely archived- log entry of this request.=20 * By the way, (and not limited to the above use case) this is one element=20 of solution against the threat for the long term that the original=20 certifying keys could be broken some day (before the end of this long ter= m!) * a SCVP report could be forged 20 years after the effective date * BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries". This is another proof of the sound approach of LTANS which links "data=20 certs" and "secure archived". Any "data cert" must not only be signed,=20 but a detailed log entry must be archived in a secure way (non=20 rewritable medium, hash linking). This mandatory combination was a major = rationale of the openevidence project (/the technical solution by then=20 was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking/) > > > > =20 > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050700000607020902090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Carl Wallace --  a dit,  - le 27/10/2004 19:22: 
 <snip>
  
* Should any of the use cases be omitted?
    

I don't think we should include a use case that simply consists of reporting
the validation status of an X.509 certificate.  SCVP is well underway and
serves that purpose.  That cert validity is reported as part of a data
certification operation seems OK but establishing an alternative to SCVP is
not in our scope.
I fully agree, but the use case I presented and proposed -in my last mail- :
  • is not "simply of reporting the validation status of an X.509 certificate"
  • is not "Yet Another SCVP"
  • but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be assured that the "DVC service" (or ntotary) will keep a detailed and certified -and securely archived- log entry of this request. 

By the way, (and not limited to the above use case) this is one element of solution against the threat for the long term that the original certifying keys could be broken some day (before the end of this long term!)
  • a SCVP report could be forged 20 years after the effective date
  • BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries".
This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, but a detailed log entry must be archived in a secure way (non rewritable medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)

--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050700000607020902090004-- --------------ms030807030001030000060000 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTc1NTM2 WjAjBgkqhkiG9w0BCQQxFgQUxGD/bOrL3frIZ6gQj0UiIMuVMAgwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BHiKPy4lhkdIGkScQXJp9xcSW9tx5UQGqNWIHLXFQF/bnEwn3Z71faKzYT20uy0SDtfDODfw 8DE4YSO4ID2LkpIVCF+vr3FoiCMLwWJ0W7zbK6TR0m2L8fNKqUL2SC1pMoWLubvvYA3nL5AD YyLEe0oXo55QbZMXYWCFDtbDkxopnhcMvIqRzrFqhmIRJNSaAAAAAAAA --------------ms030807030001030000060000-- From owner-ietf-ltans Wed Oct 27 12:07:38 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJ7cT5037312; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJ7cNZ037311; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJ7b4N037305 for ; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (143.sub-70-212-165.myvzw.com [70.212.165.143]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9RJ7X8J006911; Wed, 27 Oct 2004 15:07:36 -0400 Message-Id: <200410271907.i9RJ7X8J006911@host13.websitesource.com> From: "Carl Wallace" To: "=?iso-8859-1?Q?'Paul-Andr=E9_PAYS'?=" Cc: Subject: RE: Discussion of notareqs document Date: Wed, 27 Oct 2004 15:07:24 -0400 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0030_01C4BC33.8EB38460" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS8UAMubVRbfM51RBK5QaTwosr5xwABMnNw In-Reply-To: <417FE118.2080409@edelweb.fr> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C4BC33.8EB38460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0031_01C4BC33.8EB38460" ------=_NextPart_001_0031_01C4BC33.8EB38460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think we are in disagreement. I was not responding to your last email but to Larry's question regarding whether any of the listed use = cases should be omitted. You seem to agree that a use case targeting = validation of an X.509 certificate is beyond our scope. I agree what you describe below is within our scope. _____ =20 From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-Andr=E9 PAYS Sent: Wednesday, October 27, 2004 1:56 PM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document -- Carl Wallace -- a dit, - le 27/10/2004 19:22:=20 =20 * Should any of the use cases be omitted? =20 I don't think we should include a use case that simply consists of = reporting the validation status of an X.509 certificate. SCVP is well underway = and serves that purpose. That cert validity is reported as part of a data certification operation seems OK but establishing an alternative to SCVP = is not in our scope. =20 I fully agree, but the use case I presented and proposed -in my last = mail- : * is not "simply of reporting the validation status of an X.509 certificate"=20 * is not "Yet Another SCVP"=20 * but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be = assured that the "DVC service" (or ntotary) will keep a detailed and certified = -and securely archived- log entry of this request. =20 *=09 By the way, (and not limited to the above use case) this is one element = of solution against the threat for the long term that the original = certifying keys could be broken some day (before the end of this long term!) * a SCVP report could be forged 20 years after the effective date=20 * BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries". = This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, = but a detailed log entry must be archived in a secure way (non rewritable = medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination = of TSP RFC3061, DVCS RFC3029 and hash-linking) =20 --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9=09 paul-andre.pays@edelweb.fr papays@on-x.com=09 http://www.edelweb.fr/ http://www.on-x.com/=09 Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorit=E9 et la LCR.=20 ------=_NextPart_001_0031_01C4BC33.8EB38460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PAP Sig
I don't think we are in disagreement.  I = was not=20 responding to your last email but to Larry's question regarding whether = any of=20 the listed use cases should be omitted.  You seem to agree that a = use case=20 targeting validation of an X.509 certificate is beyond = our=20 scope.  I agree what you describe below is within our=20 scope.

From: = owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of = Paul-Andr=E9=20 PAYS
Sent: Wednesday, October 27, 2004 1:56 PM
To: = Carl=20 Wallace
Cc: ietf-ltans@imc.org
Subject: Re: = Discussion of=20 notareqs document



 -- Carl Wallace --  a dit,  - le = 27/10/2004=20 19:22:=20 
 <snip>
  
* Should any of the use =
cases be omitted?
    

I don't think we should include a use case that simply consists of =
reporting
the validation status of an X.509 certificate.  SCVP is well underway =
and
serves that purpose.  That cert validity is reported as part of a data
certification operation seems OK but establishing an alternative to SCVP =
is
not in our scope.
I fully agree, but the use case I presented and = proposed=20 -in my last mail- :
  • is not "simply of reporting the validation status of an X.509 = certificate"=20
  • is not "Yet Another SCVP"=20
  • but extend (and possibly encompass) the service rendered by SCVP = or any=20 other, in order to meet the end user's requirement : obtaining a=20 certification (some form of "proof" valid for long term use) by some = external "authority" (not to say notary or e-notary) (of the "fact" = that=20 s/he has actually used a validation service (such as SCVP) and be = assured=20 that the "DVC service" (or ntotary) will keep a detailed and = certified -and=20 securely archived- log entry of this request. 

By the way, (and not limited to the above use = case) this is=20 one element of solution against the threat for the long term that the = original=20 certifying keys could be broken some day (before the end of this long=20 term!)
  • a SCVP report could be forged 20 years after the effective date=20
  • BUT, it will be much more difficult to forge -and in a = consistent way-=20 also the "DVC data cert" and the "secure and archived log entries".=20
This is another proof of the sound approach of LTANS which = links=20 "data certs" and "secure archived". Any "data cert" must not only be = signed,=20 but a detailed log entry must be archived in a secure way (non = rewritable=20 medium, hash linking). This mandatory combination was a major = rationale of the=20 openevidence project (the technical solution by then was a a = combination of=20 TSP RFC3061, DVCS RFC3029 and hash-linking)

--
Edelweb
 Groupe=20 ON-X P=F4le = S=E9curit=E9paul-andre.pays@edelweb.fr= papays@on-x.com<= /TR> http://www.edelweb.fr/ http://www.on-x.com/
Tel.=20 + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 --=20 Adresse : = 15, quai=20 de Dion Bouton  -  92816 Puteaux cedex
Pour = v=E9rifier la=20 signature =E9lectronique, http://edelpki.edelweb.fr/ = vous permet d'obtenir le = certificat de=20 l'autorit=E9 et la LCR.=20 =

= ------=_NextPart_001_0031_01C4BC33.8EB38460-- ------=_NextPart_000_0030_01C4BC33.8EB38460 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMDCCBEAw ggMooAMCAQICBEClE7wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE0MzA1NVoXDTA3MDUxNzE1MDA1NVowWzELMAkGA1UE BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95 ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALLi +sA/Id5PcQ8uPHjuKlWcxrb8kQkBkJrn4Vv/KNrpZZcIO0mTxp28yVqg3fJRWszamV3cbE77oXV/ 0AFxrRhf89avN0lrUmqSBsf7ph8Zfz8HMbNODQvGOsKCGa4HA1jujeTnIqgrlCyyUORELVu4i2a7 uErbLjIX7SHNxGtlAgMBAAGjggGHMIIBgzALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVY3dhbGxh Y2VAb3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8G A1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cu b3Jpb25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxn ZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY 0jAdBgNVHQ4EFgQUB0yg8DWubbASzzui5JhAF3+oIRYwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAE DDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAYh0dywIAWMho3sca3AwuMZiepipLDF/+ +vrm9Md+P9AfS6pjwRbsBNcS9425jr56ANJXALioZoxDMKlRKXy+Hmj8wXq8nMgPkmfLYhvP+PVn KgOkoQtT3ym7FSCwrDJEvO0azG6uRxhuIevShRsBaxsCCjdnf6xG6OGV0KrniweAsnNoZPdq6bHI 2ZAk8hZNWHWwGmYo1lP9MeZ+5aYvG1T3OoKI7Kyg4SM/OjjqxwuGC1Zoh1nAJHrBuvRxvhrzvf9t 5ff5r7/YEguVTRfnviUhAyB56auTb1+lY+sz+NQB0kBkSXwvq1+R6pJ3eBWH7o9h5QI87j0IbrL/ ZXhj0zCCBG0wggNVoAMCAQICBEClE74wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBB dXRob3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE4MDExNFoXDTA3MDUxNzE4MzExNFow WzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UE CxMJRW1wbG95ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAK+KL0avuOpT0cjCIpk1FxSdLKeXJvS9YoiWX51DoSimpkLJrVj3dxVZW+ixPGTKpnGB RlGMLOnaqhtIgJ7rSw7/c2Ahc52t8QRdb5HFG96/b4FQabd9zgjiKs82ijzsWvwP1wcDm5YwrTcc 5ZXh4BgelpXgUn5I1kOjTvyC4UuTAgMBAAGjggG0MIIBsDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQw IoAPMjAwNDA1MTcxODAxMTRagQ8yMDA2MDYyMzA2MzExNFowIAYDVR0RBBkwF4EVY3dhbGxhY2VA b3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8GA1UE ChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhv cml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cub3Jp b25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVz ZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAd BgNVHQ4EFgQUBoyaS8dak6pJpXXiEkLdnVnyngAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAK GwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAa69I2Ckr0OjSaxgqdueqQczXR74p1qAS9eRC vZjLW23840mKXk/UtiKvF0E9JgZ11/Fqyk/IHHbSnX7r9Z6oLVKvs0Pkk+HlB9X5XGiVm6RXpAzL jHwsKefQsQ9Lsrk8bouPneRqMzoYQ/ea3Azeit1UWMiZYA+Oebv9Lu6oIFVq/ONucRyxTAMN5i91 IZ5bAp3Jb3cUfd3FqmVBctfVemWIOOcgOoRCf7gJKpPqI0CWkR/LIA67F3lD+goNYb07ISIFqVgk VcGhsMJx19lwFl9kXqgHLDhxfTbV6PDb1LkBoIE8O+dhZkYQ2DmH6dHo88+bfOJJ3z6HtA8GpFpb LzCCBXcwggRfoAMCAQICBEClE1EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNV BAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNDE5MDMxMloXDTI0MDUxNDE5MzMxMlowYjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZ Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoJjL4nDMben23Cn1KTo4DfHDtfNZGOWwBW2XI9djn/VuXXO2hj6nX4r4 G1lNwtCpDYn7Lp80dHRFdpn7GnqrfNMHIsKDaRYxpJ0fgi4gE9LdMwnmsEE8WONj7yPVRuI6Xq43 nfO8LTZehHaN+NwUdgh/rXDQLru1AaxYbaJftkpGGwyMDmPwtfgV3TvNf8g50mCTcAripDVm2tzC 4vIOdNCYQJfsRoQggtLwby9nNyxwHKHHh7OlEZPqVJPGn1S1qzFxKjRcLHwzP4vKD6H8nY5ndVk3 4CLZ5jq59kcpoVTDMLySl5PTg6zBuS+1S0nngBAW9FOqUOTBRMyxqHkmgwIDAQABo4ICMzCCAi8w ggGEBgNVHR8EggF7MIIBdzB5oHegdaRzMHExCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBT ZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAK BgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDovL3d3dy5vcmlvbnNlYy5jb20v Q1JML2NhMV9jcmxmaWxlNC5jcmwwgZSggZGggY6GgYtsZGFwOi8vU0JFVEVMR0VVU0UvY249V2lu Q29tYmluZWQ0LG91PUNBMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1PcmlvbiUy MFNlY3VyaXR5JTIwU29sdXRpb25zLGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9CYXNl MC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDArBgNVHRAE JDAigA8yMDA0MDUxNDE5MDMxMlqBDzIwMjQwNTE0MTkzMzEyWjALBgNVHQ8EBAMCAQYwHwYDVR0j BBgwFoAUyLI83rqa64kJoNY0MpsZQobMmNIwHQYDVR0OBBYEFMiyPN66muuJCaDWNDKbGUKGzJjS MAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMDo0LjADAgSQMA0GCSqGSIb3DQEB BQUAA4IBAQA9LSuraaiw3bO+TdsvCuppT4dbud3+lw6LekUzC9uVFzKbVpVUohUezNJ4zz7FbTV3 0zFNBUrjM8twoSJQ+pbAdJRhrva9zztJp+zR1hDiF4xUfQ/VhcW5HQ8AuduMAdDOyDbc2qQFeUwR YfonnJpWZINiCyUavFXKoTKoG6KkaDfrBiKLtOXy6m09Qr1dQ7wGnL8i+iEDGVFiCjlJ1JeP0vDP g+oOwWYTraW69me5EfXXhhvghAbYtkwoEfxS8hAxRfFqh+8LTIf9nL8ug9ImcfQqVZhRBsC8W2+Y TzLrexngHUpedXJuas/XVSW1+COqOt/gU9lWPD+GD+59FYJIMYIC0jCCAs4CAQEwajBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE74wCQYFKw4DAhoFAKCCAb4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTg0NTA5WjAj BgkqhkiG9w0BCQQxFgQUhEuVhW7Vc96gYnX7cKLHS9mltTIwZwYJKoZIhvcNAQkPMVowWDAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUweQYJKwYBBAGCNxAEMWwwajBiMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE7wwewYLKoZIhvcNAQkQAgsxbKBqMGIx CzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUTvDANBgkqhkiG9w0B AQEFAASBgH5xJu2sFkzn6hxv0AZ2em1AmJdUKudrUd5SLiyaHc4JnRPwoLEIvSj4wl+vR5s52EFO zcpcOv1PC6kL58ZScUFVNU8aFl4FNdLXwDePwXu7XKlmGWu8TAAsiCCQH8sYWzD6kSoMs7Vh6/tO HlTRDEGH5aDO1Vu3ujjtVzc2IT6lAAAAAAAA ------=_NextPart_000_0030_01C4BC33.8EB38460-- From owner-ietf-ltans Thu Oct 28 06:41:17 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SDfGs9055927; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SDfG9g055926; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SDfFNZ055863 for ; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16470; Thu, 28 Oct 2004 15:53:03 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102815411171:826 ; Thu, 28 Oct 2004 15:41:11 +0200 Message-ID: <4180F677.3090703@bull.net> Date: Thu, 28 Oct 2004 15:39:03 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 15:41:11, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 15:41:12, Serialize complete at 28/10/2004 15:41:12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SDfGNZ055921 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, (text deleted) > This is another proof of the sound approach of LTANS which links "data > certs" and "secure archived". Any "data cert" must not only be signed, > but a detailed log entry must be archived in a secure way (non > rewritable medium, hash linking). This mandatory combination was a major > rationale of the openevidence project (the technical solution by then > was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) There is no such mandatory comnbination for LTANS: data needs to be signed (and time-stamped) by the archive service, but the log is not intended to be used as an evidence. Denis From owner-ietf-ltans Thu Oct 28 08:17:47 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFHlOV064374; Thu, 28 Oct 2004 08:17:47 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFHl5P064373; Thu, 28 Oct 2004 08:17:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFHjQu064278 for ; Thu, 28 Oct 2004 08:17:46 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9SFHgD28542 for ; Thu, 28 Oct 2004 17:17:42 +0200 (MEST) Message-ID: <41810D94.60202@edelweb.fr> Date: Thu, 28 Oct 2004 17:17:40 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> <4180F677.3090703@bull.net> In-Reply-To: <4180F677.3090703@bull.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803060002070500080504" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020803060002070500080504 Content-Type: multipart/alternative; boundary="------------050007080209070609060409" This is a multi-part message in MIME format. --------------050007080209070609060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > Paul-Andr=E9, > > (text deleted) > >> This is another proof of the sound approach of LTANS which links=20 >> "data certs" and "secure archived". Any "data cert" must not only be=20 >> signed, but a detailed log entry must be archived in a secure way=20 >> (non rewritable medium, hash linking). This mandatory combination was = >> a major rationale of the openevidence project (the technical solution = >> by then was a a combination of TSP RFC3061, DVCS RFC3029 and=20 >> hash-linking) > > > There is no such mandatory comnbination for LTANS: data needs to be=20 > signed (and time-stamped) by the archive service, but the log is not=20 > intended to be used as an evidence. I am exactly suggesting that it be. We are preparing a *requirements document* and not some "a posteriori"=20 rationale for a given protocol or service. My strong suggestion, based=20 on several years activities for several customers, is indeed that the=20 "certified archival" of "detailed and signed" log is a "must" for a=20 large majority of actual applications and uses cases. What the most "educated" or aware customers do require is a complete set = of "evidence management" services. (/What they call in France "Gestion=20 de la Preuve" or "Administration de la Preuve"; what they will be able=20 to exhibit in order to dissuade "others" to initiate a litigation, or=20 whenever unsuccessfull, what they will be able to exhibit as evidence=20 elements in a court/). My personal view of the whole justification of LTANS context is, as I=20 am convinced that this type of requirements will be generalized, that=20 the IETF succeeds in proposing and establishing standards that wil enable= : 1. technical interop between business partners 2. technical interop between solution providers 3. the judges and their expert to master the e-material (because it conforms to standard and because there exist tools enbling to manipulate them) 4. the possibility of mutual recognition within a business community And I have no longer any doubt that "certified archived logs" (more or=20 less equivalent of the certified archival of requests and receipts) will = be one of, if not, the most usefull component. > > Denis > > > > > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050007080209070609060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Denis Pinkas --  a dit,  - le 28/10/2004 15:39:

Paul-André,

(text deleted)

This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, but a detailed log entry must be archived in a secure way (non rewritable medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)

There is no such mandatory comnbination for LTANS: data needs to be signed (and time-stamped) by the archive service, but the log is not intended to be used as an evidence.
I am exactly suggesting that it be.

We are preparing a requirements document and not some "a posteriori" rationale for a given protocol or service.  My strong suggestion, based on several years activities for several customers, is indeed that the "certified archival" of "detailed and signed" log is a "must" for a large majority of actual applications and uses cases.

What the most "educated" or aware customers do require is a complete set of "evidence management" services. (What they call in France "Gestion de la Preuve" or "Administration de la Preuve"; what they will be able to exhibit in order to dissuade "others" to initiate a litigation, or whenever unsuccessfull, what they will be able to exhibit as evidence elements in a court).

My personal view of the whole justification of LTANS  context is, as I am convinced that this type of requirements will be generalized, that the IETF succeeds in proposing and establishing standards that wil enable :
  1. technical interop between business partners
  2. technical interop between solution providers
  3. the judges and their expert to master the e-material (because it conforms to standard and because there exist tools enbling to manipulate them)
  4. the possibility of mutual recognition within a business community
And I have no longer any doubt that  "certified archived logs" (more or less equivalent of the certified archival of requests and receipts) will be one of, if not, the most usefull component.


Denis






--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050007080209070609060409-- --------------ms020803060002070500080504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI4MTUxNzQw WjAjBgkqhkiG9w0BCQQxFgQUwWAO2pvfb6cUR6KOktq4jWaTQaUwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BbSGkJqsioCRW6gubrvrouqaAnSCvhOzWTtUqJWBhWdanCuYPh4c5x93sZ3unrqORhrfeRS2 HKRdUH16xt+aSB528+PnfFrd7kOWtp3KlfRmfGto2WpAumcByaT6O9fgTJV1fuIk01MkXNVb B4wfdPU/7x4zNlywEHPtoF6j0pwVdTAACWPQsrY+RCZvxN6nAAAAAAAA --------------ms020803060002070500080504-- From owner-ietf-ltans Thu Oct 28 08:31:53 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFVrOK066215; Thu, 28 Oct 2004 08:31:53 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFVrnn066214; Thu, 28 Oct 2004 08:31:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFVp5E066198 for ; Thu, 28 Oct 2004 08:31:52 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA47472; Thu, 28 Oct 2004 17:43:47 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102817315452:965 ; Thu, 28 Oct 2004 17:31:54 +0200 Message-ID: <41811069.3040202@bull.net> Date: Thu, 28 Oct 2004 17:29:45 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> <4180F677.3090703@bull.net> <41810D94.60202@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 17:31:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 17:31:56, Serialize complete at 28/10/2004 17:31:56 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SFVq5E066209 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, Unfortunately, we have quite opposite personal views. Denis > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > >> >> Paul-André, >> >> (text deleted) >> >>> This is another proof of the sound approach of LTANS which links >>> "data certs" and "secure archived". Any "data cert" must not only be >>> signed, but a detailed log entry must be archived in a secure way >>> (non rewritable medium, hash linking). This mandatory combination was >>> a major rationale of the openevidence project (the technical solution >>> by then was a a combination of TSP RFC3061, DVCS RFC3029 and >>> hash-linking) >> >> >> There is no such mandatory comnbination for LTANS: data needs to be >> signed (and time-stamped) by the archive service, but the log is not >> intended to be used as an evidence. > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a posteriori" > rationale for a given protocol or service. My strong suggestion, based > on several years activities for several customers, is indeed that the > "certified archival" of "detailed and signed" log is a "must" for a > large majority of actual applications and uses cases. > > What the most "educated" or aware customers do require is a complete set > of "evidence management" services. (What they call in France "Gestion de > la Preuve" or "Administration de la Preuve"; what they will be able to > exhibit in order to dissuade "others" to initiate a litigation, or > whenever unsuccessfull, what they will be able to exhibit as evidence > elements in a court). > > My personal view of the whole justification of LTANS context is, as I > am convinced that this type of requirements will be generalized, that > the IETF succeeds in proposing and establishing standards that wil enable : > > 1. technical interop between business partners > 2. technical interop between solution providers > 3. the judges and their expert to master the e-material (because it > conforms to standard and because there exist tools enbling to > manipulate them) > 4. the possibility of mutual recognition within a business community > > And I have no longer any doubt that "certified archived logs" (more or > less equivalent of the certified archival of requests and receipts) will > be one of, if not, the most usefull component. > >> >> Denis From owner-ietf-ltans Thu Oct 28 11:57:25 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SIvPnr011300; Thu, 28 Oct 2004 11:57:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SIvPRX011294; Thu, 28 Oct 2004 11:57:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SIvOW3011287 for ; Thu, 28 Oct 2004 11:57:24 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (118.sub-70-212-144.myvzw.com [70.212.144.118]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9SIvWHK030268 for ; Thu, 28 Oct 2004 14:57:32 -0400 Message-Id: <200410281857.i9SIvWHK030268@host13.websitesource.com> From: "Carl Wallace" To: Subject: IETF session Date: Thu, 28 Oct 2004 14:57:25 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C4BCFE.748DC660" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS9H/ZhtRA2qR1UQTqH9Ba4VyhJjQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C4BCFE.748DC660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI, on the newest *draft* agenda, the LTANS session has been shifted from Thursday at 1PM to Tuesday at 9AM. ------=_NextPart_000_0006_01C4BCFE.748DC660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF session

FYI, on the newest *draft* agenda, the = LTANS session has been shifted from Thursday at 1PM to Tuesday at = 9AM.

------=_NextPart_000_0006_01C4BCFE.748DC660-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SIvPnr011300; Thu, 28 Oct 2004 11:57:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SIvPRX011294; Thu, 28 Oct 2004 11:57:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SIvOW3011287 for ; Thu, 28 Oct 2004 11:57:24 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (118.sub-70-212-144.myvzw.com [70.212.144.118]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9SIvWHK030268 for ; Thu, 28 Oct 2004 14:57:32 -0400 Message-Id: <200410281857.i9SIvWHK030268@host13.websitesource.com> From: "Carl Wallace" To: Subject: IETF session Date: Thu, 28 Oct 2004 14:57:25 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C4BCFE.748DC660" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS9H/ZhtRA2qR1UQTqH9Ba4VyhJjQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C4BCFE.748DC660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI, on the newest *draft* agenda, the LTANS session has been shifted from Thursday at 1PM to Tuesday at 9AM. ------=_NextPart_000_0006_01C4BCFE.748DC660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF session

FYI, on the newest *draft* agenda, the = LTANS session has been shifted from Thursday at 1PM to Tuesday at = 9AM.

------=_NextPart_000_0006_01C4BCFE.748DC660-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFVrOK066215; Thu, 28 Oct 2004 08:31:53 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFVrnn066214; Thu, 28 Oct 2004 08:31:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFVp5E066198 for ; Thu, 28 Oct 2004 08:31:52 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA47472; Thu, 28 Oct 2004 17:43:47 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102817315452:965 ; Thu, 28 Oct 2004 17:31:54 +0200 Message-ID: <41811069.3040202@bull.net> Date: Thu, 28 Oct 2004 17:29:45 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> <4180F677.3090703@bull.net> <41810D94.60202@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 17:31:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 17:31:56, Serialize complete at 28/10/2004 17:31:56 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SFVq5E066209 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, Unfortunately, we have quite opposite personal views. Denis > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > >> >> Paul-André, >> >> (text deleted) >> >>> This is another proof of the sound approach of LTANS which links >>> "data certs" and "secure archived". Any "data cert" must not only be >>> signed, but a detailed log entry must be archived in a secure way >>> (non rewritable medium, hash linking). This mandatory combination was >>> a major rationale of the openevidence project (the technical solution >>> by then was a a combination of TSP RFC3061, DVCS RFC3029 and >>> hash-linking) >> >> >> There is no such mandatory comnbination for LTANS: data needs to be >> signed (and time-stamped) by the archive service, but the log is not >> intended to be used as an evidence. > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a posteriori" > rationale for a given protocol or service. My strong suggestion, based > on several years activities for several customers, is indeed that the > "certified archival" of "detailed and signed" log is a "must" for a > large majority of actual applications and uses cases. > > What the most "educated" or aware customers do require is a complete set > of "evidence management" services. (What they call in France "Gestion de > la Preuve" or "Administration de la Preuve"; what they will be able to > exhibit in order to dissuade "others" to initiate a litigation, or > whenever unsuccessfull, what they will be able to exhibit as evidence > elements in a court). > > My personal view of the whole justification of LTANS context is, as I > am convinced that this type of requirements will be generalized, that > the IETF succeeds in proposing and establishing standards that wil enable : > > 1. technical interop between business partners > 2. technical interop between solution providers > 3. the judges and their expert to master the e-material (because it > conforms to standard and because there exist tools enbling to > manipulate them) > 4. the possibility of mutual recognition within a business community > > And I have no longer any doubt that "certified archived logs" (more or > less equivalent of the certified archival of requests and receipts) will > be one of, if not, the most usefull component. > >> >> Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFHlOV064374; Thu, 28 Oct 2004 08:17:47 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SFHl5P064373; Thu, 28 Oct 2004 08:17:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SFHjQu064278 for ; Thu, 28 Oct 2004 08:17:46 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9SFHgD28542 for ; Thu, 28 Oct 2004 17:17:42 +0200 (MEST) Message-ID: <41810D94.60202@edelweb.fr> Date: Thu, 28 Oct 2004 17:17:40 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> <4180F677.3090703@bull.net> In-Reply-To: <4180F677.3090703@bull.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020803060002070500080504" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020803060002070500080504 Content-Type: multipart/alternative; boundary="------------050007080209070609060409" This is a multi-part message in MIME format. --------------050007080209070609060409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > Paul-Andr=E9, > > (text deleted) > >> This is another proof of the sound approach of LTANS which links=20 >> "data certs" and "secure archived". Any "data cert" must not only be=20 >> signed, but a detailed log entry must be archived in a secure way=20 >> (non rewritable medium, hash linking). This mandatory combination was = >> a major rationale of the openevidence project (the technical solution = >> by then was a a combination of TSP RFC3061, DVCS RFC3029 and=20 >> hash-linking) > > > There is no such mandatory comnbination for LTANS: data needs to be=20 > signed (and time-stamped) by the archive service, but the log is not=20 > intended to be used as an evidence. I am exactly suggesting that it be. We are preparing a *requirements document* and not some "a posteriori"=20 rationale for a given protocol or service. My strong suggestion, based=20 on several years activities for several customers, is indeed that the=20 "certified archival" of "detailed and signed" log is a "must" for a=20 large majority of actual applications and uses cases. What the most "educated" or aware customers do require is a complete set = of "evidence management" services. (/What they call in France "Gestion=20 de la Preuve" or "Administration de la Preuve"; what they will be able=20 to exhibit in order to dissuade "others" to initiate a litigation, or=20 whenever unsuccessfull, what they will be able to exhibit as evidence=20 elements in a court/). My personal view of the whole justification of LTANS context is, as I=20 am convinced that this type of requirements will be generalized, that=20 the IETF succeeds in proposing and establishing standards that wil enable= : 1. technical interop between business partners 2. technical interop between solution providers 3. the judges and their expert to master the e-material (because it conforms to standard and because there exist tools enbling to manipulate them) 4. the possibility of mutual recognition within a business community And I have no longer any doubt that "certified archived logs" (more or=20 less equivalent of the certified archival of requests and receipts) will = be one of, if not, the most usefull component. > > Denis > > > > > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050007080209070609060409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Denis Pinkas --  a dit,  - le 28/10/2004 15:39:

Paul-André,

(text deleted)

This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, but a detailed log entry must be archived in a secure way (non rewritable medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)

There is no such mandatory comnbination for LTANS: data needs to be signed (and time-stamped) by the archive service, but the log is not intended to be used as an evidence.
I am exactly suggesting that it be.

We are preparing a requirements document and not some "a posteriori" rationale for a given protocol or service.  My strong suggestion, based on several years activities for several customers, is indeed that the "certified archival" of "detailed and signed" log is a "must" for a large majority of actual applications and uses cases.

What the most "educated" or aware customers do require is a complete set of "evidence management" services. (What they call in France "Gestion de la Preuve" or "Administration de la Preuve"; what they will be able to exhibit in order to dissuade "others" to initiate a litigation, or whenever unsuccessfull, what they will be able to exhibit as evidence elements in a court).

My personal view of the whole justification of LTANS  context is, as I am convinced that this type of requirements will be generalized, that the IETF succeeds in proposing and establishing standards that wil enable :
  1. technical interop between business partners
  2. technical interop between solution providers
  3. the judges and their expert to master the e-material (because it conforms to standard and because there exist tools enbling to manipulate them)
  4. the possibility of mutual recognition within a business community
And I have no longer any doubt that  "certified archived logs" (more or less equivalent of the certified archival of requests and receipts) will be one of, if not, the most usefull component.


Denis






--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050007080209070609060409-- --------------ms020803060002070500080504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI4MTUxNzQw WjAjBgkqhkiG9w0BCQQxFgQUwWAO2pvfb6cUR6KOktq4jWaTQaUwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BbSGkJqsioCRW6gubrvrouqaAnSCvhOzWTtUqJWBhWdanCuYPh4c5x93sZ3unrqORhrfeRS2 HKRdUH16xt+aSB528+PnfFrd7kOWtp3KlfRmfGto2WpAumcByaT6O9fgTJV1fuIk01MkXNVb B4wfdPU/7x4zNlywEHPtoF6j0pwVdTAACWPQsrY+RCZvxN6nAAAAAAAA --------------ms020803060002070500080504-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SDfGs9055927; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9SDfG9g055926; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9SDfFNZ055863 for ; Thu, 28 Oct 2004 06:41:16 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16470; Thu, 28 Oct 2004 15:53:03 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102815411171:826 ; Thu, 28 Oct 2004 15:41:11 +0200 Message-ID: <4180F677.3090703@bull.net> Date: Thu, 28 Oct 2004 15:39:03 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> <417FE118.2080409@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 15:41:11, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/10/2004 15:41:12, Serialize complete at 28/10/2004 15:41:12 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9SDfGNZ055921 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, (text deleted) > This is another proof of the sound approach of LTANS which links "data > certs" and "secure archived". Any "data cert" must not only be signed, > but a detailed log entry must be archived in a secure way (non > rewritable medium, hash linking). This mandatory combination was a major > rationale of the openevidence project (the technical solution by then > was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) There is no such mandatory comnbination for LTANS: data needs to be signed (and time-stamped) by the archive service, but the log is not intended to be used as an evidence. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJ7cT5037312; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RJ7cNZ037311; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RJ7b4N037305 for ; Wed, 27 Oct 2004 12:07:38 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (143.sub-70-212-165.myvzw.com [70.212.165.143]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9RJ7X8J006911; Wed, 27 Oct 2004 15:07:36 -0400 Message-Id: <200410271907.i9RJ7X8J006911@host13.websitesource.com> From: "Carl Wallace" To: "=?iso-8859-1?Q?'Paul-Andr=E9_PAYS'?=" Cc: Subject: RE: Discussion of notareqs document Date: Wed, 27 Oct 2004 15:07:24 -0400 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0030_01C4BC33.8EB38460" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcS8UAMubVRbfM51RBK5QaTwosr5xwABMnNw In-Reply-To: <417FE118.2080409@edelweb.fr> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C4BC33.8EB38460 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0031_01C4BC33.8EB38460" ------=_NextPart_001_0031_01C4BC33.8EB38460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think we are in disagreement. I was not responding to your last email but to Larry's question regarding whether any of the listed use = cases should be omitted. You seem to agree that a use case targeting = validation of an X.509 certificate is beyond our scope. I agree what you describe below is within our scope. _____ =20 From: owner-ietf-ltans@mail.imc.org = [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-Andr=E9 PAYS Sent: Wednesday, October 27, 2004 1:56 PM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document -- Carl Wallace -- a dit, - le 27/10/2004 19:22:=20 =20 * Should any of the use cases be omitted? =20 I don't think we should include a use case that simply consists of = reporting the validation status of an X.509 certificate. SCVP is well underway = and serves that purpose. That cert validity is reported as part of a data certification operation seems OK but establishing an alternative to SCVP = is not in our scope. =20 I fully agree, but the use case I presented and proposed -in my last = mail- : * is not "simply of reporting the validation status of an X.509 certificate"=20 * is not "Yet Another SCVP"=20 * but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be = assured that the "DVC service" (or ntotary) will keep a detailed and certified = -and securely archived- log entry of this request. =20 *=09 By the way, (and not limited to the above use case) this is one element = of solution against the threat for the long term that the original = certifying keys could be broken some day (before the end of this long term!) * a SCVP report could be forged 20 years after the effective date=20 * BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries". = This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, = but a detailed log entry must be archived in a secure way (non rewritable = medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination = of TSP RFC3061, DVCS RFC3029 and hash-linking) =20 --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9=09 paul-andre.pays@edelweb.fr papays@on-x.com=09 http://www.edelweb.fr/ http://www.on-x.com/=09 Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorit=E9 et la LCR.=20 ------=_NextPart_001_0031_01C4BC33.8EB38460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PAP Sig
I don't think we are in disagreement.  I = was not=20 responding to your last email but to Larry's question regarding whether = any of=20 the listed use cases should be omitted.  You seem to agree that a = use case=20 targeting validation of an X.509 certificate is beyond = our=20 scope.  I agree what you describe below is within our=20 scope.

From: = owner-ietf-ltans@mail.imc.org=20 [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of = Paul-Andr=E9=20 PAYS
Sent: Wednesday, October 27, 2004 1:56 PM
To: = Carl=20 Wallace
Cc: ietf-ltans@imc.org
Subject: Re: = Discussion of=20 notareqs document



 -- Carl Wallace --  a dit,  - le = 27/10/2004=20 19:22:=20 
 <snip>
  
* Should any of the use =
cases be omitted?
    

I don't think we should include a use case that simply consists of =
reporting
the validation status of an X.509 certificate.  SCVP is well underway =
and
serves that purpose.  That cert validity is reported as part of a data
certification operation seems OK but establishing an alternative to SCVP =
is
not in our scope.
I fully agree, but the use case I presented and = proposed=20 -in my last mail- :
  • is not "simply of reporting the validation status of an X.509 = certificate"=20
  • is not "Yet Another SCVP"=20
  • but extend (and possibly encompass) the service rendered by SCVP = or any=20 other, in order to meet the end user's requirement : obtaining a=20 certification (some form of "proof" valid for long term use) by some = external "authority" (not to say notary or e-notary) (of the "fact" = that=20 s/he has actually used a validation service (such as SCVP) and be = assured=20 that the "DVC service" (or ntotary) will keep a detailed and = certified -and=20 securely archived- log entry of this request. 

By the way, (and not limited to the above use = case) this is=20 one element of solution against the threat for the long term that the = original=20 certifying keys could be broken some day (before the end of this long=20 term!)
  • a SCVP report could be forged 20 years after the effective date=20
  • BUT, it will be much more difficult to forge -and in a = consistent way-=20 also the "DVC data cert" and the "secure and archived log entries".=20
This is another proof of the sound approach of LTANS which = links=20 "data certs" and "secure archived". Any "data cert" must not only be = signed,=20 but a detailed log entry must be archived in a secure way (non = rewritable=20 medium, hash linking). This mandatory combination was a major = rationale of the=20 openevidence project (the technical solution by then was a a = combination of=20 TSP RFC3061, DVCS RFC3029 and hash-linking)

--
Edelweb
 Groupe=20 ON-X P=F4le = S=E9curit=E9paul-andre.pays@edelweb.fr= papays@on-x.com<= /TR> http://www.edelweb.fr/ http://www.on-x.com/
Tel.=20 + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 --=20 Adresse : = 15, quai=20 de Dion Bouton  -  92816 Puteaux cedex
Pour = v=E9rifier la=20 signature =E9lectronique, http://edelpki.edelweb.fr/ = vous permet d'obtenir le = certificat de=20 l'autorit=E9 et la LCR.=20 =

= ------=_NextPart_001_0031_01C4BC33.8EB38460-- ------=_NextPart_000_0030_01C4BC33.8EB38460 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOMDCCBEAw ggMooAMCAQICBEClE7wwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9y aW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGll czEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE0MzA1NVoXDTA3MDUxNzE1MDA1NVowWzELMAkGA1UE BhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UECxMJRW1wbG95 ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALLi +sA/Id5PcQ8uPHjuKlWcxrb8kQkBkJrn4Vv/KNrpZZcIO0mTxp28yVqg3fJRWszamV3cbE77oXV/ 0AFxrRhf89avN0lrUmqSBsf7ph8Zfz8HMbNODQvGOsKCGa4HA1jujeTnIqgrlCyyUORELVu4i2a7 uErbLjIX7SHNxGtlAgMBAAGjggGHMIIBgzALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EVY3dhbGxh Y2VAb3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8G A1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cu b3Jpb25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxn ZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY 0jAdBgNVHQ4EFgQUB0yg8DWubbASzzui5JhAF3+oIRYwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAE DDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAYh0dywIAWMho3sca3AwuMZiepipLDF/+ +vrm9Md+P9AfS6pjwRbsBNcS9425jr56ANJXALioZoxDMKlRKXy+Hmj8wXq8nMgPkmfLYhvP+PVn KgOkoQtT3ym7FSCwrDJEvO0azG6uRxhuIevShRsBaxsCCjdnf6xG6OGV0KrniweAsnNoZPdq6bHI 2ZAk8hZNWHWwGmYo1lP9MeZ+5aYvG1T3OoKI7Kyg4SM/OjjqxwuGC1Zoh1nAJHrBuvRxvhrzvf9t 5ff5r7/YEguVTRfnviUhAyB56auTb1+lY+sz+NQB0kBkSXwvq1+R6pJ3eBWH7o9h5QI87j0IbrL/ ZXhj0zCCBG0wggNVoAMCAQICBEClE74wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBB dXRob3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNzE4MDExNFoXDTA3MDUxNzE4MzExNFow WzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczESMBAGA1UE CxMJRW1wbG95ZWVzMRUwEwYDVQQDEwxDYXJsIFdhbGxhY2UwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAK+KL0avuOpT0cjCIpk1FxSdLKeXJvS9YoiWX51DoSimpkLJrVj3dxVZW+ixPGTKpnGB RlGMLOnaqhtIgJ7rSw7/c2Ahc52t8QRdb5HFG96/b4FQabd9zgjiKs82ijzsWvwP1wcDm5YwrTcc 5ZXh4BgelpXgUn5I1kOjTvyC4UuTAgMBAAGjggG0MIIBsDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQw IoAPMjAwNDA1MTcxODAxMTRagQ8yMDA2MDYyMzA2MzExNFowIAYDVR0RBBkwF4EVY3dhbGxhY2VA b3Jpb25zZWMuY29tMIHrBgNVHR8EgeMwgeAweaB3oHWkczBxMQswCQYDVQQGEwJVUzEhMB8GA1UE ChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1dGhv cml0aWVzMQwwCgYDVQQLEwNDQTExDTALBgNVBAMTBENSTDEwMqAwoC6GLGh0dHA6Ly93d3cub3Jp b25zZWMuY29tL0NSTC9jYTFfY3JsZmlsZTQuY3JsMC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVz ZVxDUkxcY2ExX2NybGZpbGU0LmNybDAfBgNVHSMEGDAWgBTIsjzeuprriQmg1jQymxlChsyY0jAd BgNVHQ4EFgQUBoyaS8dak6pJpXXiEkLdnVnyngAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAK GwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAa69I2Ckr0OjSaxgqdueqQczXR74p1qAS9eRC vZjLW23840mKXk/UtiKvF0E9JgZ11/Fqyk/IHHbSnX7r9Z6oLVKvs0Pkk+HlB9X5XGiVm6RXpAzL jHwsKefQsQ9Lsrk8bouPneRqMzoYQ/ea3Azeit1UWMiZYA+Oebv9Lu6oIFVq/ONucRyxTAMN5i91 IZ5bAp3Jb3cUfd3FqmVBctfVemWIOOcgOoRCf7gJKpPqI0CWkR/LIA67F3lD+goNYb07ISIFqVgk VcGhsMJx19lwFl9kXqgHLDhxfTbV6PDb1LkBoIE8O+dhZkYQ2DmH6dHo88+bfOJJ3z6HtA8GpFpb LzCCBXcwggRfoAMCAQICBEClE1EwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCVVMxITAfBgNV BAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllczEMMAoGA1UECxMDQ0ExMB4XDTA0MDUxNDE5MDMxMloXDTI0MDUxNDE5MzMxMlowYjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczEiMCAGA1UECxMZ Q2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEMMAoGA1UECxMDQ0ExMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoJjL4nDMben23Cn1KTo4DfHDtfNZGOWwBW2XI9djn/VuXXO2hj6nX4r4 G1lNwtCpDYn7Lp80dHRFdpn7GnqrfNMHIsKDaRYxpJ0fgi4gE9LdMwnmsEE8WONj7yPVRuI6Xq43 nfO8LTZehHaN+NwUdgh/rXDQLru1AaxYbaJftkpGGwyMDmPwtfgV3TvNf8g50mCTcAripDVm2tzC 4vIOdNCYQJfsRoQggtLwby9nNyxwHKHHh7OlEZPqVJPGn1S1qzFxKjRcLHwzP4vKD6H8nY5ndVk3 4CLZ5jq59kcpoVTDMLySl5PTg6zBuS+1S0nngBAW9FOqUOTBRMyxqHkmgwIDAQABo4ICMzCCAi8w ggGEBgNVHR8EggF7MIIBdzB5oHegdaRzMHExCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBT ZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAK BgNVBAsTA0NBMTENMAsGA1UEAxMEQ1JMMTAyoDCgLoYsaHR0cDovL3d3dy5vcmlvbnNlYy5jb20v Q1JML2NhMV9jcmxmaWxlNC5jcmwwgZSggZGggY6GgYtsZGFwOi8vU0JFVEVMR0VVU0UvY249V2lu Q29tYmluZWQ0LG91PUNBMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1PcmlvbiUy MFNlY3VyaXR5JTIwU29sdXRpb25zLGM9VVM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9CYXNl MC+gLaArhilmaWxlOi8vXFxTYmV0ZWxnZXVzZVxDUkxcY2ExX2NybGZpbGU0LmNybDArBgNVHRAE JDAigA8yMDA0MDUxNDE5MDMxMlqBDzIwMjQwNTE0MTkzMzEyWjALBgNVHQ8EBAMCAQYwHwYDVR0j BBgwFoAUyLI83rqa64kJoNY0MpsZQobMmNIwHQYDVR0OBBYEFMiyPN66muuJCaDWNDKbGUKGzJjS MAwGA1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMDo0LjADAgSQMA0GCSqGSIb3DQEB BQUAA4IBAQA9LSuraaiw3bO+TdsvCuppT4dbud3+lw6LekUzC9uVFzKbVpVUohUezNJ4zz7FbTV3 0zFNBUrjM8twoSJQ+pbAdJRhrva9zztJp+zR1hDiF4xUfQ/VhcW5HQ8AuduMAdDOyDbc2qQFeUwR YfonnJpWZINiCyUavFXKoTKoG6KkaDfrBiKLtOXy6m09Qr1dQ7wGnL8i+iEDGVFiCjlJ1JeP0vDP g+oOwWYTraW69me5EfXXhhvghAbYtkwoEfxS8hAxRfFqh+8LTIf9nL8ug9ImcfQqVZhRBsC8W2+Y TzLrexngHUpedXJuas/XVSW1+COqOt/gU9lWPD+GD+59FYJIMYIC0jCCAs4CAQEwajBiMQswCQYD VQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE74wCQYFKw4DAhoFAKCCAb4w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTg0NTA5WjAj BgkqhkiG9w0BCQQxFgQUhEuVhW7Vc96gYnX7cKLHS9mltTIwZwYJKoZIhvcNAQkPMVowWDAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUweQYJKwYBBAGCNxAEMWwwajBiMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMSIwIAYDVQQLExlDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0aWVzMQwwCgYDVQQLEwNDQTECBEClE7wwewYLKoZIhvcNAQkQAgsxbKBqMGIx CzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxIjAgBgNVBAsT GUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxDDAKBgNVBAsTA0NBMQIEQKUTvDANBgkqhkiG9w0B AQEFAASBgH5xJu2sFkzn6hxv0AZ2em1AmJdUKudrUd5SLiyaHc4JnRPwoLEIvSj4wl+vR5s52EFO zcpcOv1PC6kL58ZScUFVNU8aFl4FNdLXwDePwXu7XKlmGWu8TAAsiCCQH8sYWzD6kSoMs7Vh6/tO HlTRDEGH5aDO1Vu3ujjtVzc2IT6lAAAAAAAA ------=_NextPart_000_0030_01C4BC33.8EB38460-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHtd4b022163; Wed, 27 Oct 2004 10:55:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RHtdTu022162; Wed, 27 Oct 2004 10:55:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHtbLV022154 for ; Wed, 27 Oct 2004 10:55:38 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9RHtcD11937; Wed, 27 Oct 2004 19:55:38 +0200 (MEST) Message-ID: <417FE118.2080409@edelweb.fr> Date: Wed, 27 Oct 2004 19:55:36 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Carl Wallace CC: ietf-ltans@imc.org Subject: Re: Discussion of notareqs document References: <200410271723.i9RHN78J021264@host13.websitesource.com> In-Reply-To: <200410271723.i9RHN78J021264@host13.websitesource.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030807030001030000060000" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030807030001030000060000 Content-Type: multipart/alternative; boundary="------------050700000607020902090004" This is a multi-part message in MIME format. --------------050700000607020902090004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Carl Wallace -- a dit, - le 27/10/2004 19:22: > > =20 > >>* Should any of the use cases be omitted? >> =20 >> > >I don't think we should include a use case that simply consists of repor= ting >the validation status of an X.509 certificate. SCVP is well underway an= d >serves that purpose. That cert validity is reported as part of a data >certification operation seems OK but establishing an alternative to SCVP= is >not in our scope. > =20 > I fully agree, but the use case I presented and proposed -in my last mail= - : * is not "/simply of reporting the validation status of an X.509 certificate/" * is not "Yet Another SCVP" * but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be assured that the "DVC service" (or ntotary) will keep a detailed and certified -and securely archived- log entry of this request.=20 * By the way, (and not limited to the above use case) this is one element=20 of solution against the threat for the long term that the original=20 certifying keys could be broken some day (before the end of this long ter= m!) * a SCVP report could be forged 20 years after the effective date * BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries". This is another proof of the sound approach of LTANS which links "data=20 certs" and "secure archived". Any "data cert" must not only be signed,=20 but a detailed log entry must be archived in a secure way (non=20 rewritable medium, hash linking). This mandatory combination was a major = rationale of the openevidence project (/the technical solution by then=20 was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking/) > > > > =20 > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050700000607020902090004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Carl Wallace --  a dit,  - le 27/10/2004 19:22: 
 <snip>
  
* Should any of the use cases be omitted?
    

I don't think we should include a use case that simply consists of reporting
the validation status of an X.509 certificate.  SCVP is well underway and
serves that purpose.  That cert validity is reported as part of a data
certification operation seems OK but establishing an alternative to SCVP is
not in our scope.
I fully agree, but the use case I presented and proposed -in my last mail- :
  • is not "simply of reporting the validation status of an X.509 certificate"
  • is not "Yet Another SCVP"
  • but extend (and possibly encompass) the service rendered by SCVP or any other, in order to meet the end user's requirement : obtaining a certification (some form of "proof" valid for long term use) by some external "authority" (not to say notary or e-notary) (of the "fact" that s/he has actually used a validation service (such as SCVP) and be assured that the "DVC service" (or ntotary) will keep a detailed and certified -and securely archived- log entry of this request. 

By the way, (and not limited to the above use case) this is one element of solution against the threat for the long term that the original certifying keys could be broken some day (before the end of this long term!)
  • a SCVP report could be forged 20 years after the effective date
  • BUT, it will be much more difficult to forge -and in a consistent way- also the "DVC data cert" and the "secure and archived log entries".
This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, but a detailed log entry must be archived in a secure way (non rewritable medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)

--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050700000607020902090004-- --------------ms030807030001030000060000 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTc1NTM2 WjAjBgkqhkiG9w0BCQQxFgQUxGD/bOrL3frIZ6gQj0UiIMuVMAgwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BHiKPy4lhkdIGkScQXJp9xcSW9tx5UQGqNWIHLXFQF/bnEwn3Z71faKzYT20uy0SDtfDODfw 8DE4YSO4ID2LkpIVCF+vr3FoiCMLwWJ0W7zbK6TR0m2L8fNKqUL2SC1pMoWLubvvYA3nL5AD YyLEe0oXo55QbZMXYWCFDtbDkxopnhcMvIqRzrFqhmIRJNSaAAAAAAAA --------------ms030807030001030000060000-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHN6Fg013762; Wed, 27 Oct 2004 10:23:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RHN6w3013761; Wed, 27 Oct 2004 10:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RHN5LH013754 for ; Wed, 27 Oct 2004 10:23:05 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (172.sub-166-180-42.myvzw.com [166.180.42.172]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9RHN78J021264 for ; Wed, 27 Oct 2004 13:23:07 -0400 Message-Id: <200410271723.i9RHN78J021264@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Discussion of notareqs document Date: Wed, 27 Oct 2004 13:22:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <0I69003IV33PK7@mailsj-v1.corp.adobe.com> Thread-index: AcS8EQeHzNmztPZBTaOxPCVvEq0kkwAJ9+XwAAPQiyA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > * Should any of the use cases be omitted? I don't think we should include a use case that simply consists of reporting the validation status of an X.509 certificate. SCVP is well underway and serves that purpose. That cert validity is reported as part of a data certification operation seems OK but establishing an alternative to SCVP is not in our scope. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RG09bU095165; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RG090G095164; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RG09H2095135 for ; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Wed, 27 Oct 2004 08:59:30 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i9RFxo85021425 for ; Wed, 27 Oct 2004 08:59:55 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9RFxo0U025183 for ; Wed, 27 Oct 2004 08:59:50 -0700 (PDT) Received: from MasinterT40 ([130.248.178.62]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I69003IU33PK7@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Wed, 27 Oct 2004 08:59:50 -0700 (PDT) Date: Wed, 27 Oct 2004 08:59:49 -0700 From: Larry Masinter Subject: Discussion of notareqs document In-reply-to: <417F760B.3030303@edelweb.fr> To: ietf-ltans@imc.org Message-id: <0I69003IV33PK7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=iso-8859-1 Thread-index: AcS8EQeHzNmztPZBTaOxPCVvEq0kkwAJ9+Xw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RG09H2095159 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Note that my email said 'draft-ietf-ltans-notareq-01' but the actual document name is 'draft-ietf-ltans-notareqs-01' with an s; the internet-drafts editor fixed this). I think there is no problem changing the title again to "Data Validation and Certification Service Requirements". On the technical content of the document, I am hoping we can have a good discussion at the IETF meeting about some of these points: Use cases: The use cases in the document are fairly general. We've had some suggestions for more specific use cases, from Paul-André Pays: - validation of an X.509 certificate - validation of a receipt notification by a Long-Term Archive service - "approval" of a document at a given time by at least 67% of the members of a given list of users and from Peter Sylvester (originally at IETF Vienna): - Certify three events of an SMIME message sent (prepare message, receipt of message, receipt of acknowledgement) If we are to include these, we will need to describe them clearly. Are there any problems with including these? * Are there other use cases? * Should any of the use cases be omitted? * What other elements of these use cases should be elaborated? (I think it would be useful to elaborate the 'long term' elements of the use cases, e.g., "after 10 years, someone needs to prove A having sent the message") Requirements: What are the actual requirements corresponding to these use cases, as far as the network protocol or data structures necessary to communicate with an agent performing these services? I think we want to document requirements in the same way that we've been moving the long-term archive requirements document. Security considerations: I think a "Long-Term" service needs some expansion about the requirements for long-term security. For example, over a 30-year period, what is feasible with a "brute force" attack is different than what might be expected over a 2-year period, because of indetermined increases in computing power available to attackers, and the sheer amount of time available to do brute force. Operational considerations: It seems that there are two main purposes to this section -- to be clear about the scaling and performance requirements, and to lay out the operational security measures necessary. I think this could be clearer in the document. References: I had meant to add references to DVCS and ERS and to reference them in the introduction as some prior work in the area. And the reference to the long-term archive requirements could be to RFC XXXX assuming it will be published first (or at least, simultaneously). Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RAJYFt001165; Wed, 27 Oct 2004 03:19:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RAJYQd001163; Wed, 27 Oct 2004 03:19:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RAJWjh001136 for ; Wed, 27 Oct 2004 03:19:32 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9RAIrD05575; Wed, 27 Oct 2004 12:18:53 +0200 (MEST) Message-ID: <417F760B.3030303@edelweb.fr> Date: Wed, 27 Oct 2004 12:18:51 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Denis Pinkas CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> <417D30ED.7090600@edelweb.fr> <417F52D7.8070207@bull.net> In-Reply-To: <417F52D7.8070207@bull.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020007040100030806080201" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020007040100030806080201 Content-Type: multipart/alternative; boundary="------------050608050208070705090402" This is a multi-part message in MIME format. --------------050608050208070705090402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Denis Pinkas -- a dit, - le 27/10/2004 09:48: > > Paul-Andr=E9, > > You said: > > "We can probably have a shortexplanation in the foreword of the=20 > document, stating that in this document the word "data" has to be=20 > understood as the "electronic representation" of a "fact" (or "event").= " > > This is fully correct and I support this. perfect > > However thenafter you added: > > "One specific case of such a "fact" is the submission or validation of = > a document at a given date and time (optionnaly by a specific user),=20 > one specific subcase being the validation of a X.509 certificate". > > I wonder about this. > > Someone (e.g. a notary) can testify hundreds of facts or events. There = > are millions of such facts or events. So we should neither focus on=20 > "submission or validation of a document at a given date and time" nor=20 > on "validation of a X.509 certificate". I never said that the groupe "should focus" on "validation of a=20 certificate" and I am sorry if my wording was so obscure that it could=20 be understood as such. Nevertheless, I still pretend that the ability to obtain from a "Data =20 Certification Service" some form of "evidence", by means of a "data=20 cert" (dated and signed by the DCS authority) that one has indeed=20 verified at a given date and time that an X.509 certificate was checked=20 and validated is indeed one example of "user's requirement" from such a=20 service. Don't read that this should be the goal (main goal, unique goal) of =20 LTANS, just that it cann't be excluded and it makes sense in addition to = such services as OCSP. The "data cert" will "prove" for example that the = signature attached to a given document had been verified by a specific=20 user, at a given date (different from the signature date) using a given=20 "validation service". The actual role of the "Data Certification=20 Service" will not be to perform "itself" the validation work but to=20 certify that is has been done in the specific context (that is the=20 "fact" that is certified") Same could be said about "document validation and submission", the role=20 of the DCS must be to deliver such a data cert and need not to include=20 the actual perfomance of the validation itself. Exactly as a "notary"=20 could establish a certificate that one of is customers has deposited=20 some amount of money at a bank for a specific purpose, that the=20 banknotes had been validated -by the bank- and that this bank has=20 delivered a receipt. The "data-cert" certifies a fact and comes in=20 addition to the bank receipt. This being said, for the purpose of sharing the understanding, I agree=20 that that mentionning "X509 certs validation" too early in the document=20 and as a purpose and not as an example might be confusing, and I=20 certainly do no invite the group to mention this use case event if I=20 still claim that it belongs to the myriads of use cases relevant of such = a service. regards, -- PAP > > Denis > > >> -- Larry Masinter -- a dit, - le 25/10/2004 18:28: >> >>>> This new title will add even more confusion with the PKIX working=20 >>>> group. >>>> =20 >>> >>> >>> I'm sorry about the confusion over the title. We had put off >>> working through the document, so there was some rush to get >>> a new version out. >>> >>> I'm a little uneasy about "Data Validation and Certification" >>> because in many of the use cases, the thing being validated >>> or certified isn't so much "data" as it is an "event" -- an >>> oath was administered, an agreement was understood, etc. >>> =20 >>> >> On one hand, you are right, in many cases what will be certified will = >> not be an document, but as you say a fact or an event, but on the=20 >> other hand, we are dealing with information systems and "facts" or=20 >> "events" will have to be represented and it will be by some "data" (a = >> combination of what, when, by whom ...) >> >> As far as my understanding of the english language is correct,=20 >> "data", as being the more general word(even vague, here it is a clear = >> advantage over a more "accurate" or "connotated" term) is definitely=20 >> the more appropriate. >> >> We can probably have a shortexplanation in the foreword of the=20 >> document, stating that in this document the word "data" has to be=20 >> understood as the "electronic representation" of a "fact" (or "event")= . >> One specific case of such a "fact" is the submission or validation of = >> a document at a given date and time (optionnaly by a specific user),=20 >> one specific subcase being the validation of a X.509 certificate. >> Another case being for example the receipt notification by a Long=20 >> Term Archive service, >> or the the "approval" of a document at a given time by at least 67%=20 >> of the members of a given list of users. >> >> Regards, >> >> -- PAP >> >>> If we keep these use cases, can you think of other alternatives? >>> >>> Larry >>> >>> >>> >>> >>> =20 >>> >> >> --=20 >> Edelweb >> Groupe ON-X P=F4le S=E9curit=E9 >> paul-andre.pays@edelweb.fr papays@on-x.com >> http://www.edelweb.fr/ http://www.on-x.com/ >> >> Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai = >> de Dion Bouton - 92816 Puteaux cedex >> Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr= /=20 >> vous permet d'obtenir le certificat de l'autorit=E9 et la LCR. >> >> >> > > > > > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050608050208070705090402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Denis Pinkas --  a dit,  - le 27/10/2004 09:48:

Paul-André,

You said:

"We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event")."

This is fully correct and I support this.
perfect

However thenafter you added:

"One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate".

I wonder about this.

Someone (e.g. a notary) can testify hundreds of facts or events. There are millions of such facts or events. So we should neither focus on "submission or validation of a document at a given date and time" nor on "validation of a X.509 certificate".
I never said that the groupe "should focus" on "validation of a certificate" and I am sorry if my wording was so obscure that it could be understood as such.
Nevertheless, I still pretend that  the ability to obtain from a "Data  Certification Service" some form of "evidence", by means of a "data cert" (dated and signed by the DCS authority) that one has indeed verified at a given date and time that an X.509 certificate was checked and validated is indeed one example of "user's requirement" from such a service.
Don't read that this should be the goal (main goal, unique goal) of  LTANS, just that it cann't be excluded and it makes sense in addition to such services as OCSP. The "data cert" will "prove" for example that the signature attached to a given document had been verified by a specific user, at a given date (different from the signature date) using a given "validation service".  The actual role of the "Data Certification Service" will not be to perform "itself" the validation work but to certify that is has been done in the specific context (that is the "fact" that is certified")

Same could be said about "document validation and submission", the role of the DCS must be to deliver such a data cert and need not to include the actual perfomance of the validation itself. Exactly as a "notary" could establish a certificate that one of is customers has deposited some amount of money at a bank for a specific purpose, that the banknotes had been validated -by the bank- and that this bank has delivered a receipt. The "data-cert" certifies a fact and comes in addition to the bank receipt.

This being said, for the purpose of sharing the understanding, I agree that that mentionning "X509 certs validation" too early in the document and as a purpose and not as an example might be confusing, and I certainly do no invite the group to mention this use case event if I still claim that it belongs to the myriads of use cases relevant of such a service.

regards,

-- PAP

Denis


 -- Larry Masinter --  a dit,  - le 25/10/2004 18:28:

This new title will add even more confusion with the PKIX working group.
  

I'm sorry about the confusion over the title. We had put off
working through the document, so there was some rush to get
a new version out.

I'm a little uneasy about "Data Validation and Certification"
because in many of the use cases, the thing being validated
or certified isn't so much "data" as it is an "event" -- an
oath was administered, an agreement was understood, etc.
 

On one hand, you are right, in many cases what will be certified will not be an document, but as you say a fact or an event, but on the other hand, we are dealing with information systems and "facts" or "events" will have to be represented and it will be by some "data" (a combination of what, when, by whom ...)

As far as my understanding of the english language is correct, "data", as being the more general word(even vague, here it is a clear advantage over a more "accurate" or "connotated" term) is definitely the more appropriate.

We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event") .
One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate.
Another case being for example the receipt notification by a Long Term Archive service,
or the the "approval" of a document at a given time by at least 67% of the members of a given list of users.

Regards,

-- PAP

If we keep these use cases, can you think of other alternatives?

Larry




 


-- 
Edelweb
Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/

Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.









--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050608050208070705090402-- --------------ms020007040100030806080201 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI3MTAxODUx WjAjBgkqhkiG9w0BCQQxFgQUxvQLu3rnEWIvt2DES1yDsgJUokkwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ AdNExAnDyIqAFB3bZSLh9s8gG8gul33m7CNLNemWsdLGGo0e5CnsMujwEfMlGfN6ED1BAJZi O33sVE7pXPlCH8q9XWB498Jc2Rc7YKS6UytkqyVH9jgId8DsLqg+4tZjJm9IMBNr2WsNEmtv GL14b1c4GFD9C6ug1PtDemdxWp0Weq0lGDCtfD2/c043H0ZNAAAAAAAA --------------ms020007040100030806080201-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7p4vf030867; Wed, 27 Oct 2004 00:51:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9R7p4Um030866; Wed, 27 Oct 2004 00:51:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9R7p2gn030817 for ; Wed, 27 Oct 2004 00:51:03 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA57794; Wed, 27 Oct 2004 10:02:36 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102709504458:342 ; Wed, 27 Oct 2004 09:50:44 +0200 Message-ID: <417F52D7.8070207@bull.net> Date: Wed, 27 Oct 2004 09:48:39 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> <417D30ED.7090600@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:50:44, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/10/2004 09:50:47, Serialize complete at 27/10/2004 09:50:47 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9R7p4gn030860 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul-André, You said: "We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event")." This is fully correct and I support this. However thenafter you added: "One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate". I wonder about this. Someone (e.g. a notary) can testify hundreds of facts or events. There are millions of such facts or events. So we should neither focus on "submission or validation of a document at a given date and time" nor on "validation of a X.509 certificate". Denis > -- Larry Masinter -- a dit, - le 25/10/2004 18:28: > >>>This new title will add even more confusion with the PKIX >>>working group. >>> >>> >> >>I'm sorry about the confusion over the title. We had put off >>working through the document, so there was some rush to get >>a new version out. >> >>I'm a little uneasy about "Data Validation and Certification" >>because in many of the use cases, the thing being validated >>or certified isn't so much "data" as it is an "event" -- an >>oath was administered, an agreement was understood, etc. >> >> > On one hand, you are right, in many cases what will be certified will > not be an document, but as you say a fact or an event, but on the other > hand, we are dealing with information systems and "facts" or "events" > will have to be represented and it will be by some "data" (a combination > of what, when, by whom ...) > > As far as my understanding of the english language is correct, "data", > as being the more general word(even vague, here it is a clear advantage > over a more "accurate" or "connotated" term) is definitely the more > appropriate. > > We can probably have a shortexplanation in the foreword of the document, > stating that in this document the word "data" has to be understood as > the "electronic representation" of a "fact" (or "event") . > One specific case of such a "fact" is the submission or validation of a > document at a given date and time (optionnaly by a specific user), one > specific subcase being the validation of a X.509 certificate. > Another case being for example the receipt notification by a Long Term > Archive service, > or the the "approval" of a document at a given time by at least 67% of > the members of a given list of users. > > Regards, > > -- PAP > >>If we keep these use cases, can you think of other alternatives? >> >>Larry >> >> >> >> >> >> > > -- > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de > Dion Bouton - 92816 Puteaux cedex > Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3sPD017304; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK3sDQ017303; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3svH017297 for ; Mon, 25 Oct 2004 13:03:54 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29379; Mon, 25 Oct 2004 16:03:55 -0400 (EDT) Message-Id: <200410252003.QAA29379@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-notareqs-01.txt Date: Mon, 25 Oct 2004 16:03:55 -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 : Requirements for Certification Services Author(s) : T. Gondrom, et al. Filename : draft-ietf-ltans-notareqs-01.txt Pages : 11 Date : 2004-10-25 This document establishes the goals and requirements for protocols and data structures for use with services that provide additional means for users to ensure and prove the validity of data, especially digitally signed data, in a common and reproducible way. It establishes the need for components to be used in addition to long-term archive services. It provides some use cases and scenarios, and establishes technical requirements for protocols and data structures to support them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-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-notareqs-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-notareqs-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: <2004-10-25162134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-notareqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-notareqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162134.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3Xs2017223; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PK3Xhw017220; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PK3WMc017214 for ; Mon, 25 Oct 2004 13:03:33 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29302; Mon, 25 Oct 2004 16:03:34 -0400 (EDT) Message-Id: <200410252003.QAA29302@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-03.txt Date: Mon, 25 Oct 2004 16:03:34 -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-03.txt Pages : 21 Date : 2004-10-25 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-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-reqs-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-reqs-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: <2004-10-25162129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-25162129.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH1tM0073913; Mon, 25 Oct 2004 10:01:55 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PH1tRp073912; Mon, 25 Oct 2004 10:01:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH1rcf073903 for ; Mon, 25 Oct 2004 10:01:54 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9PH1uD07726; Mon, 25 Oct 2004 19:01:56 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 25 Oct 2004 19:01:56 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9PH1tH22688; Mon, 25 Oct 2004 19:01:55 +0200 (MEST) Date: Mon, 25 Oct 2004 19:01:55 +0200 (MEST) From: Peter Sylvester Message-Id: <200410251701.i9PH1tH22688@chandon.edelweb.fr> To: Denis.Pinkas@bull.net, LMM@acm.org Subject: RE: Document submitted for draft-ietf-ltans-notareq-01.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > If we keep these use cases, can you think of other alternatives? > We can add a text in the requirement saying that we have to find a good name for the protocol and a text: The protocol should be called 'xyz' because of this and that reason. (which can be repeated in the introductions). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PH03hM073457; Mon, 25 Oct 2004 10:00:03 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PH03aD073456; Mon, 25 Oct 2004 10:00:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGxvNa073415 for ; Mon, 25 Oct 2004 09:59:58 -0700 (PDT) (envelope-from paul-andre.pays@edelweb.fr) Received: from [193.51.14.168] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9PGxPD07686; Mon, 25 Oct 2004 18:59:25 +0200 (MEST) Message-ID: <417D30ED.7090600@edelweb.fr> Date: Mon, 25 Oct 2004 18:59:25 +0200 From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= Organization: Edelweb - Groupe ON-X User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: Larry Masinter CC: "'Denis Pinkas'" , ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I650066CF48KP@mailsj-v1.corp.adobe.com> In-Reply-To: <0I650066CF48KP@mailsj-v1.corp.adobe.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040707070805090509080202" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms040707070805090509080202 Content-Type: multipart/alternative; boundary="------------050505080105040404080303" This is a multi-part message in MIME format. --------------050505080105040404080303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable -- Larry Masinter -- a dit, - le 25/10/2004 18:28: >>This new title will add even more confusion with the PKIX=20 >>working group. >> =20 >> > >I'm sorry about the confusion over the title. We had put off >working through the document, so there was some rush to get >a new version out. > >I'm a little uneasy about "Data Validation and Certification" >because in many of the use cases, the thing being validated >or certified isn't so much "data" as it is an "event" -- an >oath was administered, an agreement was understood, etc. > =20 > On one hand, you are right, in many cases what will be certified will=20 not be an document, but as you say a fact or an event, but on the other=20 hand, we are dealing with information systems and "facts" or "events"=20 will have to be represented and it will be by some "data" (a combination = of what, when, by whom ...) As far as my understanding of the english language is correct, "data",=20 as being the more general word(even vague, here it is a clear advantage=20 over a more "accurate" or "connotated" term) is definitely the more=20 appropriate. We can probably have a shortexplanation in the foreword of the document, = stating that in this document the word "data" has to be understood as=20 the "electronic representation" of a "fact" (or "event") . One specific case of such a "fact" is the submission or validation of a=20 document at a given date and time (optionnaly by a specific user), one=20 specific subcase being the validation of a X.509 certificate. Another case being for example the receipt notification by a Long Term=20 Archive service, or the the "approval" of a document at a given time by at least 67% of=20 the members of a given list of users. Regards, -- PAP >If we keep these use cases, can you think of other alternatives? > >Larry > > > > > =20 > --=20 Edelweb Groupe ON-X P=F4le S=E9curit=E9 paul-andre.pays@edelweb.fr papays@on-x.com http://www.edelweb.fr/ http://www.on-x.com/ Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de = Dion Bouton - 92816 Puteaux cedex Pour v=E9rifier la signature =E9lectronique, http://edelpki.edelweb.fr/ v= ous=20 permet d'obtenir le certificat de l'autorit=E9 et la LCR. --------------050505080105040404080303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

 -- Larry Masinter --  a dit,  - le 25/10/2004 18:28: 
This new title will add even more confusion with the PKIX 
working group.
    

I'm sorry about the confusion over the title. We had put off
working through the document, so there was some rush to get
a new version out.

I'm a little uneasy about "Data Validation and Certification"
because in many of the use cases, the thing being validated
or certified isn't so much "data" as it is an "event" -- an
oath was administered, an agreement was understood, etc.
On one hand, you are right, in many cases what will be certified will not be an document, but as you say a fact or an event, but on the other hand, we are dealing with information systems and "facts" or "events" will have to be represented and it will be by some "data" (a combination of what, when, by whom ...)

As far as my understanding of the english language is correct, "data", as being the more general word(even vague, here it is a clear advantage over a more "accurate" or "connotated" term) is definitely the more appropriate.

We can probably have a shortexplanation in the foreword of the document, stating that in this document the word "data" has to be understood as the "electronic representation" of a "fact" (or "event") .
One specific case of such a "fact" is the submission or validation of a document at a given date and time (optionnaly by a specific user), one specific subcase being the validation of a X.509 certificate.
Another case being for example the receipt notification by a Long Term Archive service,
or the the "approval" of a document at a given time by at least 67% of the members of a given list of users.

Regards,

-- PAP
If we keep these use cases, can you think of other alternatives?

Larry

--
PAP Sig
Edelweb
 Groupe ON-X Pôle Sécurité
paul-andre.pays@edelweb.fr papays@on-x.com
http://www.edelweb.fr/ http://www.on-x.com/
Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous permet d'obtenir le certificat de l'autorité et la LCR.


--------------050505080105040404080303-- --------------ms040707070805090509080202 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOsDCC BHgwggLloAMCAQICBgn6iOLoTjANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNDEwMDcxNTUyNDBaFw0wNjEyMTYxNTUyNDBaMHEx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNjA0BgNVBAMMLVBhdWwtQW5kcsOpIFBBWVMgPFBhdWwtQW5kcmUuUGF5c0BlZGVsd2Vi LmZyPjCBrjANBgkqhkiG9w0BAQEFAAOBnAAwgZgCgZAGaAomVpYawdvSiZ+AqStCFIwcvBXD xNik4odWHQa0xuJdTwLE5fBOenqOaWSlX8Xv545m5Anmdbb5UUHVHOAFfxo9+ZK7h9S4n+Qj ZiLPSBMy8jWR4jNuI/wKhNZgSJGOiyfw5cPFphzIbz6uS8t3e07/VmzB12Ox8JV+/76/QuW/ CQGhC76J0HoKSPp1sJkCAwEAAaOCASQwggEgMGMGA1UdEQRcMFqBGlBhdWwtQW5kcmUuUGF5 c0BlZGVsd2ViLmZypDwwOjELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGTAXBgNV BAMMEFBhdWwtQW5kcsOpIFBBWVMwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2Vi LmZyL2NybC9FZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFLi5Tz1lSeZ8 2PzZ7z18uvaocpcbMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MA0GCSqGSIb3 DQEBBQUAA4IBfAAS2zVcNs/YjJn4ue4LOO5crlcIGKFB47kDv7u/HF4ghD21LkEIrRJyrw5K SnB91g8KQkeUOhm7oBGF3oh83tE4OVeDTE2gLaPUtEt9dTeoykuXne69HMOLepYzaTVsfn6D j7pfOkIJPTkFaeUaMQWNnrYKYEa9wX8EXcPdW/xqkea2yLaGI4In6PulYR75Bbbx8ROSSB5C sVV/4VecgqKaV/MtFVNnvheaJ4gT7VXEJ7pypFWzKKYORMZCJqNxqrM+4mNCC9CkC8ekV2Uf qawIHAYcmSc6HPtxWDXFRJw9eUswyzgcgiK/1A5r34BoqV3FSmMLsCwsYWmY2oIbt/nJSOa1 m5GEtKQBNtRlJl2i9jkkUagRCtcrbj1KNwWQwzdRRUGPOuoKzzDlzle43IwXtUNpS3cPz2Un VPpHQkZe0rt19Q0hfdEtzGvNESs7C0mujk4YMg3UE8BBPXsVDkgQ6ZdboW/51b0s7feAH9hS V0WpbnjA0SPMra8NMIIEeDCCAuWgAwIBAgIGCfqI4uhOMA0GCSqGSIb3DQEBBQUAMFsxCzAJ BgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kx IDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA0MTAwNzE1NTI0MFoXDTA2 MTIxNjE1NTI0MFowcTELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsM D1NlcnZpY2UgRWRlbFBLSTE2MDQGA1UEAwwtUGF1bC1BbmRyw6kgUEFZUyA8UGF1bC1BbmRy ZS5QYXlzQGVkZWx3ZWIuZnI+MIGuMA0GCSqGSIb3DQEBAQUAA4GcADCBmAKBkAZoCiZWlhrB 29KJn4CpK0IUjBy8FcPE2KTih1YdBrTG4l1PAsTl8E56eo5pZKVfxe/njmbkCeZ1tvlRQdUc 4AV/Gj35kruH1Lif5CNmIs9IEzLyNZHiM24j/AqE1mBIkY6LJ/Dlw8WmHMhvPq5Ly3d7Tv9W bMHXY7HwlX7/vr9C5b8JAaELvonQegpI+nWwmQIDAQABo4IBJDCCASAwYwYDVR0RBFwwWoEa UGF1bC1BbmRyZS5QYXlzQGVkZWx3ZWIuZnKkPDA6MQswCQYDVQQGEwJGUjEQMA4GA1UECgwH RWRlbFdlYjEZMBcGA1UEAwwQUGF1bC1BbmRyw6kgUEFZUzAOBgNVHQ8BAf8EBAMCBeAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9l ZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0ktRWRlbFdlYi1QZXJzR0VOLmNybDAdBgNV HQ4EFgQUuLlPPWVJ5nzY/NnvPXy69qhylxswHwYDVR0jBBgwFoAUnuUPwRSVSRzdWl1enK7N AW8vlHkwDQYJKoZIhvcNAQEFBQADggF8ABLbNVw2z9iMmfi57gs47lyuVwgYoUHjuQO/u78c XiCEPbUuQQitEnKvDkpKcH3WDwpCR5Q6GbugEYXeiHze0Tg5V4NMTaAto9S0S311N6jKS5ed 7r0cw4t6ljNpNWx+foOPul86Qgk9OQVp5RoxBY2etgpgRr3BfwRdw91b/GqR5rbItoYjgifo +6VhHvkFtvHxE5JIHkKxVX/hV5yCoppX8y0VU2e+F5oniBPtVcQnunKkVbMopg5ExkImo3Gq sz7iY0IL0KQLx6RXZR+prAgcBhyZJzoc+3FYNcVEnD15SzDLOByCIr/UDmvfgGipXcVKYwuw LCxhaZjaghu3+clI5rWbkYS0pAE21GUmXaL2OSRRqBEK1ytuPUo3BZDDN1FFQY866grPMOXO V7jcjBe1Q2lLdw/PZSdU+kdCRl7Su3X1DSF90S3Ma80RKzsLSa6OThgyDdQTwEE9exUOSBDp l1uhb/nVvSzt94Af2FJXRalueMDRI8ytrw0wggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZI hvcNAQEFBQAwUjELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1Nl cnZpY2UgRWRlbFBLSTEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMw WhcNMTEwODEyMTU0MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYG A1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dF TjCCAZwwDQYJKoZIhvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bc rJKIlnAPn6eH8V1MORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5Jfu DjU6Aq0RzmjqTWDe1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WL wHLA+sIKFzA/CCRtqeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQ NHeCgbUvebvAT9HdUGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy 4DazzXfZosKeJATHpyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38 psgnVLtPPITgOZrScV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+ EiISL7aJHQcJRoNBCdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8G A1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkr j9SwZ7q9SVy8M/x3UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R /adID02c2B3aOUUy4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZ VrZtmrpKCjBh1tNzQbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/G bXsAfEsHV0IQjM7uUS+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4 XRQ0goXYGcM8xXYjPDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QE Hhw6Bv1yxLYXGamqUxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEK ggonklzUXA+sUbCfAd5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9u TeANcRocftHfgM7YrQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xC YkJ9Pg7Op30o43l6PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQ Gti2UcxtJAa2NmULd+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7Z NlTIZvR/VFWxlY18k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzF tHf3D9VAholjhEFgd28aJSs6qN15PXDgDjptAl34eoUxggK+MIICugIBATBlMFsxCzAJBgNV BAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAe BgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYJ+oji6E4wCQYFKw4DAhoFAKCCAZ8w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDQxMDI1MTY1OTI1 WjAjBgkqhkiG9w0BCQQxFgQUEJCRv7zchnp0nYT9Z/QJ5DK1+S4wUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQG EwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYD VQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTgIGCfqI4uhOMA0GCSqGSIb3DQEBAQUABIGQ BVYWh7hisdlx3MzpDY78oUlcZAIoNctWwQOdf0ix708PasEYBGydx8+MxmFhy4AQAr9hyJgi yP1EX/qfAPw8UMGOFM9hm5ag1gdpHamRPRehiwhq1A+zic1ElvGDisOAOZK/qrvf07Ez/Npy nAd8Dm02AAqiu7zMewjqLSyzyKa3SptVmwfxuo5B4SaA2Jv6AAAAAAAA --------------ms040707070805090509080202-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PGTTC6064629; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PGTTY7064628; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob5.obsmtp.com [64.18.1.215]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9PGTTNC064622 for ; Mon, 25 Oct 2004 09:29:29 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 25 Oct 2004 09:28:36 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9PGSvph000689; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9PGSvTk014217; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Received: from MasinterT40 ([130.248.176.23]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I6500669F48KP@mailsj-v1.corp.adobe.com>; Mon, 25 Oct 2004 09:28:57 -0700 (PDT) Date: Mon, 25 Oct 2004 09:28:56 -0700 From: Larry Masinter Subject: RE: Document submitted for draft-ietf-ltans-notareq-01.txt In-reply-to: <417CACBD.9000409@bull.net> To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org Message-id: <0I650066CF48KP@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcS6Z/sTgPshzjbfSjeNxkrNbh8EvgARsr+A Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > This new title will add even more confusion with the PKIX > working group. I'm sorry about the confusion over the title. We had put off working through the document, so there was some rush to get a new version out. I'm a little uneasy about "Data Validation and Certification" because in many of the use cases, the thing being validated or certified isn't so much "data" as it is an "event" -- an oath was administered, an agreement was understood, etc. If we keep these use cases, can you think of other alternatives? Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDKXTB038033; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9PDKXdE038032; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9PDKWFc038024 for ; Mon, 25 Oct 2004 06:20:33 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (218.sub-166-180-50.myvzw.com [166.180.50.218]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9PDKXHt015653 for ; Mon, 25 Oct 2004 09:20:34 -0400 Message-Id: <200410251320.i9PDKXHt015653@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: -03 reqs draft and agenda requests Date: Mon, 25 Oct 2004 09:20:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C4BA73.E1EA4A90" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200410242153.i9OLrij0018767@host13.websitesource.com> Thread-Index: AcS6E+7G2iyngfv9TD6UKK2nNZU1wAAgN7aQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C4BA73.E1EA4A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI, Peter Sylvester has posted the updated requirements doc at: http://ltans.edelweb.fr/draft-ietf-ltans-reqs-03.html. The IETF publication may not occur for a few days. All of the WG drafts, and various other docs, are available at http://ltans.edelweb.fr. ------=_NextPart_000_0052_01C4BA73.E1EA4A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -03 reqs draft and agenda requests
FYI, Peter Sylvester has posted the updated = requirements=20 doc at: http://ltans.edelweb.fr/draft-ietf-ltans-reqs-03.html= .  The IETF publication may not occur = for a few=20 days.  All of the WG drafts, and various other docs, are = available at=20 http://ltans.edelweb.fr.
------=_NextPart_000_0052_01C4BA73.E1EA4A90-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7bekx038319; Mon, 25 Oct 2004 00:37:40 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9P7bepx038318; Mon, 25 Oct 2004 00:37:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9P7bc2Y038268 for ; Mon, 25 Oct 2004 00:37:39 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA36534; Mon, 25 Oct 2004 09:49:16 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004102509372617:2530 ; Mon, 25 Oct 2004 09:37:26 +0200 Message-ID: <417CACBD.9000409@bull.net> Date: Mon, 25 Oct 2004 09:35:25 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Larry Masinter CC: ietf-ltans@imc.org Subject: Re: Document submitted for draft-ietf-ltans-notareq-01.txt References: <0I60003T9DQB9T@mailsj-v1.corp.adobe.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 09:37:26, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/10/2004 09:37:27, Serialize complete at 25/10/2004 09:37:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Larry, > After some discussion with co-editors of the document (and some > subsequent reorganization on my own), I've submitted a new > version of the 'notareq' document. > The title is now 'Requirements for Certification Services'. This new title will add even more confusion with the PKIX working group. Once you proposed: "Data Validation and Certification Protocol Requirements". The word "data" has been dropped in the new proposal. "Requirements for Data Certification Services" could be appropriate, but "Requirements for Certification Services" is not. Denis > Most of the document is significantly rewritten. There is still > need for quite a bit of work. > > If you would like a preview before the internet draft is > available, you may find this at: > > http://larry.masinter.net/ltans-notary-req.txt (plain text, what was > submitted) > http://larry.masinter.net/ltans-notary-req.xml (source xml, should view) > http://larry.masinter.net/ltans-notary-req.html (html transformation) > > Larry > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLrhkY099741; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9OLrhYo099740; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9OLrgAh099731 for ; Sun, 24 Oct 2004 14:53:43 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-70-17-123-202.res.east.verizon.net [70.17.123.202]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9OLrij0018767 for ; Sun, 24 Oct 2004 17:53:53 -0400 Message-Id: <200410242153.i9OLrij0018767@host13.websitesource.com> From: "Carl Wallace" To: Subject: -03 reqs draft and agenda requests Date: Sun, 24 Oct 2004 17:53:44 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C4B9F2.6CAF0490" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcS6E+7G2iyngfv9TD6UKK2nNZU1wA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C4B9F2.6CAF0490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The -03 version of the archive requirements draft has been submitted. It addresses all of the editorial comments and many of the non-editorial comments. I adopted Larry's suggestion to include bracketed notes in the draft to highlight areas that require further list discussion. Also, if anyone would like a slot on the agenda during the LTANS session at the IETF meeting let me know. We're currently scheduled for a two hour slot starting at 1PM on Nov. 11th. ------=_NextPart_000_0013_01C4B9F2.6CAF0490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -03 reqs draft and agenda requests

The -03 version of the archive = requirements draft has been submitted.  It addresses all of the = editorial comments and many of the non-editorial comments.  I = adopted Larry's suggestion to include bracketed notes in the draft to = highlight areas that require further list discussion.

Also, if anyone would like a slot on = the agenda during the LTANS session at the IETF meeting let me = know.  We're currently scheduled for a two hour slot starting at = 1PM on Nov. 11th. 

------=_NextPart_000_0013_01C4B9F2.6CAF0490-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9MNAvYg035754; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9MNAv9J035753; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob5.obsmtp.com [64.18.1.215]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9MNAvU0035742 for ; Fri, 22 Oct 2004 16:10:57 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob5.obsmtp.com ([64.18.5.12]) with SMTP; Fri, 22 Oct 2004 16:10:45 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9MNB0ph002976 for ; Fri, 22 Oct 2004 16:11:00 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9MNAx0S012927 for ; Fri, 22 Oct 2004 16:11:00 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I60003T8DQB9T@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Fri, 22 Oct 2004 16:10:59 -0700 (PDT) Date: Fri, 22 Oct 2004 16:10:59 -0700 From: Larry Masinter Subject: Document submitted for draft-ietf-ltans-notareq-01.txt To: ietf-ltans@imc.org Message-id: <0I60003T9DQB9T@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcS4jGR+4QH4daWZRHubySDoeWrq2A== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: After some discussion with co-editors of the document (and some subsequent reorganization on my own), I've submitted a new version of the 'notareq' document. The title is now 'Requirements for Certification Services'. Most of the document is significantly rewritten. There is still need for quite a bit of work. If you would like a preview before the internet draft is available, you may find this at: http://larry.masinter.net/ltans-notary-req.txt (plain text, what was submitted) http://larry.masinter.net/ltans-notary-req.xml (source xml, should view) http://larry.masinter.net/ltans-notary-req.html (html transformation) Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9INPf2c029929; Mon, 18 Oct 2004 16:25:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9INPfxQ029928; Mon, 18 Oct 2004 16:25:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [64.18.1.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9INPchD029909 for ; Mon, 18 Oct 2004 16:25:38 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Mon, 18 Oct 2004 16:25:13 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i9INPYNf015379; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9INPYTk014766; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Received: from MasinterT40 (c-130-169.corp.adobe.com [153.32.130.169]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5S003Q3ZQMJV@mailsj-v1.corp.adobe.com>; Mon, 18 Oct 2004 16:25:34 -0700 (PDT) Date: Mon, 18 Oct 2004 16:25:34 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410181804.i9II44p23059@chandon.edelweb.fr> To: "'Peter Sylvester'" Cc: ietf-ltans@imc.org Message-id: <0I5S003Q4ZQMJV@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcS1PqckElJM22c7RZmbKT7U7EwLpAAKjAjA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I and the other editors of the notary services requirements draft will be attempting to take feedback so far and integrate it into the document. I already converted the document to XML a while back, but there's nothing to be posted yet. I hope we'll have a new version before the Monday cutoff. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II44kS073908; Mon, 18 Oct 2004 11:04:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9II44ki073907; Mon, 18 Oct 2004 11:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9II42lD073895 for ; Mon, 18 Oct 2004 11:04:03 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9II45N22365; Mon, 18 Oct 2004 20:04:05 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 18 Oct 2004 20:04:05 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9II44p23059; Mon, 18 Oct 2004 20:04:04 +0200 (MEST) Date: Mon, 18 Oct 2004 20:04:04 +0200 (MEST) From: Peter Sylvester Message-Id: <200410181804.i9II44p23059@chandon.edelweb.fr> To: Denis.Pinkas@bull.net, rhansberger@nationalnotary.org, tobias@ixos.de Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, I thought that the discussion of last days indicated that the protocols for 'notarisation' (voluntarily written with an s) are NOT there to define all and everything what a 'notary' can do or DOES and exclusively a notary, but rather technical services that can/may be used by notaries but also by other people/services. ==> more use cases necessary, not just 'a notary'. e.g. B&B a "service" in a company that needs to countersign all outgoing invoices, contracts, letters, whatever (this service talks to a company archiver). A service can be implemented by a machine process combined with some persons who 'confirm'. Here some concrete text. - The protocol intends to have a 'client' delegate some validation and procedural activity to some entity that will deliver an attestation concerning the operation. - An attestation contains payload data and may eventually contain a security envelope. - The payload can occur in at least two flavors: - An information collection attestation, including all things that have been done. (signed document is valid because the follwing CAs are trustworthy, and I have performed the validation against CRL etc etc) - An information reduction attestation, i.e. 'this document is valid according to policy, details of my activities concerning this statement may be obtained via reference xyz' - Security envelopes of attestion can come from persons or machines (with the common understanding of 'a person making a digital signature' - Since we seem to operate in context of digital signature, some particular 'validation policy' concerns the validity of digital signatures and, in particular, for attestations. - ERS and archives techniques are most likely used in order to ensure long term validity (if necessary), either explicitly towards the clients, or internally to the service (securing and archiving an activity log). - The protocol is not intended to replace whatever activity of a notary by a totally automated process. Well, my few cents. Peter BTW: http://www.edelweb.fr/EdelStuff/EdelNews/#first Thanks in advance PS: I'd like to know how others are preparing the drafts, I have good experience with Marshall Rose' XML based tool, if this could be used, I propose to make the xml version available in the web server, contributions seem easier to make, not even speaking about the work that we canb save to the rfc editor. The reverse engineering of a draft to an nroff input creates a horrible amount of pbs. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGETD2051739; Mon, 18 Oct 2004 09:14:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9IGETVk051738; Mon, 18 Oct 2004 09:14:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.98.ixos.de [149.235.31.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9IGERG2051708 for ; Mon, 18 Oct 2004 09:14:28 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from samxg01.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id i9IGDnXi019459; Mon, 18 Oct 2004 18:13:51 +0200 (MEST) Received: from MUCXGC1.opentext.net ([149.235.128.13]) by samxg01.opentext.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Oct 2004 09:13:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Notary services requirements -- directions? Date: Mon, 18 Oct 2004 18:13:43 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B07049D898@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notary services requirements -- directions? Thread-Index: AcS06XnetMoLKwFLRimESNSXkJs/NQAQzDFw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Denis Pinkas" , "Richard Hansberger" Cc: X-OriginalArrivalTime: 18 Oct 2004 16:13:49.0058 (UTC) FILETIME=[7395F620:01C4B52D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9IGESG2051731 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I fully agree with Denis statement that we need to clarify more what kind of services should be offered per example. E.g. should there be a service for administering of oaths (just to choose one) - how would it look like ? Please, this is the question for me to the mailing list: What kind of use case/scenario do you see ? I would really appreciate a first version of a strawman definition so that we can focus again on gaining a hold on what the definition should be. Tobias > The current text states: > > The functions of notaries > include the attestation of documents and certification of their due > execution, administering of oaths, witnessing affidavits and > statutory declarations, certification of copy documents, noting and > protesting of bills of exchange and the preparation of ships' > protests. > > This tells what the functions of notaries are, but still does not tell > what > notary services are or will be. > > Later on the text says: > > A notary service should support and enable a human notary to fullfill > his tasks with electronic documents as well as he already does with > paper based documents and processes. > > This is is closer but still does not tell what "notary services" are or > will be. > > Finally we have: > > Notary service: electronic service that supports a human notary > to provide his/her services on electronic based processes and > documents. > > Is this definition sufficient ? I do not think so, since it is too broad > and > is not self-descriptive. > > I understand that the "notaries services" that we will consider will only > cover a *subset* of all the services a (human) Notary can perform, and we > have not yet identified that subset of services and both the different or > common characteristics of that subset. > > So I ask the editor (or others) to propose a strawman definition that we > can > discuss. > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I7sdIZ009484; Mon, 18 Oct 2004 00:54:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I7sdwk009483; Mon, 18 Oct 2004 00:54:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I7sbp9009404 for ; Mon, 18 Oct 2004 00:54:38 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA80236; Mon, 18 Oct 2004 10:06:07 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004101809542352:1603 ; Mon, 18 Oct 2004 09:54:23 +0200 Message-ID: <41737645.6010507@bull.net> Date: Mon, 18 Oct 2004 09:52:37 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Richard Hansberger CC: "'ietf-ltans@imc.org'" Subject: Re: Notary services requirements -- directions? References: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 09:54:23, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 18/10/2004 09:54:25, Serialize complete at 18/10/2004 09:54:25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, I do understand that it is important to say exactly what means "notary service" or "Notary service". The first sentence of the abstract of the draft on "Notary Services requirements" is is too vague and thus does not provide an adequate explanation: Notary services are available today in a wide variety for paper based processes and documents. Until we agree on a definition of "notary service" or "Notary service", we will have endless discussions. The current text states: The functions of notaries include the attestation of documents and certification of their due execution, administering of oaths, witnessing affidavits and statutory declarations, certification of copy documents, noting and protesting of bills of exchange and the preparation of ships' protests. This tells what the functions of notaries are, but still does not tell what notary services are or will be. Later on the text says: A notary service should support and enable a human notary to fullfill his tasks with electronic documents as well as he already does with paper based documents and processes. This is is closer but still does not tell what "notary services" are or will be. Finally we have: Notary service: electronic service that supports a human notary to provide his/her services on electronic based processes and documents. Is this definition sufficient ? I do not think so, since it is too broad and is not self-descriptive. I understand that the "notaries services" that we will consider will only cover a *subset* of all the services a (human) Notary can perform, and we have not yet identified that subset of services and both the different or common characteristics of that subset. So I ask the editor (or others) to propose a strawman definition that we can discuss. Denis > Respectfully, I'll disagree with the determination that "notary service" is > an appropriate term. Here in the states, we went through a similar debate > when major CAs and others offered "digital notary services" in the wake of > passage of the Federal "E-Sign" Act. Personally, I think it had a > detrimental effect overall and all these "services" have since closed up > shop or been renamed, but that's just my opinion. > > What Notaries do, in other words, has little to do with the certification > that a document is a true and original copy. Notaries witness signings, take > oaths and affirmations, and perform other in-person kinds of functions. I > guess I'm just sensitive to the appropriation of the word as an adjective. > Notary is a noun;-) > > Regardless, if the majority feels it is appropriate then I'll oblige and say > no more. > > Thanks, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > > -----Original Message----- > From: Tobias Gondrom [mailto:tobias@ixos.de] > Sent: Friday, October 15, 2004 8:20 AM > To: Carl Wallace; Larry Masinter > Cc: ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > > > > >>>From: Larry Masinter [mailto:LMM@acm.org] >>>Sent: Tuesday, October 12, 2004 7:25 PM >>>Subject: RE: Notary services requirements -- directions? >>> >>>Personally, I don't think we get into too much trouble using >>>the word 'Notary' in the title of the working group or even >>>in the title of a document here and there, as long as we're >>>clear -- after all, it's a term that's been used already in >>>the industry, and we're not particularly offering those >>>services for sale, in any case. >> >>I don't mind the title either. > > > I also agree. I can understand possible problems when a company sells a > notary service and is not allowed to, but this is neither the case with > the name of the WG or the Name of the requirements - basically I like to > call the things by the best fitting name if I find one at all... ;-) > > So I see no problem calling a document requirements for notary services, > e.g. > > >>>I think the requirements document might note that the term >>>may have restricted use in some legal jurisdictions, and I >>>think it is reasonable to add some wording to that effect. >> > > Full ACK, although I wouldn't add too much - there will always be one > place in the world where some wording might cause legal conflicts and it > is always up to the companies to resolve these conflicts when the > implement things and sell products to local customers. > > > >>>Are time-stamping services associated with unsigned data out >>>of scope, because they're already covered? >> >>I'm not sure what you mean out of scope. If you mean outside the > > scope > >>for >>new specification work, I think so. If you mean outside the scope of > > what > >>we may refer to as a notary service, I don't think so. Timestamping > > seems > >>like a fundamental component. We've explicitly included support for >>unsigned data in the archive discussion and since those have so far > > been > >>discussed pretty much solely in terms timestamp solutions, I think > > this is > >>in scope (if already covered elsewhere). >> >> >>>Are combined archive-and-certification services (which >>>archive data and also provide for the certification of the >>>data archived) out of scope? >> >>I think this combination is very much in scope. It seems natural for > > the > >>data certification service we define to be capable of verifying the >>structures defined for long-term archive purposes. For some purposes, >>this >>combination may be invest too much trust in a single entity. For > > other > >>purposes, it seems like the ideal pairing (e.g. a binding that > > verified > >>the >>evidence record upon data retrieval). > > > I also agree with Carl - this is a possible but not necessary > combination. > > Tobias > > > ------------------------------------------------------------------------ > > This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9I79EiB092470; Mon, 18 Oct 2004 00:09:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9I79EZ4092469; Mon, 18 Oct 2004 00:09:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout01.datevnet.de (mailout01.datevnet.de [193.27.50.76]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9I79CZo092372 for ; Mon, 18 Oct 2004 00:09:13 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 12187 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from mail01.services.datevnet.de (10.252.80.78) by mailout01.services.datevnet.de with SMTP; 18 Oct 2004 07:08:55 -0000 Received: (qmail 16772 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from localhost (HELO mail01.services.datev.de) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 18 Oct 2004 07:08:55 -0000 Received: (qmail 16767 invoked from network); 18 Oct 2004 07:08:55 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 18 Oct 2004 07:08:55 -0000 From: "Michael Tielemann" To: Subject: AW: Notary services requirements -- directions? Date: Mon, 18 Oct 2004 09:09:00 +0200 Message-ID: <001a01c4b4e1$57d2a380$9c01fb0a@P25823E0> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4170A0F4.7030801@strongauth.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9I79DZo092462 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: That's it. A technical standard should be open for different scenarios. It's up to the standard to provide a common basis for implementing applications on top of it. We should understand the wg group results as a vehicle for any technical approach, e.g #1 I guess the recommandation "Long-term Data Validation Protocol" is a good one. -Michael Tielemann > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Arshad Noor > Gesendet: Samstag, 16. Oktober 2004 06:18 > An: 'ietf-ltans@imc.org' > Betreff: Re: Notary services requirements -- directions? > > > > Seems to me, the list is struggling with two different issues: > > 1) the protocols and standards associated with verifying the > authenticity of a document over very long periods; and > > 2) the potential use of such technology to maintain the legal > validity of documents that were presumably electronically > notarized by human notaries. > > I believe it is possible for the WG to achieve #1 without > being concerned about #2. If specific business groups > (Notaries) wish to create legal bindings around the technical > protocols, so be it. The technical standards should support > that outcome without being concerned about what human > notaries do - value-added integrators, software & hardware > vendors will worry about that using the standards & protocols > established by this WG. > > Since legitimate businesses - even outside the notarial areas > - will have use for such technology, it behooves this group > to maintain focus on #1 without being concerned about #2. > > I would recommend the use of something along the lines of > "Long-term Data Validation Protocol" to remain industry-neutral. > > Arshad Noor > StrongAuth, Inc. > > Richard Hansberger wrote: > > Respectfully, I'll disagree with the determination that "notary > > service" is an appropriate term. Here in the states, we > went through a > > similar debate when major CAs and others offered "digital notary > > services" in the wake of passage of the Federal "E-Sign" Act. > > Personally, I think it had a detrimental effect overall and > all these > > "services" have since closed up shop or been renamed, but > that's just > > my opinion. > > > > What Notaries do, in other words, has little to do with the > > certification that a document is a true and original copy. Notaries > > witness signings, take oaths and affirmations, and perform other > > in-person kinds of functions. I guess I'm just sensitive to the > > appropriation of the word as an adjective. Notary is a noun;-) > > > > Regardless, if the majority feels it is appropriate then > I'll oblige > > and say no more. > > > > Thanks, > > > > Richard J. Hansberger > > Director of eNotarization > > National Notary Association > > 818-739-4027 > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GIbE7D025240; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9GIbEEn025239; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9GIbDiS025202 for ; Sat, 16 Oct 2004 11:37:14 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from [172.0.0.1] ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 16 Oct 2004 13:37:15 -0500 Received: from no.name.available by [172.0.0.1] via smtpd (for [200.57.34.107] [200.57.34.107]) with ESMTP; Sat, 16 Oct 2004 13:33:21 -0600 From: "Miguel Rodriguez" To: Subject: RE: Notary services requirements -- directions? Date: Sat, 16 Oct 2004 13:33:11 -0500 Message-ID: <001001c4b3ae$97aa7a70$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4170A0F4.7030801@strongauth.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-OriginalArrivalTime: 16 Oct 2004 18:37:15.0703 (UTC) FILETIME=[28B84470:01C4B3AF] Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Mr Moor's point of view. Miguel A Rodriguez SeguriData Mexico > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Arshad Noor > Sent: Friday, October 15, 2004 11:18 PM > To: 'ietf-ltans@imc.org' > Subject: Re: Notary services requirements -- directions? > > > > Seems to me, the list is struggling with two different issues: > > 1) the protocols and standards associated with verifying the > authenticity of a document over very long periods; and > > 2) the potential use of such technology to maintain the legal > validity of documents that were presumably electronically > notarized by human notaries. > > I believe it is possible for the WG to achieve #1 without being > concerned about #2. If specific business groups (Notaries) wish > to create legal bindings around the technical protocols, so be it. > The technical standards should support that outcome without being > concerned about what human notaries do - value-added integrators, > software & hardware vendors will worry about that using the > standards & protocols established by this WG. > > Since legitimate businesses - even outside the notarial areas - > will have use for such technology, it behooves this group to > maintain focus on #1 without being concerned about #2. > > I would recommend the use of something along the lines of > "Long-term Data Validation Protocol" to remain industry-neutral. > > Arshad Noor > StrongAuth, Inc. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9G4I7VC024118; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9G4I7MW024117; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9G4I4Vm024102 for ; Fri, 15 Oct 2004 21:18:07 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I5N00KS3S9FI0@igw.noorhome.net> for ietf-ltans@imc.org; Fri, 15 Oct 2004 20:56:03 -0700 (PDT) Date: Fri, 15 Oct 2004 21:17:56 -0700 From: Arshad Noor Subject: Re: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> To: "'ietf-ltans@imc.org'" Message-id: <4170A0F4.7030801@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 References: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Seems to me, the list is struggling with two different issues: 1) the protocols and standards associated with verifying the authenticity of a document over very long periods; and 2) the potential use of such technology to maintain the legal validity of documents that were presumably electronically notarized by human notaries. I believe it is possible for the WG to achieve #1 without being concerned about #2. If specific business groups (Notaries) wish to create legal bindings around the technical protocols, so be it. The technical standards should support that outcome without being concerned about what human notaries do - value-added integrators, software & hardware vendors will worry about that using the standards & protocols established by this WG. Since legitimate businesses - even outside the notarial areas - will have use for such technology, it behooves this group to maintain focus on #1 without being concerned about #2. I would recommend the use of something along the lines of "Long-term Data Validation Protocol" to remain industry-neutral. Arshad Noor StrongAuth, Inc. Richard Hansberger wrote: > Respectfully, I'll disagree with the determination that "notary service" is > an appropriate term. Here in the states, we went through a similar debate > when major CAs and others offered "digital notary services" in the wake of > passage of the Federal "E-Sign" Act. Personally, I think it had a > detrimental effect overall and all these "services" have since closed up > shop or been renamed, but that's just my opinion. > > What Notaries do, in other words, has little to do with the certification > that a document is a true and original copy. Notaries witness signings, take > oaths and affirmations, and perform other in-person kinds of functions. I > guess I'm just sensitive to the appropriation of the word as an adjective. > Notary is a noun;-) > > Regardless, if the majority feels it is appropriate then I'll oblige and say > no more. > > Thanks, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FIqm6q032946; Fri, 15 Oct 2004 11:52:48 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FIqmeQ032945; Fri, 15 Oct 2004 11:52:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FIqhbQ032915 for ; Fri, 15 Oct 2004 11:52:43 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W9FJ2G4F00000980; Fri, 15 Oct 2004 11:52:04 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <48NKMTN5>; Fri, 15 Oct 2004 11:52:08 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368D2C2@Louise2> From: Richard Hansberger To: "'Tobias Gondrom'" , "'Carl Wallace'" , "'Larry Masinter'" Cc: "'ietf-ltans@imc.org'" Subject: RE: Notary services requirements -- directions? Date: Fri, 15 Oct 2004 11:52:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 78da53b36e0a1dbb172d7c3334a0c957 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Respectfully, I'll disagree with the determination that "notary service" is an appropriate term. Here in the states, we went through a similar debate when major CAs and others offered "digital notary services" in the wake of passage of the Federal "E-Sign" Act. Personally, I think it had a detrimental effect overall and all these "services" have since closed up shop or been renamed, but that's just my opinion. What Notaries do, in other words, has little to do with the certification that a document is a true and original copy. Notaries witness signings, take oaths and affirmations, and perform other in-person kinds of functions. I guess I'm just sensitive to the appropriation of the word as an adjective. Notary is a noun;-) Regardless, if the majority feels it is appropriate then I'll oblige and say no more. Thanks, Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Tobias Gondrom [mailto:tobias@ixos.de] Sent: Friday, October 15, 2004 8:20 AM To: Carl Wallace; Larry Masinter Cc: ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > > From: Larry Masinter [mailto:LMM@acm.org] > > Sent: Tuesday, October 12, 2004 7:25 PM > > Subject: RE: Notary services requirements -- directions? > > > > Personally, I don't think we get into too much trouble using > > the word 'Notary' in the title of the working group or even > > in the title of a document here and there, as long as we're > > clear -- after all, it's a term that's been used already in > > the industry, and we're not particularly offering those > > services for sale, in any case. > > I don't mind the title either. I also agree. I can understand possible problems when a company sells a notary service and is not allowed to, but this is neither the case with the name of the WG or the Name of the requirements - basically I like to call the things by the best fitting name if I find one at all... ;-) So I see no problem calling a document requirements for notary services, e.g. > > > I think the requirements document might note that the term > > may have restricted use in some legal jurisdictions, and I > > think it is reasonable to add some wording to that effect. Full ACK, although I wouldn't add too much - there will always be one place in the world where some wording might cause legal conflicts and it is always up to the companies to resolve these conflicts when the implement things and sell products to local customers. > > Are time-stamping services associated with unsigned data out > > of scope, because they're already covered? > > I'm not sure what you mean out of scope. If you mean outside the scope > for > new specification work, I think so. If you mean outside the scope of what > we may refer to as a notary service, I don't think so. Timestamping seems > like a fundamental component. We've explicitly included support for > unsigned data in the archive discussion and since those have so far been > discussed pretty much solely in terms timestamp solutions, I think this is > in scope (if already covered elsewhere). > > > Are combined archive-and-certification services (which > > archive data and also provide for the certification of the > > data archived) out of scope? > > I think this combination is very much in scope. It seems natural for the > data certification service we define to be capable of verifying the > structures defined for long-term archive purposes. For some purposes, > this > combination may be invest too much trust in a single entity. For other > purposes, it seems like the ideal pairing (e.g. a binding that verified > the > evidence record upon data retrieval). I also agree with Carl - this is a possible but not necessary combination. Tobias ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FGKhk9010201; Fri, 15 Oct 2004 09:20:43 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FGKg4f010200; Fri, 15 Oct 2004 09:20:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (HOST.31.98.ixos.de [149.235.31.98]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FGKfPk010190 for ; Fri, 15 Oct 2004 09:20:41 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id i9FGKXRX019954; Fri, 15 Oct 2004 18:20:34 +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: Notary services requirements -- directions? Date: Fri, 15 Oct 2004 18:20:26 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B07049D74E@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notary services requirements -- directions? Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnAAAFwFIACH0DhQ From: "Tobias Gondrom" To: "Carl Wallace" , "Larry Masinter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9FGKgPk010195 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > From: Larry Masinter [mailto:LMM@acm.org] > > Sent: Tuesday, October 12, 2004 7:25 PM > > Subject: RE: Notary services requirements -- directions? > > > > Personally, I don't think we get into too much trouble using > > the word 'Notary' in the title of the working group or even > > in the title of a document here and there, as long as we're > > clear -- after all, it's a term that's been used already in > > the industry, and we're not particularly offering those > > services for sale, in any case. > > I don't mind the title either. I also agree. I can understand possible problems when a company sells a notary service and is not allowed to, but this is neither the case with the name of the WG or the Name of the requirements - basically I like to call the things by the best fitting name if I find one at all... ;-) So I see no problem calling a document requirements for notary services, e.g. > > > I think the requirements document might note that the term > > may have restricted use in some legal jurisdictions, and I > > think it is reasonable to add some wording to that effect. Full ACK, although I wouldn't add too much - there will always be one place in the world where some wording might cause legal conflicts and it is always up to the companies to resolve these conflicts when the implement things and sell products to local customers. > > Are time-stamping services associated with unsigned data out > > of scope, because they're already covered? > > I'm not sure what you mean out of scope. If you mean outside the scope > for > new specification work, I think so. If you mean outside the scope of what > we may refer to as a notary service, I don't think so. Timestamping seems > like a fundamental component. We've explicitly included support for > unsigned data in the archive discussion and since those have so far been > discussed pretty much solely in terms timestamp solutions, I think this is > in scope (if already covered elsewhere). > > > Are combined archive-and-certification services (which > > archive data and also provide for the certification of the > > data archived) out of scope? > > I think this combination is very much in scope. It seems natural for the > data certification service we define to be capable of verifying the > structures defined for long-term archive purposes. For some purposes, > this > combination may be invest too much trust in a single entity. For other > purposes, it seems like the ideal pairing (e.g. a binding that verified > the > evidence record upon data retrieval). I also agree with Carl - this is a possible but not necessary combination. Tobias Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FADCgt058302; Fri, 15 Oct 2004 03:13:12 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9FADCSI058301; Fri, 15 Oct 2004 03:13:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9FAD8DE058275 for ; Fri, 15 Oct 2004 03:13:11 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9FAD9N07623; Fri, 15 Oct 2004 12:13:09 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 15 Oct 2004 12:13:09 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9FAD8E13467; Fri, 15 Oct 2004 12:13:08 +0200 (MEST) Date: Fri, 15 Oct 2004 12:13:08 +0200 (MEST) From: Peter Sylvester Message-Id: <200410151013.i9FAD8E13467@chandon.edelweb.fr> To: Peter.Sylvester@edelweb.fr, cwallace@orionsec.com Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Is there an additional need to define means for > > representing notarial > > > acts performed by humans? > > > > > No. The best is to have the equivalent of a framework paper > > that has a free form text place where the nature of the > > notarial act and anything else can be noted. > > > > These elements are not subject to automatic treatment by our > > core protocol > > > > it may be useful to more than "free' text, i.e. some schema > > or oid based document piece like for soap content or CMS > > content types, in order to allow plugin logic do additional > > work for semantic validation in a correct way. > > Seems like part of you says "No" and another part says "Yes":-) A schema, > or some such, might be a useful parallel to the signature formats, bindings > and certification protocol. It seems to me that your question has two aspects: - The content to be notarized - The notarization (envelope) I am just saying that we probably would not go further down that having a common envelope for some 'ANY DEFINED BY' (to use some obsolete terminology), a 'signature format' if one prefers this term. it looks like we have a similarity with the problem of archive transformation and metadata, i.e., the extent to which an archiver has knowledge about the relationship of 'outer' metadata and some 'inner' structure of the data. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EI2Zlx030729; Thu, 14 Oct 2004 11:02:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EI2ZhH030728; Thu, 14 Oct 2004 11:02:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EI2YTJ030722 for ; Thu, 14 Oct 2004 11:02:34 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (97.sub-166-180-59.myvzw.com [166.180.59.97]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9EI2Xfn027935; Thu, 14 Oct 2004 14:02:34 -0400 Message-Id: <200410141802.i9EI2Xfn027935@host13.websitesource.com> From: "Carl Wallace" To: "'Peter Sylvester'" , Subject: RE: Notary services requirements -- directions? Date: Thu, 14 Oct 2004 14:02:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200410141700.i9EH0KS10805@chandon.edelweb.fr> Thread-Index: AcSyEOOLPoyriYt8SMauU+iDWoljrwABe5jg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Is there an additional need to define means for > representing notarial > > acts performed by humans? > > > No. The best is to have the equivalent of a framework paper > that has a free form text place where the nature of the > notarial act and anything else can be noted. > > These elements are not subject to automatic treatment by our > core protocol > > it may be useful to more than "free' text, i.e. some schema > or oid based document piece like for soap content or CMS > content types, in order to allow plugin logic do additional > work for semantic validation in a correct way. Seems like part of you says "No" and another part says "Yes":-) A schema, or some such, might be a useful parallel to the signature formats, bindings and certification protocol. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EH0OCV020187; Thu, 14 Oct 2004 10:00:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EH0OiL020186; Thu, 14 Oct 2004 10:00:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EH0KJQ020166 for ; Thu, 14 Oct 2004 10:00:23 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9EH0KN26694; Thu, 14 Oct 2004 19:00:20 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 14 Oct 2004 19:00:20 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9EH0KS10805; Thu, 14 Oct 2004 19:00:20 +0200 (MEST) Date: Thu, 14 Oct 2004 19:00:20 +0200 (MEST) From: Peter Sylvester Message-Id: <200410141700.i9EH0KS10805@chandon.edelweb.fr> To: ietf-ltans@imc.org, cwallace@orionsec.com Subject: RE: Notary services requirements -- directions? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Is there an additional need to define means for representing notarial acts > performed by humans? > No. The best is to have the equivalent of a framework paper that has a free form text place where the nature of the notarial act and anything else can be noted. These elements are not subject to automatic treatment by our core protocol it may be useful to more than "free' text, i.e. some schema or oid based document piece like for soap content or CMS content types, in order to allow plugin logic do additional work for semantic validation in a correct way. This represents 'go to office number 1234 and obtains forms type XA-856b ...' :-) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBR6Ol067890; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9EBR6b2067889; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9EBR547067843 for ; Thu, 14 Oct 2004 04:27:06 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9EBQsN21858; Thu, 14 Oct 2004 13:26:54 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 14 Oct 2004 13:26:54 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9EBQs109572; Thu, 14 Oct 2004 13:26:54 +0200 (MEST) Date: Thu, 14 Oct 2004 13:26:54 +0200 (MEST) From: Peter Sylvester Message-Id: <200410141126.i9EBQs109572@chandon.edelweb.fr> To: LMM@acm.org Subject: RE: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > Personally, I don't think we get into too much trouble > using the word 'Notary' in the title of the working group > or even in the title of a document here and there, as long > as we're clear -- after all, it's a term that's been used > already in the industry, and we're not particularly offering > those services for sale, in any case. I tend to agree. > > I think the requirements document might note that the > term may have restricted use in some legal jurisdictions, > and I think it is reasonable to add some wording to that effect. Would someone mind writing down a small paragraph that could explain the issue, i.e., resume the last exchange of messages, so we have something to be put into the RFCs but also I can add this in a kind of disclaimer section in the web server in order to avoid that in a few months new participants ... > > Are time-stamping services associated with unsigned > data out of scope, because they're already covered? - Time stamping of signed data, i.e. digital signature is also already covered by existing proposals. - I think we have several questions to clarify, like - what are "our" requirements of the stability of time stamps, i.e., currently they are at best the 'lifetime' of a hash function. - what means does archiving provide (or not), to cover long term, e.g., if I just have to archive invoices for about three months, i can live withe short term time stamping. (to be a litle bit provocative, current time stamps are not good for long term IMO, since they were never intended as such) > Are combined archive-and-certification services > (which archive data and also provide for the certification > of the data archived) out of scope? - If we make it right, then we have just a combination of three quarks: Notarisation (voluntarily written with an s), Archiving, and Evidence creation/recording to do this. Or, in other words, it is a particular use case of a combination of basic techniques. - The role of such a notary can just be "I perform the archiving, and certify that the "reference" returned from the archive. Whether one consider this minimal notarisation as a front end client related service of the archive or as an independant service, seems to me an organisational matter, or, in other words, it depends on the client needs. - There may be a lot of cases where the information (the references) provided by the archiver does not need to be "secured" at lot when given to the client. That's why I think it is important to clearly distinguish between (more or less real time) security measures and the payload. - As far as I have understood from discussions with notaries there is some particular kind of archive+notary application which is based on the observation that notaries (at least in some places) perform some information reduction, for example, a 'signature validation' can be done in such a way that the notary collects all the validation data, performs the validation, time stamps all that, archives them, but just delivers a statement that everything is of+the refereces to the archive. in fact, the archived data correspond to his activity log. This is somehow the exact opposite operation of what is provided by some profile of DVCS or by SCVP, where the validation data are returned by a service. Again, an information reducing notary would be able to ask an information collecting service (+ a validator) to provide the information, then all this can be archived, and a 'reduced' result produced. If one looks at such use cases as molecules, I wonder where are our atoms. Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNZGaJ087104; Tue, 12 Oct 2004 16:35:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CNZG6A087103; Tue, 12 Oct 2004 16:35:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNZFwE087096 for ; Tue, 12 Oct 2004 16:35:15 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace ([70.21.11.69]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9CNZQ88015582; Tue, 12 Oct 2004 19:35:26 -0400 Message-Id: <200410122335.i9CNZQ88015582@host13.websitesource.com> From: "Carl Wallace" To: "'Larry Masinter'" Cc: Subject: RE: Notary services requirements -- directions? Date: Tue, 12 Oct 2004 19:35:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnAAAFwFIA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <0I5H009DMVPPWA@mailsj-v1.corp.adobe.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Tuesday, October 12, 2004 7:25 PM > Subject: RE: Notary services requirements -- directions? > > Personally, I don't think we get into too much trouble using > the word 'Notary' in the title of the working group or even > in the title of a document here and there, as long as we're > clear -- after all, it's a term that's been used already in > the industry, and we're not particularly offering those > services for sale, in any case. I don't mind the title either. > I think the requirements document might note that the term > may have restricted use in some legal jurisdictions, and I > think it is reasonable to add some wording to that effect. > > Are time-stamping services associated with unsigned data out > of scope, because they're already covered? I'm not sure what you mean out of scope. If you mean outside the scope for new specification work, I think so. If you mean outside the scope of what we may refer to as a notary service, I don't think so. Timestamping seems like a fundamental component. We've explicitly included support for unsigned data in the archive discussion and since those have so far been discussed pretty much solely in terms timestamp solutions, I think this is in scope (if already covered elsewhere). > Are combined archive-and-certification services (which > archive data and also provide for the certification of the > data archived) out of scope? I think this combination is very much in scope. It seems natural for the data certification service we define to be capable of verifying the structures defined for long-term archive purposes. For some purposes, this combination may be invest too much trust in a single entity. For other purposes, it seems like the ideal pairing (e.g. a binding that verified the evidence record upon data retrieval). > > Larry > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CNP8qV086652; Tue, 12 Oct 2004 16:25:08 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CNP8xs086651; Tue, 12 Oct 2004 16:25:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9CNP7ma086645 for ; Tue, 12 Oct 2004 16:25:07 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Tue, 12 Oct 2004 16:25:02 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i9CNP2bA000539; Tue, 12 Oct 2004 16:25:07 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9CNP10S024290; Tue, 12 Oct 2004 16:25:02 -0700 (PDT) Received: from MasinterT40 (c-130-169.corp.adobe.com [153.32.130.169]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5H009DLVPPWA@mailsj-v1.corp.adobe.com>; Tue, 12 Oct 2004 16:25:01 -0700 (PDT) Date: Tue, 12 Oct 2004 16:25:01 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410121651.i9CGpZ88027346@host13.websitesource.com> To: "'Carl Wallace'" Cc: ietf-ltans@imc.org Message-id: <0I5H009DMVPPWA@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXAAA48qnA= Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Personally, I don't think we get into too much trouble using the word 'Notary' in the title of the working group or even in the title of a document here and there, as long as we're clear -- after all, it's a term that's been used already in the industry, and we're not particularly offering those services for sale, in any case. I think the requirements document might note that the term may have restricted use in some legal jurisdictions, and I think it is reasonable to add some wording to that effect. Are time-stamping services associated with unsigned data out of scope, because they're already covered? Are combined archive-and-certification services (which archive data and also provide for the certification of the data archived) out of scope? Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CGpXxY054198; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CGpXI0054197; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CGpXV0054190 for ; Tue, 12 Oct 2004 09:51:33 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (pool-70-18-234-230.res.east.verizon.net [70.18.234.230]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i9CGpZ88027346 for ; Tue, 12 Oct 2004 12:51:36 -0400 Message-Id: <200410121651.i9CGpZ88027346@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Notary services requirements -- directions? Date: Tue, 12 Oct 2004 12:51:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSwb/RQAbq7qcBCRMuLHnnppx7f7QACIGXA In-Reply-To: <200410121514.i9CFEGs01737@chandon.edelweb.fr> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > But, well, before making a title, it seems to me that we may > first come to an agreement about *what* protocol we are > doing, i.e., the ones between machines that 'certify' > something, my view: > > - act as a more or less automatic tool to perform some defined > validation activity > - a to 'certify' the result, i.e. authenticating the data. > - used in workflows. > > Note that protocol is meant in a large sense, not just the > 'access protocol', there are components for auditable > operational requirements, i.e. a service must play the game > in the right way, and cannot just pretend to do something. It seems like we are settling on a few avenues (with existing protocol correlations in parentheses): - long-term signature formats (e.g. ERS) - long-term signature format protocols (e.g. machine-to-machine a la WebDAV or DVCS variant) - server-based data certification protocols (e.g. machine-to-machine a la DVCS) Is there an additional need to define means for representing notarial acts performed by humans? Has anyone been following the OASIS work that was discussed during the San Diego meeting? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFECfS042255; Tue, 12 Oct 2004 08:14:12 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9CFECnm042254; Tue, 12 Oct 2004 08:14:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9CFE9h0042245 for ; Tue, 12 Oct 2004 08:14:10 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9CFEHN21500; Tue, 12 Oct 2004 17:14:17 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 12 Oct 2004 17:14:17 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9CFEGs01737; Tue, 12 Oct 2004 17:14:16 +0200 (MEST) Date: Tue, 12 Oct 2004 17:14:16 +0200 (MEST) From: Peter Sylvester Message-Id: <200410121514.i9CFEGs01737@chandon.edelweb.fr> To: Andreas.U.Schmidt@sit.fraunhofer.de, Denis.Pinkas@bull.net, rhansberger@nationalnotary.org Subject: RE: Notary services requirements -- directions? Cc: LMM@acm.org, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Merriam-Webster is sometimes helpful: 'notarization' = 1. the act, process, or an instance of notarising. 2. the notarial certificate appended to a document. 'notarize' = to acknowledge or attest as notary public. 'notarial' = 1. of relating to, or characteristic of a notary public 2. donce or executed by a notary public. 'notary public' = a public officer who attests or certifies writings (as a deed) to make them authentic, and takes affidavits, depositions, and protests of negotiable paper. It seems that indeed the words notarXXX are heavily connected to one profession, and, as I conclude from this discussion, notaries don't like someone else playing in their garden. :-) So be it. :-) (As far as I understand from French dictionaries, the words notarisation or notariser seem not to exist in French. I haven't contacted the Acedemy Francaise. It was (maybe) a mistake (of mime?) to have the word in the name of the working group. How can we (escape from)/remedy this situation? We could add a remark "the term is a French word". But, well, before making a title, it seems to me that we may first come to an agreement about *what* protocol we are doing, i.e., the ones between machines that 'certify' something, my view: - act as a more or less automatic tool to perform some defined validation activity - a to 'certify' the result, i.e. authenticating the data. - used in workflows. Note that protocol is meant in a large sense, not just the 'access protocol', there are components for auditable operational requirements, i.e. a service must play the game in the right way, and cannot just pretend to do something. Is it that what we are talking about? It seems that this is what Larry was proposing? Since more than 15 years or 20, we call some beasts 'certification authority', and not 'e-certification authority', I am not sure whether the remark 'clumsy' is related to the prefix 'e-' or to 'e-certification' as a buzzword. "Protocol requirements for (data?) certification services" seems another possibilities, also long and maybe 'clumsy', too. ("Data" in order to avoid a confusion with public key certification) I hope not having added too much confusion to the discussion. Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C1a24e061025; Mon, 11 Oct 2004 18:36:02 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9C1a28j061024; Mon, 11 Oct 2004 18:36:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9C1a0x9060992 for ; Mon, 11 Oct 2004 18:36:00 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W9C21Y7N00000A0C; Mon, 11 Oct 2004 18:34:43 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <43VFDB87>; Mon, 11 Oct 2004 18:35:16 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368D14B@Louise2> From: Richard Hansberger To: Andreas.U.Schmidt@sit.fraunhofer.de, Denis Pinkas Cc: Larry Masinter , ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Date: Mon, 11 Oct 2004 18:35:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: fecfb005fa4fbfdc258e42ee1683c84b Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Andreas, The term "Electronic Notary" is perhaps a bit awkward for US Notaries. It might work well in other countries, but in the U.S. we have model legislation that regulates the "Electronic Notary," which a number of states have adopted already. Thus, I could see confusion resulting from this service. "eCertification Services" or "e-certification service" isn't all that clumsy and is, in fact, more acceptable to US Notaries. In the US, we have long recognized that the certification services human Notaries now provide will gradually be replaced by machine services that provide better certification guarantees. Notaries witness; machines certify. It makes sense to me. Rich Hansberger National Notary Association -----Original Message----- From: Andreas U. Schmidt [mailto:Andreas.U.Schmidt@sit.fraunhofer.de] Sent: Friday, October 08, 2004 2:25 AM To: Denis Pinkas Cc: Larry Masinter; ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? Denis, certain examples in the form of scenarios and use-cases are necessary *in the beginning* of this requirements document to delineate the scope, clarify the subject, and provide rationales for the requirements proper. What we have now, including two suggestions I posted earlier on, could already be sufficient if we make good use of RFC3029 as a secondary reference. "e-Certification Serivces" to me seems overly clumsy - reading that title one might wonder what such a thing might do *more* than a CA or a Timestamping Service. At the moment I cannot think of a solid name which avoids the conflicts with the legal domain of notaries public, and still has some impact. How about "Electronic Notary (e-Notary) Services". Still I think we should keep some relation to the title of the WG and not make an ad hoc change which might then persist. With regard to the abstract I would like to stick to Larry's last proposal. AUS Denis Pinkas wrote: > > Larry, > >> I was unaware of RFC 3029. Should we add a reference to >> RFC 3029 as an example of what is intended in the requirements >> document? > > > A requirements document should not simply be a collection of examples. > Examples can certainly be mentionned in informative annexes, but the > core document would still need to say what needs to be supported. > > RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 > would certainly makes sense once we have define the document filling > the requirements (which still need to be defined). RFC 3029 contains > solutions to many problems, but it is not a requirements document. > > Besides the vocabulary problem about the use of the term "notary", we > would have first to define what would be the title and the topic of > the requirements document. I would propose something along the > following strawman proposal: > > "e-Certification Services requirements > > Abstract > > This document defines the requirements for e-Certification services. > Such services may be used when there is a need to register one or many > documents and to certify that these documents have been duly > semantically verified by a given person prior to registration. These > persons may or may not be Notaries, as understood by Civil Law or > Common Law. The document to be certified may or may not contain > electronic signatures from other persons." > > Denis > >> Would it be reasonable to rename the document: >> >> Data Validation and Certification Protocol Requirements >> >> and replace 'Notary' with 'Data Validation or >> Certification Service' as appropriate? >> >> RFC 3029 contains a few uses of the word 'notary', but >> only in descriptions of patents and relationship to >> prior work. >> >> Larry > > > > ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BAL6Hr064756; Mon, 11 Oct 2004 03:21:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9BAL6jw064755; Mon, 11 Oct 2004 03:21:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9BAL4w4064739 for ; Mon, 11 Oct 2004 03:21:05 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9BAL4N25814 for ; Mon, 11 Oct 2004 12:21:04 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 11 Oct 2004 12:21:04 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9BAL4p26805 for ietf-ltans@imc.org; Mon, 11 Oct 2004 12:21:04 +0200 (MEST) Date: Mon, 11 Oct 2004 12:21:04 +0200 (MEST) From: Peter Sylvester Message-Id: <200410111021.i9BAL4p26805@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: draft-ietf-ltans-reqs-02.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have some comments to the "archive service requirements": > Abstract > In many scenarios, users need to be able to prove the existence of > data at a given time and integrity of data, especially digitally > signed data, in a common and reproducible way after an arbitrarily > long period. This document specifies the technical requirements for > a long-term archive service to support such scenarios. Somehow I'd like to see the word "protocol" here. "after an arbitrarily long" is a pretty arbitary term avoid to say nothing precise :-) it seems slightly misleading since we forget that some data MUST be destroyed after a defined time in certain scenarious. This could be explained later in the use cases which could benefit from some important case of let's say a telephone company or an ISP who has to safely store connection data for a definitely limited time, ot certified accountants, "exterts compatbles" "Steuerberater" who must store their raw data for some years but not eternally. Thus the following: > Deletion requests must be authorized and an authorization policy must > be defined and observed by the long-term archive service (as part of > an archive policy). In some cases, deletion may not involve physical > deletion and instead may simply be an early termination of the > archivation period. is somewhat the contrary of what I'd say: Shortening of an archiving period seems to me rather exceptional, but extension must be ensured in case of a conflict between the involved parties. Extension may have some influence of how data can be deleted on some media, if one stores all data of one months for all customers of a telephone company, then not deleting data of one customer may involve that no data are deleted. Such a situation seems bad to me. The requirement should be IMO that when an extension of an archiving period occurs, the archiver service should implement a technique that limits the need of extending other data. Reading Larry's comment, I think defining a good abstract may come in a yoyo technique following the actual texts. I stop here, since I prefer that we first "digest" Denis and Larry's comments in some way. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AGNdIv076863; Sun, 10 Oct 2004 09:23:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9AGNdld076862; Sun, 10 Oct 2004 09:23:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9AGNZah076851 for ; Sun, 10 Oct 2004 09:23:36 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i9AGNbN15545; Sun, 10 Oct 2004 18:23:37 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 10 Oct 2004 18:23:37 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i9AGNZ624626; Sun, 10 Oct 2004 18:23:35 +0200 (MEST) Date: Sun, 10 Oct 2004 18:23:35 +0200 (MEST) From: Peter Sylvester Message-Id: <200410101623.i9AGNZ624626@chandon.edelweb.fr> To: LMM@acm.org, Denis.Pinkas@bull.net Subject: Re: Notary services requirements -- directions? Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Abstract > > This document defines the requirements for e-Certification services. Such > services may be used when there is a need to register one or many documents > and to certify that these documents have been duly semantically verified by > a given person prior to registration. These persons may or may not be > Notaries, as understood by Civil Law or Common Law. The document to be > certified may or may not contain electronic signatures from other persons." > Independant of the usage of the word "e-certification service" I am not sure that the description is what we have in mind as services to be supported by a protocol. What is meant by 'registration'? My understanding was that we can access to a service that performs certain aspects of a semantical verification, and does not only rely on a person doing this, or else, what is proposed looks to me as a front end to an archiving system (which may still be one of the use cases). At best, the title is one possible use case IMO. But I may be wrong. Futhermore, it doesn't seem to me that we have agreement about whether we talk about requirements for a protocol or for a service. To me we arec talking about protocol requirements, i.e. by what means can we access to the services and the functions it provides, and what information we can submit or and what do we obtain. Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98DfZji037894; Fri, 8 Oct 2004 06:41:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i98DfZnO037893; Fri, 8 Oct 2004 06:41:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i98DfYhL037871 for ; Fri, 8 Oct 2004 06:41:34 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i98DfSN22607 for ; Fri, 8 Oct 2004 15:41:28 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 8 Oct 2004 15:41:28 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i98DfSq19213 for ietf-ltans@imc.org; Fri, 8 Oct 2004 15:41:28 +0200 (MEST) Date: Fri, 8 Oct 2004 15:41:28 +0200 (MEST) From: Peter Sylvester Message-Id: <200410081341.i98DfSq19213@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I was unaware of RFC 3029. Something maybe worth to read from the PKIX list almost 4 years ago explaining the status of DVCS = RFC3029 At that time I was tempted to simplify the services in DVCS and to combine the validation of of signed data and certificates into some common thing, i.e., to perform some validation on some document whose structure and semantics are known, and for which a validation procedure is defined. Even with 3029 one has already some bricks of such procedures, one for signed documents, one for attestations itself, several for public key certs where one can distinguish between signature and encryption, etc., ... Furthermore, the validation algorithm itself may include that external services are required, e.g., to archive each "document" and obtain the attestations from someone else. It is not clear (to me) whether such procedures need to implemented as code or as more or less complicated parameters to some generic algorithm. I wonder whether such a technical system is somethig we are looking for as an 'functional architecture of a technical system to support activities of notaries and others' Peter ---- From: Carlisle Adams To: "'kent@bbn.com'" , "'wpolk@nist.gov'" Cc: ietf-pkix@imc.org Subject: The future of DVCS... Date: Wed, 11 Oct 2000 15:40:25 -0400 Hi, Over the past year or more, the question has arisen in various contexts as to the status and role of the DVCS draft, especially with respect to TSP, OCSP, SCVP, DPV, DPD, and whatever other variations might be incarnated in the future. DVCS precedes and, at some level, encompasses all of these other protocols. However, these protocols -- many of them targeted for the standards track -- have been defined for the twin purposes of simplicity and rapid implementation. They are small and clearly defined; each one tries to solve essentially one problem. DVCS, on the other hand, is intended to be general, embracing the sometimes abstract notion of the validation and certification of arbitrary data. The actual content of the data (the payload) in a sense defines the function of the server (i.e., if the data is a hash of something, then the server is providing a time stamp function; if the data is a certificate, then the server is providing an OCSP or SCVP/DPV function; if the data is a contract or legal document, then the server is providing what (at least in North America) might be called a notarization function; etc.). It's not quite as loose as that, but that's the basic idea. In discussing this protocol with the other authors and with various members of the community, I sense "rough consensus" on two things. Firstly, it makes sense to allow the more clearly-defined subsets of the DVCS functionality to be handled by these other protocols (TSP, OCSP, etc.) since they are relatively well-understood and implementations are already either completed or underway. Secondly, most real-world environments are not yet ready to incorporate notarization functions for other data formats. This higher-layer purpose of DVCS is perhaps too early as a concept to engage serious review and debate within the wider PKIX group right now. Consequently, the authors of DVCS are recommending to the chairs that this specification be preserved as an Experimental RFC. It has received some discussion (both public and private) over the years, but probably not sufficient to warrant progression along the standards track. Furthermore, we are aware of only a single implementation at this time, so any interoperability testing is out of the question, at least at the moment. But enough work has gone into this protocol that letting it expire as an Internet Draft and disappear completely seems inappropriate, especially if (as we suspect) this higher-layer functionality will begin to be required in PKI environments in the one- to three-year time frame. We would like to see the specification frozen and preserved for now; it can always be re-visited later (and even re-targeted for the standards track) if the need arises. In light of this recommendation, further revisions to this document seem unnecessary; the authors are satisfied with the text in this -07 version going to "Experimental" status. Steve, Tim: any comments or alternate suggestions? Carlisle. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i989PjEe090841; Fri, 8 Oct 2004 02:25:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i989PjwS090839; Fri, 8 Oct 2004 02:25:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i989Phss090739 for ; Fri, 8 Oct 2004 02:25:44 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id LAA08029; Fri, 8 Oct 2004 11:24:43 +0200 (MET DST) Message-ID: <41665CDA.9080502@sit.fraunhofer.de> Date: Fri, 08 Oct 2004 11:24:42 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: Denis Pinkas CC: Larry Masinter , ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? References: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> <416652E3.3070900@bull.net> In-Reply-To: <416652E3.3070900@bull.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: Denis, certain examples in the form of scenarios and use-cases are necessary *in the beginning* of this requirements document to delineate the scope, clarify the subject, and provide rationales for the requirements proper. What we have now, including two suggestions I posted earlier on, could already be sufficient if we make good use of RFC3029 as a secondary reference. "e-Certification Serivces" to me seems overly clumsy - reading that title one might wonder what such a thing might do *more* than a CA or a Timestamping Service. At the moment I cannot think of a solid name which avoids the conflicts with the legal domain of notaries public, and still has some impact. How about "Electronic Notary (e-Notary) Services". Still I think we should keep some relation to the title of the WG and not make an ad hoc change which might then persist. With regard to the abstract I would like to stick to Larry's last proposal. AUS Denis Pinkas wrote: > > Larry, > >> I was unaware of RFC 3029. Should we add a reference to >> RFC 3029 as an example of what is intended in the requirements >> document? > > > A requirements document should not simply be a collection of examples. > Examples can certainly be mentionned in informative annexes, but the > core document would still need to say what needs to be supported. > > RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 > would certainly makes sense once we have define the document filling > the requirements (which still need to be defined). RFC 3029 contains > solutions to many problems, but it is not a requirements document. > > Besides the vocabulary problem about the use of the term "notary", we > would have first to define what would be the title and the topic of > the requirements document. I would propose something along the > following strawman proposal: > > "e-Certification Services requirements > > Abstract > > This document defines the requirements for e-Certification services. > Such services may be used when there is a need to register one or many > documents and to certify that these documents have been duly > semantically verified by a given person prior to registration. These > persons may or may not be Notaries, as understood by Civil Law or > Common Law. The document to be certified may or may not contain > electronic signatures from other persons." > > Denis > >> Would it be reasonable to rename the document: >> >> Data Validation and Certification Protocol Requirements >> >> and replace 'Notary' with 'Data Validation or >> Certification Service' as appropriate? >> >> RFC 3029 contains a few uses of the word 'notary', but >> only in descriptions of patents and relationship to >> prior work. >> >> Larry > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i988hplw073375; Fri, 8 Oct 2004 01:43:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i988hp8e073373; Fri, 8 Oct 2004 01:43:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i988hlW8073321 for ; Fri, 8 Oct 2004 01:43:49 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA13760; Fri, 8 Oct 2004 10:55:07 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100810433444:401 ; Fri, 8 Oct 2004 10:43:34 +0200 Message-ID: <416652E3.3070900@bull.net> Date: Fri, 08 Oct 2004 10:42:11 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Larry Masinter CC: ietf-ltans@imc.org Subject: Re: Notary services requirements -- directions? References: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/10/2004 10:43:34, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 08/10/2004 10:43:37, Serialize complete at 08/10/2004 10:43:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Larry, > I was unaware of RFC 3029. Should we add a reference to > RFC 3029 as an example of what is intended in the requirements > document? A requirements document should not simply be a collection of examples. Examples can certainly be mentionned in informative annexes, but the core document would still need to say what needs to be supported. RFC 3029 supports many use cases, maybe too many. A subset of RFC 3029 would certainly makes sense once we have define the document filling the requirements (which still need to be defined). RFC 3029 contains solutions to many problems, but it is not a requirements document. Besides the vocabulary problem about the use of the term "notary", we would have first to define what would be the title and the topic of the requirements document. I would propose something along the following strawman proposal: "e-Certification Services requirements Abstract This document defines the requirements for e-Certification services. Such services may be used when there is a need to register one or many documents and to certify that these documents have been duly semantically verified by a given person prior to registration. These persons may or may not be Notaries, as understood by Civil Law or Common Law. The document to be certified may or may not contain electronic signatures from other persons." Denis > Would it be reasonable to rename the document: > > Data Validation and Certification Protocol Requirements > > and replace 'Notary' with 'Data Validation or > Certification Service' as appropriate? > > RFC 3029 contains a few uses of the word 'notary', but > only in descriptions of patents and relationship to > prior work. > > Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i985VvY8073815; Thu, 7 Oct 2004 22:31:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i985VvVf073813; Thu, 7 Oct 2004 22:31:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i985VnS0073696 for ; Thu, 7 Oct 2004 22:31:49 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Thu, 07 Oct 2004 22:31:11 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i985UlbA017972; Thu, 7 Oct 2004 22:30:52 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i985UhTk012879; Thu, 7 Oct 2004 22:30:47 -0700 (PDT) Received: from MasinterT40 ([130.248.178.254]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5900M703B7AQ@mailsj-v1.corp.adobe.com>; Thu, 07 Oct 2004 22:30:43 -0700 (PDT) Date: Thu, 07 Oct 2004 22:30:42 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <200410051553.i95Frpl05845@chandon.edelweb.fr> To: "'Peter Sylvester'" , rhansberger@nationalnotary.org, Denis.Pinkas@bull.net Cc: ietf-ltans@imc.org Message-id: <0I5900M713B7AQ@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcSq84878hn3zaADSV6SifZKRlRSswCAxnjw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was unaware of RFC 3029. Should we add a reference to RFC 3029 as an example of what is intended in the requirements document? Would it be reasonable to rename the document: Data Validation and Certification Protocol Requirements and replace 'Notary' with 'Data Validation or Certification Service' as appropriate? RFC 3029 contains a few uses of the word 'notary', but only in descriptions of patents and relationship to prior work. Larry Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FTbRi067905; Wed, 6 Oct 2004 08:29:37 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96FTbeL067904; Wed, 6 Oct 2004 08:29:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96FTZS9067884 for ; Wed, 6 Oct 2004 08:29:36 -0700 (PDT) (envelope-from ulrich.pordesch@zv.fraunhofer.de) Received: from PCTOM (pc-tom [141.12.87.62]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id RAA14502; Wed, 6 Oct 2004 17:29:32 +0200 (MET DST) Message-Id: <200410061529.RAA14502@sonne.sit.fraunhofer.de> From: To: Cc: Subject: draft-ietf-ltans-reqs-02.txt: comments Date: Wed, 6 Oct 2004 17:33:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSrudDvWLcHn3xfRk2cUE90haXhBA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias At the moment I can not answer to all the comments from Denis in detail, as the comments are submitted quite shortly and although vehemently argued, but unfortunately in many cases missing arguments why such things are needed and what the benefit for specific use cases is. As far as I understand, Denis basically has two concerns most of his proposed changes are based on: 1. He wants a cryptographically secured proof of origin for the data, that can be used for an infinite time which user has submitted the data and to which archive provider the data has been submitted. Such a proof is not necessary for the named urging practical use cases as the conservation of evidence (value of proof) of signed documents, but would call for unnecessarily complex procedures/solutions. For the submitting entity itself a signed document that confirms that he has submitted the data is not usable for the long term, as the value of proof of such a signature will also loose its value because of the known and discussed reasons. Possibly some particular use cases exist, which require to be able to proof to a third party that data is from a specific person, as e.g. specific notary services for intellectual property or copy right questions. But those should be treated and solved separately. 2. Denis is introducing the term "Maintenance Policy", that should become a part of the Archive Policy. This term for a concept that has already been mentioned in the paper is ok, but I think the definition of parameters, the intermixture with Signature Policies and other proposals are problematic and should be discussed in detail. The requirements paper is not the right place to discuss this topic in detail. We can incorporate this term and some ideas, but should leave the specification of the details to a separate paper especially dedicated to this question. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvNLn037670; Tue, 5 Oct 2004 10:57:23 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvNk4037669; Tue, 5 Oct 2004 10:57:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvMC6037663 for ; Tue, 5 Oct 2004 10:57:22 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqn010708 for ; Tue, 5 Oct 2004 13:57:15 -0400 Message-Id: <200410051757.i95HvCqn010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Miscellaneous non-editorial comments Date: Tue, 5 Oct 2004 13:57:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBL5w2T/K6EDwQ8aGBD31Uw+wHw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This thread collects various non-editorial comments and provides some responses. > The document misses to indicate that it is necessary to demonstrate the origin of the data I don't think 'origin of data' is a service an LTA can provide. The best an LTA can do towards proof of origin is collection and preservation of materials required for source authentication and this can only occur in the 'active' mode of operation. Data handled in a 'passive' manner may contain sufficient information to authenticate a source of the data with the LTA having no knowledge of (or possibly even access to) that information. An LTA may operate such that it will only accept data for which a source can be authenticated. This provides an extra measure against LTA administrators altering data (by substituting timestamps for example). > # A long-term archive service may accept any type of data for > # preservation. The data might be in any format, whether textual > # data, images, documents, applications, or compound packages > # of multiple components. The data may be digitally > # signed, time-stamped, encrypted, or not subject to any > cryptographic > # processing. > > *** Is this a requirement that all of these be accepted, or > is this something where variability is allowed? What is the > general principle here? There is no requirement expressed w.r.t. the type of archived data an LTA must accept from a submitter. This will be clarified by introducing the listed possibilities as examples. The types of permissible data may be a policy component. > *** This sounds like you intent it to be disallowed for a > long-term archive service to provide any content-focused operations. > > Shouldn't this be 'is not required to operate upon' rather > than 'does not operate on'? > > In any case, even if it isn't the long-term archive service > doing the operating, I think it should be left open whether > the content-focused operations are performed by notary > services or, at least in part, by some other third-party service. > For example, there could be an (untrusted) > content-transformation service whose output would be > validated by a (trusted) notary service. So I suggest something like: > > # A long-term archive service is not required to operate upon > evidence # related to the content of archived data objects. > Content-focused operations, # including data format migration > or translation, may be performed by a # other services, e.g., > notary services. The intent was to preclude content-focused operations under the LTA banner, recognizing that related capabilities might operate on content (e.g. to verify signatures contained in the content or to translate the content in some way). The suggested text conveys the intent more accurately. If the end user experiences this as an LTA service (and it seems reasonable to expect that to be the case), perhaps this note should simply be deleted. Section 4 > **** May someone request the archivation period being > shortened but not immediately? (E.g., employee records are > usually kept 'for the length of employment plus N years', so > at employment termination, you might request shortening the > lifetime to N years.) Right now the only operations are > 'delete' and 'extend'. Archivation period shortening should be identified as a possible operation (and has been in the working copy of the draft). This introduces a new type of actor, e.g. modifier in addition to submitter/retriever. > Submitters should be able to specify metadata that, for > example, can be used to enable retrievers to render the data > correctly. > > I think this may be worthy of some amplification and clarification. > Do you mean explicitly content-type or other MIME-like headers? > > **** Usually the word 'metadata' is also associated with > indexing information (Title, Author, Date, etc.). Is that > kind of metadata for long-term archived data included? Is it > possible to search on metadata in the long-term archive? Or > is it explicitly excluded, required to be part of the > archived package or part of the archived data? Content type and MIME-like headers are certainly examples. Others might be specific to a particular system or application (e.g. classification code), general support for searching (e.g. keywords) or other generic information (e.g. contributors, title, author, date). It seems likely that an implementation would support searching on at least some of these. A question we ran into working on the (unpublished) protocol spec was whether or not there needed to be support for "archived" and "unarchived" metadata, i.e. like signed and unsigned CMS attributes. We should probably have a profile of such attributes for which support is required. Should ability to search on particular types of metadata be mandated? If metadata is not an appropriate term, attribute could be substituted. > ===================== > Following submission, the service must provide a value that can be > used to retrieve the archived data and/or associated evidence. It > may be possible to retrieve archive packages by using a > hash value of > an archived data object. > > **** Is this value a capability? Or does it also require > authorization? > Is the requirement that this retrieval handle be generated by the > submitter, the long-term archive service, or by both (when > it uses a hash value of the archived data object)? > > While I think using a hash value of an archived data object is > an interesting approach, I'm not sure why it's in the requirements. I'd viewed this as a server-generated value (even in cases where the client could predict the value beforehand, e.g. hash). A client could specify an identifier as a metadata/attribute value. I did not view possession of the value as authorization to perform any action related to the associated archived data object or evidence. > ======================= > The format for the acknowledgements must allow the > identification of > the archiving provider. > > **** Why is this optional? Is it the identification of the > operator of the LTA? Or of the LTA itself? The intent was LTA itself. The statement indicates that the formats must support specification of the LTA. > ======================= > The format for the acknowledgements must allow the > identification of > the participating client. > > **** I think this is a more substantial requirement, that the > submitting client must identify itself, and that identity may > (or must? or should?) be included in the acknowledgement? So submissions must be authenticated? Section 4.4 > It may be that this section has a part that is defining what > a Long-term archive service does (it operates according to a > policy), and that the requirements are not operational > requirements but interface requirements, e.g., providing > information identifying the policies. > > I'm not sure what 'in use at any point in time'. Are services > allowed to change their policies? Can you ask today 'what > were your policies 10 years ago'? It seems likely that services will have to change policies over time. Good question as to whether it should be possible to ask for policies in use at time X. It may be overkill to require an interface for this. Instead the formats must include a means of indicating the policy in use. Thus, the policies applied to a specific object at a particular point in time can be determined but not the policies in use at a particular time. > The policy may define characteristics > such as the quality of timestamps obtained or generated by the > long-term archive service or triggers for preservation activities, > e.g. timestamp refresh or data format migration. > > So we need to invent protocol elements for describing such > things? What is the measure of 'quality of time-stamp'? We need to determine what aspects of policy should be applied on a per document basis and/or what aspects should be controlled explicitly by a submitter. Protocol elements would be necessary for the latter, at least. The "quality of timestamp" phrase should be replaced by "characteristics of timestamps" (possibly to include duration, key size, specific TSA). > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I like the idea of distinguishing between data that is operated upon by an LTA and data that is not. However, these are modes of operation for an LTA w.r.t to an archived data object (i.e. an LTA could operate in a passive mode for some objects and an active mode for others). Passive v. active as applied to data evokes ongoing preservation activities, however. Opaque vs. transparent may be a suitable alternative. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvL3A037659; Tue, 5 Oct 2004 10:57:21 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvLco037658; Tue, 5 Oct 2004 10:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvKq0037652 for ; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqo010708 for ; Tue, 5 Oct 2004 13:57:18 -0400 Message-Id: <200410051757.i95HvCqo010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Abstract-related comments Date: Tue, 5 Oct 2004 13:57:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBMAzqIisDJ7RS36xOsSow+minw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We received two suggested rewrites of the abstract. Both are presented below along with the abstract from the -02 draft. As Larry suggested, it may be better to table the abstract and focus on the other issues for the moment. Larry suggested the following: # There are many scenarios in which users, even after an arbitrarily # long period of time, will need to prove the original existance of # data and the integrity of that data in the duration. In addition, # there are requirements to prove the original validity of the # signatures of digitally signed data, even after an arbitrarily # long period. This document describes a class of long-term archive # services which support such scenarios, and the technical requirements # for protocols for interacting with such services. Denis suggested the following: "This document specifies the technical requirement for long-term archive services able to support non repudiation of data origin with integrity and existence of data at a given time. Data to be stored and retrieved may include signed data. Long-term archive services operate under an archive policy which will need to be periodically redefined as the time goes. This document specifies the main constituents of an archive policy". -02 draft text: In many scenarios, users need to be able to prove the existence of data at a given time and integrity of data, especially digitally signed data, in a common and reproducible way after an arbitrarily long period. This document specifies the technical requirements for a long-term archive service to support such scenarios. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvKlT037650; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvK7D037649; Tue, 5 Oct 2004 10:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvJQN037641 for ; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqp010708 for ; Tue, 5 Oct 2004 13:57:21 -0400 Message-Id: <200410051757.i95HvCqp010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Archive policy-related comments Date: Tue, 5 Oct 2004 13:57:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBMK+Pp8YwvYQRYiRn1ml0QmNcw== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A number of comments on the -02 requirements draft relate to archive policy. This thread collects the policy-related questions/comments and offers an initial set of archive policy components and a few responses. 1) What are the primary components of an Archive Policy? - Based on the comments, a few candidate archive policy components based on the discussion are: types of data accepted by an LTA; types of data operated upon by an LTA and nature of that operation; access control policy; refresh operation triggers; types and characteristics of refresh mechanisms used. 2) Are archive policies enforced on a per document basis or per LTA basis? - It seems like there are some policy components that should be per document (e.g. archivation period) and others that are LTA-wide (e.g. TSA used to generate timestamps, 3) If archive policies are named, what is the namespace? 4) What components of an archive policy can be specified by a submitter (or modifier)? 5) Do different LTAs share named archive policies? - This seems like a likely scenario. 6) Cryptographic maintenance policies were described in detail (see below with responses). > "4.X Cryptographic maintenance > > 4.X.1 Functional requirements > > A long term archive service must maintain the cryptographic > validity of its evidence records. It needs to perform the > following > basic operations: > > - attach cryptographic maintenance parameters to one or a set > of archived packages, > > - apply the cryptographic maintenance policy referenced within > the cryptographic maintenance parameters to maintain the > validity of its evidence records using the critical > cryptographic parameters, > > - periodically apply the original cryptographic maintenance > policy using the critical cryptographic parameters, "Original" should be "current". Once the policy is changed the original policy won't be reapplied. > - periodically apply a new cryptographic maintenance policy > should the previous cryptographic maintenance policy become > weak or inappropriate. > > When an archived data objet is submitted to a long term archive > service with cryptographic maintenance parameters, then the long > term archive service shall either maintain the cryptographic > validity of that archived data objet or refuse to accept the > service. If it accepts, then it needs to perform the following > basic operations: > > > > 4.X.1 Rational > > Maintenance of the validity of archived packages is a necessary basic > function of a long-term archive service. > > Maintenance of the validity of archived data objets is an > optional function > of a long-term archive service". > > > 10. A new section should be introduced to address the > requirement of some > data structures. Proposed text; > > " Y. Requirements on some data objects > > Y.1 Requirements on cryptographic maintenance policies > > A cryptographic maintenance policy: > > - must be unambiguously identified by an object identifier > (e.g. an OID), Suggest "must be unambiguously identified (e.g. an OID)". No need to require OIDs. > - must include a validity period, > > - must specify how the necessary bindings to the time scale will > be guaranteed, for example it can specify the > Time-Stamping Units > (TSU) recognized under that policy, > > - may unambiguously reference a sequence of one or more previously > defined cryptographic maintenance policies. For what purpose? > > Y.2 Requirements on critical cryptographic parameters > > Critical cryptographic parameters shall include data objects > describing all > the algorithms, and the associated key lengths used in the > object to which > the critical cryptographic parameters are associated. These > data objects may > be in the form of data objects identified using an OID, and > may include one > or more algorithm specific parameters. > > Y.3 Requirements on cryptographic maintenance parameters > > Cryptographic maintenance parameters shall include two components: > > - critical cryptographic parameters, and > > - an unambiguous reference to one cryptographic > maintenance policy. > > > 11. In formation should be added to address cryptographic > maintenance issues > in case a hash function exhibits collisions. Proposed text to > be included in > the security considerations section: > > "Cryptographic maintenance issues in case a hash function > exhibits collisions > > Submitters may submit: > > 1) signed data and their associated signatures, or > 2) signatures only (i.e. without the signed data). > > In case the hash function used to compute the digital > signature over the > original data exhibits collisions, it is necessary to > recompute a hash of > that original data using another hash function. This is not > feasible if > signatures only are submitted (i.e. without the signed data)". Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvJc5037642; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvJBD037640; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvIM6037618 for ; Tue, 5 Oct 2004 10:57:19 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCql010708 for ; Tue, 5 Oct 2004 13:57:12 -0400 Message-Id: <200410051757.i95HvCql010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Overview of comments Date: Tue, 5 Oct 2004 13:57:06 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C4AAE3.36B842C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBLn04ITtsg7eRPa0Ph8H8J/DPQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C4AAE3.36B842C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have received over 21(!) pages of comments so far. In an attempt to respond to each comment and to focus list discussion, I have reorganized the comments into four categories and will be sending a series of email messages shortly with the comments grouped into these categories along with some initial responses and a number of outstanding questions. The categories are: - Editorial comments - Archive policy-related comments - Abstract-related comments - Miscellaneous non-editorial comments Carl ------=_NextPart_000_0034_01C4AAE3.36B842C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ltans-reqs-02.txt: Overview of comments

We have received over 21(!) pages of = comments so far.  In an attempt to respond to each comment and to = focus list discussion, I have reorganized the comments into four = categories and will be sending a series of email messages shortly with = the comments grouped into these categories along with some initial = responses and a number of outstanding questions.  The categories = are:

        - Editorial comments
        - Archive policy-related comments
        - Abstract-related comments
        - Miscellaneous non-editorial comments

Carl   

------=_NextPart_000_0034_01C4AAE3.36B842C0-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvE6x037626; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95HvEWv037625; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95HvEJT037617 for ; Tue, 5 Oct 2004 10:57:14 -0700 (PDT) (envelope-from cwallace@orionsec.com) Received: from wcwallace (81.sub-166-180-54.myvzw.com [166.180.54.81]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i95HvCqm010708 for ; Tue, 5 Oct 2004 13:57:13 -0400 Message-Id: <200410051757.i95HvCqm010708@host13.websitesource.com> From: "Carl Wallace" To: "'IETF LTANS'" Subject: draft-ietf-ltans-reqs-02.txt: Editorial comments Date: Tue, 5 Oct 2004 13:57:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSrBLywsYZo5CVPR/aFqXb73/xxLQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This thread captures the editorial comments from Larry's and Denis' emails regarding the -02 draft of the long-term archive service requirements document. For each item, an indication of acceptance or a response is provided. The comments have been numbered sequentially prefaced by document section number. Non-editorial comments will be addressed in separate threads. Front Matter FM-1) Capitalize words in the title - Accepted FM-2) Use "Long-Term" instead of "Long Term" throughout the document. - Accepted Section 1 1-1) In the first paragraph of the introduction, use 'required lifetime' instead of 'useful lifetime' (in sentence 2) and 'lifetime' in sentence 3 instead of "lifetime of digitally signed data" - Rejected. I think "useful", or possibly "valuable", is preferable to "required" in this case. In sentence 3, "lifetime of digitally signed data" is necessary to establish the context for the remainder of the sentence. 1-2) Change "...via an internet" to "...via the Internet" - Accepted 1-3) Put a comma between "asserted at" - Accepted 1-4) There are two (unspecified) typos in the first sentence - Partially accepted. The spelling of technical was corrected. What's the other typo? 1-5) The third paragraph needs to be revisited because it is inappropriate. - Rejected. The paragraph does not state that the LTA is performing the validation. It states that the LTA is supporting validation (presumably through provision of evidence). However, I would see LTA-side validation as being a reasonable service. 1-6) Delete the first sentence in the fifth paragraph. What is "something"? - Partially accepted. Replaced something with "a claim" and left the sentence in place. 1-7) Delete the last sentence of the fifth paragraph and refrain from using the words notary and notarization. - Pending. References to notaries and notarization remain pending further discussion on the list regarding notaries and notarization. 1-8) Add three new terms - Pending. New terms will be added pending further discussion on the list regarding archive policies. Section 2 2-1) Section 2 needs a preface. - Suggested text accepted. 2-2) "Arbitrator" is defined but not used. - Pending. Other text may need to change to support the inclusion of this definition. 2-3) Write out 'long-term archive service' since it is a forward reference - Accepted 2-4) Define 'attestation' - May drop usage of the term (one of two instances has already been replaced). 2-5) "Originator" is defined but not used. - Pending. Other text may need to change to support the inclusion of this definition. 2-6) Various RFC3161, TSA and timestamp suggestions - All accepted Section 3 3-1) In General Principles, expand on "textual data or images". - Suggested text accepted 3-2) The statement "a long-term archive service preserves archived data objects over arbitrarily long periods of time" reads like a definition and seems to preclude services from only offering to preserve data for a specified period of time. - Suggested text accepted Section 3-3) Replace the last sentence on page 6 with the following: "A long term archive service provides material that may be used to demonstrate the existence at a given time of archived data objects, and both the integrity and authenticity of these archived data objects (i.e. that they originate from servers under the responsibility of a given long term archive service." - Why does it matter what servers the data objects originate from? The integrity is since submission (regardless of the servers that have handled the data) or before submission in the case of signed data. Section 4 4-1) Replace "This section describes requirements for a long-term archive system" with "This section describes the requirements for the protocol for # accessing a long-term archive system." - Partially accepted. The requirements aren't limited strictly to accessing a long-term archive system. Appended "and for the data formats associated with data preservation" to the suggested text. 4-2) Change "permit clients to perform the following" to "permit clients to request the following" - Accepted 4-3) Change "submit data and receive an acknowledgement or proof of deposit" to "submit data objects for archive" - Accepted 4-4) Move "submitters must be able to specify an archivation period" to bulleted list - Accepted 4-5) Remove the "Rationale" subsection heading - Pending. May remove or may provide additional detail under the Rationale subsections. 4-6) Add text describing new terms (e.g. cryptographic maintenance and related terms) - Pending. Will add additional sections pending outcome of list discussion regarding archive policy. Section 4.2 4.2-1) "Non-repudiation of data" is not a well defined service. - Accepted with alternative text. Appended "existence at and integrity since a point in time" to "non-repudiation of data". Section 4.3 4.3-1) Some of the requirements are in the rationale section - Pending. Some sections may be significantly rewritten depending on the discussing related to content-focused operations. 4.3-2) This section should be merged with the previous section. - Pending. Integrity-focused text will be merged with previous section. New text regarding content-focused operations may be added here. Section 4.4 4.4-1) A reference for certificate policy is called for. - Accepted. Added a reference to the CP/CPS framework. 4.4-2) Text should be changed to reference "cryptographic maintenance policy". - Pending. Text will be modified pending list discussion regarding archive policy. Section 4.5 4.5-1) Comment regarding support for AES and CMS is confusing - Accepted. Removed sentence. Section 4.6 4.6-1) Need to state functional requirements for transfer more clearly - Accepted. Will rework this section. Section 4.7 4.7-1) Add "a document and its translation into another format" to the items considered in this section - Accepted Section 6) 6.1) Text should be modified to refer to the cryptographic maintenance policy. - Pending. Text will be modified pending list discussion regarding archive policy. Section 8 8-1) Split references into normative and informative - Accepted. All references have been categorized. 8-2) Add references to records management practices. - Pending. Any particular references in mind? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Fs6w0025710; Tue, 5 Oct 2004 08:54:06 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i95Fs6nE025709; Tue, 5 Oct 2004 08:54:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i95Fs1Ps025672 for ; Tue, 5 Oct 2004 08:54:04 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i95FrqN01497; Tue, 5 Oct 2004 17:53:52 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 5 Oct 2004 17:53:52 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i95Frpl05845; Tue, 5 Oct 2004 17:53:51 +0200 (MEST) Date: Tue, 5 Oct 2004 17:53:51 +0200 (MEST) From: Peter Sylvester Message-Id: <200410051553.i95Frpl05845@chandon.edelweb.fr> To: rhansberger@nationalnotary.org, Denis.Pinkas@bull.net Subject: Re: Notary services requirements -- directions? Cc: LMM@acm.org, ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Richard, > > > I appreciate the feedback. I would suggest, however, that because the term > > "Notary" is legally defined and most states actually have criminal penalties > > for misappropriating the term or claiming to be a Notary when one is not, > > the term is less flexible than you suggest. In fact, we are facing a serious > > problem right now in the Western states over the issue of using the term > > "Notario Publico" inappropriately. In Latin America, a Notario Publico is, > > generally speaking, an attorney; in the US, a Notary Public is a ministerial > > official of the court. Many citizens are being misled by scam artists > > preying upon general confusion of the two terms. > > This is a real problem indeed. Why not use the term eNotary or e-Notary > instead ? > Would this change a lot? A little bit of history: C. Adams(Entrust Technologies) R. Zuccherato(Entrust Technologies) February 27, 1997 Notary Protocols became: C. Adams(Entrust Technologies) R. Zuccherato(Entrust Technologies) June 4, 1998 Data Certification Server Protocols and later Network Working Group C. Adams Request for Comments: 3029 Entrust Technologies Category: Experimental P. Sylvester EdelWeb SA - Groupe ON-X Consulting M. Zolotarev Baltimore Technologies Pty Limited R. Zuccherato Entrust Technologies February 2001 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols I don't know why the first change occured, but at least it avoids at least two problems. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9576wga009191; Tue, 5 Oct 2004 00:06:58 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9576wDB009190; Tue, 5 Oct 2004 00:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9576ud3009128 for ; Tue, 5 Oct 2004 00:06:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA37112; Tue, 5 Oct 2004 09:18:10 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100509063828:20 ; Tue, 5 Oct 2004 09:06:38 +0200 Message-ID: <416247FD.3030701@bull.net> Date: Tue, 05 Oct 2004 09:06:37 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Richard Hansberger CC: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: Re: Notary services requirements -- directions? References: <561F9357D239EB428AE3A4F14244431368CFDF@Louise2> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/10/2004 09:06:38, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 05/10/2004 09:06:40, Serialize complete at 05/10/2004 09:06:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, > I appreciate the feedback. I would suggest, however, that because the term > "Notary" is legally defined and most states actually have criminal penalties > for misappropriating the term or claiming to be a Notary when one is not, > the term is less flexible than you suggest. In fact, we are facing a serious > problem right now in the Western states over the issue of using the term > "Notario Publico" inappropriately. In Latin America, a Notario Publico is, > generally speaking, an attorney; in the US, a Notary Public is a ministerial > official of the court. Many citizens are being misled by scam artists > preying upon general confusion of the two terms. This is a real problem indeed. Why not use the term eNotary or e-Notary instead ? Denis > We ran into this same problem when the US Federal "E-Sign" Act was passed in > 2000. A number of vendors offered "Digital Notary Services" that represented > their services as replacements for human Notaries. > > Obviously, as a professional association we have our biases, but the term > "Notary" is used by US states to refer to a human witness to a transaction > of legal or financial significance. Human Notaries exist in large part to > bear witness to a signer's intent/willingness/capacity in the event a court > or other state official (e.g., in a trial proceeding or similar venue) needs > that kind of confirmation. > > Just further food for thought...I don't mean to derail any good work being > done. > > Take care, > > Richard J. Hansberger > Director of eNotarization > National Notary Association > 818-739-4027 > > -----Original Message----- > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Saturday, October 02, 2004 4:42 PM > To: 'Richard Hansberger'; ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > >>In answer to your first question, we've always understood the >>term "Notary Service" to be a technology that Notaries could use, not a >>technology that others can use in lieu of notarization. If that >>means the name of the service needs to change, I'll leave that >>decision in more capable hands. > > > While "Notary Service" might be ambiguous, I don't think > this means we have to rename it. After all, the ways in which > one noun can modify another is ambiguous: steak knife, steel > knife, boy-scout knife use different kinds of modification. > (From the Addams Family movie, about Girl Scout cookies: > "Are they made from real Girl Scouts?") > > In the context of LTANS, "notary service" seems to have been > intended as something much more narrow than what a Notary does. > > http://www.ietf.org/html.charters/ltans-charter.html > > focuses on a fairly narrow set of workflows: > > In many scenarios, users need to be able to ensure and prove the > existence and validity of data, especially digitally signed data, in a > common and reproducible way over a long and possibly undetermined period > of time. > > ... > > Long-term non-repudiation of digitally signed data is an important > aspect of PKI-related standards. Standard mechanisms are needed to > handle routine events, such as expiry of signer's public key certificate > and expiry of trusted time stamp authority certificate. > > I think we should stick to a narrow definition for notary service > requirements, and focus on those services that can reasonably be > accomplished without manual (human) intervention;the use of 'notary' > in the title is evocative (notary-like services; just like a > 'stone lion' is a lion-like stone). > > I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome > and related web pages, that there is an industry focused on tools > that Notaries can use, including for support of notarization in > electronic workflows. > > I suggest we do not include these in the notary service requirements. > > Larry > > > ------------------------------------------------------------------------ > > This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IvEuw091031; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94IvE3q091028; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94IvDP1090973 for ; Mon, 4 Oct 2004 11:57:14 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W94J3KHJ0000091C; Mon, 04 Oct 2004 11:56:53 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <4C6QYD78>; Mon, 4 Oct 2004 11:57:05 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368CFDF@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: RE: Notary services requirements -- directions? Date: Mon, 4 Oct 2004 11:57:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 9e3e68efd77b8bee62c4ca443c40dfcc Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain I appreciate the feedback. I would suggest, however, that because the term "Notary" is legally defined and most states actually have criminal penalties for misappropriating the term or claiming to be a Notary when one is not, the term is less flexible than you suggest. In fact, we are facing a serious problem right now in the Western states over the issue of using the term "Notario Publico" inappropriately. In Latin America, a Notario Publico is, generally speaking, an attorney; in the US, a Notary Public is a ministerial official of the court. Many citizens are being misled by scam artists preying upon general confusion of the two terms. We ran into this same problem when the US Federal "E-Sign" Act was passed in 2000. A number of vendors offered "Digital Notary Services" that represented their services as replacements for human Notaries. Obviously, as a professional association we have our biases, but the term "Notary" is used by US states to refer to a human witness to a transaction of legal or financial significance. Human Notaries exist in large part to bear witness to a signer's intent/willingness/capacity in the event a court or other state official (e.g., in a trial proceeding or similar venue) needs that kind of confirmation. Just further food for thought...I don't mean to derail any good work being done. Take care, Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Saturday, October 02, 2004 4:42 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94ASuOW011274; Mon, 4 Oct 2004 03:28:56 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94ASuLx011272; Mon, 4 Oct 2004 03:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailout02.datevnet.de (mailout02.datevnet.de [193.27.50.77]) by above.proper.com (8.12.11/8.12.9) with SMTP id i94ASsjL011192 for ; Mon, 4 Oct 2004 03:28:55 -0700 (PDT) (envelope-from michael.tielemann@datev.de) Received: (qmail 15430 invoked from network); 4 Oct 2004 10:28:44 -0000 Received: from mail01.services.datevnet.de (10.252.80.78) by mailout02.services.datevnet.de with SMTP; 4 Oct 2004 10:28:44 -0000 Received: (qmail 7997 invoked from network); 4 Oct 2004 10:28:44 -0000 Received: from localhost (HELO mail01.services.datev.de) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 4 Oct 2004 10:28:44 -0000 Received: (qmail 7994 invoked from network); 4 Oct 2004 10:28:43 -0000 Received: from 156.1.251.10.in-addr.arpa (HELO P25823E0) ([10.251.1.156]) (envelope-sender ) by mail01.services.datevnet.de (qmail-ldap-1.03) with SMTP for ; 4 Oct 2004 10:28:43 -0000 From: "Michael Tielemann" To: Subject: WG LAST CALL: draft-ietf-ltans-req Date: Mon, 4 Oct 2004 12:31:52 +0200 Message-ID: <002f01c4a9fd$5d007e70$9c01fb0a@P25823E0> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i94ASujL011265 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, watching the discussion here in LTANS I would like to emphasis that a couple of companies are waiting for results to implement long-term archive services within the near future. Since several years we have already electronic signed documents according to our german signaure law circulating. Most sites responsible for cryptographic security, especially trust center in the sense of our signature law are in charge to implement a long-term archive. Hence, it's of course important to discuss the wording but please don't go over the top. We need technical facts a.s.a.p. to start implementation. Mit freundlichen Grüßen With kind regards -Michael Tielemann ---------------------------------------------------------------------- + Dr. Michael Tielemann Tel: ++49 / (0)911 / 276 / 6476 + DATEV eG, Dep. P34 System Design eMail: michael.tielemann@datev.de + 90329 Nürnberg Germany GSM: ++49 / (0)172 / 8120 223 + Paumgartnerstrasse 6-14 Fax: ++49 / (0)911 / 147 / 05544 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i946jSV8032607; Sun, 3 Oct 2004 23:45:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i946jSGu032606; Sun, 3 Oct 2004 23:45:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mail4.telekom.de (mail4.telekom.de [195.243.210.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i946jQTL032480 for ; Sun, 3 Oct 2004 23:45:27 -0700 (PDT) (envelope-from ErnstG.Giessmann@t-systems.com) Received: from u9jwn.mgb01.telekom.de by mail2.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Mon, 4 Oct 2004 08:44:55 +0200 Received: from mailgate9.telekom.de (mailgate9.telekom.de [164.20.161.140]) by u9jwn.mgb01.telekom.de with ESMTP for ietf-ltans@imc.org; Mon, 4 Oct 2004 08:45:11 +0200 Received: from bach.bln05.telekom.de by mailgate9.telekom.de (8.8.8/1.1.8.2/02Aug95-1122AM) id IAA0000004393; Mon, 4 Oct 2004 08:45:04 +0200 (MET DST) Received: from [172.23.7.12] ([172.23.7.12]) by bach.bln05.telekom.de (8.8.8+Sun/8.8.8) with ESMTP id IAA06650 for ; Mon, 4 Oct 2004 08:47:16 +0200 (MET DST) Message-Id: <4160F158.80803@t-systems.com> Date: Mon, 04 Oct 2004 08:44:40 +0200 From: Ernst G Giessmann User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <200410011653.i91Grkp23823@chandon.edelweb.fr> In-Reply-To: <200410011653.i91Grkp23823@chandon.edelweb.fr> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, I would like to support Peter Sylvester, he wrote: ... > Denis proposes a lot of new text, which I think should be carefully read > and combined with the current req if we agree all on that. There is one point Denis raised, that is very important. I guess that we can compare it with the digital/electronic signature issue: The technical solutions for digital signatures (hash'n'sign) are quite clear and I would say finalized, whereas the answer on the question what a electronic signature as the future replacement for handwritten signatures is can not be given as easily. The cryptographic maintenance policy is one of the crucial points as it is the signature policy for electronic signatures. This policy may be explicit or implicit, but it *must* be there. So I would suggst to extend a bit the discussion time. It is for Long-Term and don't hurry up ;-) Regards, Ernst -- Ernst G Giessmann T-Systems GmbH ITC-Security Goslarer Ufer 35, D-10589 Berlin phone:+49-30-3497-4342 mailto:ErnstG.Giessmann@t-systems.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93D3kQj022305; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i93D3kTn022304; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i93D3jMT022297 for ; Sun, 3 Oct 2004 06:03:46 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i93D3eql011466 for ; Sun, 3 Oct 2004 09:03:40 -0400 From: "Santosh Chokhani" To: Subject: RE: Notary services requirements -- directions? Date: Sun, 3 Oct 2004 09:03:34 -0400 Message-ID: <00a601c4a949$66df3f30$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <0I4Z007HLGLPE3@mailsj-v1.corp.adobe.com> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I vote for Larry's proposal for the scope of Electronic Notary services. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Larry Masinter Sent: Saturday, October 02, 2004 8:42 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i932WTbK076635; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i932WTAn076634; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob3.obsmtp.com [64.18.1.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i932WTnV076628 for ; Sat, 2 Oct 2004 19:32:29 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 19:32:02 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i932W3Nf004726; Sat, 2 Oct 2004 19:32:03 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i932W3kq002526; Sat, 2 Oct 2004 19:32:03 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007BQLPEE3@mailsj-v1.corp.adobe.com>; Sat, 02 Oct 2004 19:32:03 -0700 (PDT) Date: Sat, 02 Oct 2004 19:32:02 -0700 From: Larry Masinter Subject: RE: WG LAST CALL: draft-ietf-ltans-reqs-02.txt In-reply-to: <415D7388.3000003@bull.net> To: "'Denis Pinkas'" Cc: ietf-ltans@imc.org Message-id: <0I4Z007BRLPEE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSnypBV7SZdS/NcR1uWk9JbDjzAPgBFzcsw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I apologize for not reviewing your comments carefully before writing my own. In several places we make conflicting suggestions for what should be done with the text. I suppose with editorial suggestions that the editors have the final call, but where there are areas of technical disagreement, the working group should comment. I think it's appropriate to respond to comments when they are received, rather than waiting for the end of the 'last call' period. Here are my comments on yours; we should work to resolve conflicts where we've made different suggestions: > The document misses to indicate that it is necessary to demonstrate the > origin of the data The submitter? Or the originator? Or both? > and that the document has been placed in a storage before > a given date so that even the system engineers in charge of > the archive system do not have the possibility to modify any more stored > documents. Is this a requirement of the protocol, or a definition of a long-term archive system? > It is proposed to delete the present abstract and to replace it with: > > "This document specifies the technical requirement for long-term archive > services able to support non repudiation of data origin with integrity and > existence of data at a given time. Data to be stored and retrieved may > include signed data. Long-term archive services operate under an archive > policy which will need to be periodically redefined as the time goes. This > document specifies the main constituents of an archive policy". This still doesn't distinguish between the description of an archive service and the requirements for the protocol for interacting with it. To be honest, it's usually fruitless to focus on the abstract if there is disagreement about the substance, so we should come back to the abstract later. I like most of what you wrote. I still don't understand exactly what is meant by an 'archive policy' and whether it is a service-wide policy or a document-specific policy. Can one archive service provider proxy for many different ones, each of which with its own policy? > In fact the main constituents of an archive policy still need > to be defined. Yes, please. > The following comments focus on one of the components of an archiving > policy, i.e. the cryptographic maintenance policy, so the > work still needs to be done. Perhaps you could be more explicit, or give some references, to an example of what such a complete policy might be? > 2. Introduction > > The second paragraph needs to be revisited (besides the two > typos in the first sentence) because it is too vague. > Proposed replacement: > > "A long term archive service accepts data from users. This data may be > confidential data or public data. When it is confidential data, it is the > responsibility of users only to take care of the confidentiality of the data > they submit. If users care that their data shall not have its semantics > disclosed to the system engineers from the long term archive service, then > they shall take care themselves of the protection of their data. Is this really the idea? That the long-term archive has no responsibility to keep its archived data private??!? I could imagine different archives with different service guarantees, but it's hard to imagine a scenario where there is no requirement for confidentiality by the service provider, e.g., if I don't want my identity and the amount of data I've archived to be made public. So, if privacy from traffic analysis is a requirement, why is privacy in general not a requirement? > When data is confidential data, it is important that > submitters can check for themselves: Is it the submitters that want to check, or some third party to which the submitters wish to provide evidence? A submitter knows what was submitted, no? > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement (*), and > > - that the data originates from them (either symmetric > or asymmetric cryptography may be used). I think the comment about cryptography is perhaps out of place. It is a mechanism, not a requirement. Or is there a requirement to use cryptography? Or to support one or the other or both? > (*) more precisely a proof of existence of data at a given > time preceding the archival time, to demonstrate that the data was placed in > a server from the long-term archive before that time. I think there's a case where a malicious (or hacked) LTA might provide unmodified data to some retrievers and modified data to others, so it's useful to be clear about WHICH data has been 'unmodified'. > When the data is public data, it is important to be able to > demonstrate to someone else (i.e. obtain a non-repudiation evidence): Non-repudiation is important whether or not the data is public. > - that the data was placed in a server from the long-term archive > service, > > - that the data has been unmodified since the time of its > placement, and > > - that the data originally placed originates from a given entity > (different from servers belonging to the long-term archive > service). Note: that entity may or may not be a Notary. I don't understand the use case where a Notary might be the 'originator'. Surely the Notary is another party whose role is to add assurances, not an originator. Or do you imagine a real (human) Notary using a LTA service? > Since the document addresses long term storage, transfer from > one data storage unit to another may happen. Retrieval of data may > thus be done from a server different from the server where the data was > originally stored. It is therefor important to attach the security to the data > itself and not to rely only on the security mechanisms and procedures performed > by the server where the data is stored or retrieved. I don't think this follows. It's important for the storage to be secure operationally, and that any transfers be performed securely. One way to do that would be to encrypt the data and rely on the encryption during the transfer, but this has its difficulties, especially if the data is accompanied by meta-data (oh, access control policies) that might also be confidential. > Two non-repudiation evidences will need to be provided: > > - a first one to demonstrate to third parties the data originally > placed originates from a given entity, > > - a second one to demonstrate to third parties that the data was > originally accepted for storage, at a given time, by a server > belonging to a given long-term archive service. This is a good separation. I'm still a little uncomfortable with 'originates', since the demonstration isn't really of the origination but an initial attestation. > Since these evidences will be provided using cryptographic > means, Must they be provided using cryptographic means? There are no other means? How about 'When these evidences are provided ...'. > Some CA keys used to validate an electronic signature may last in practice > shorter that the end of the validity period of a signature policy. So it is > important to be able to maintain their validity beyond the end of the > validity period of the signature policy. I'm unclear about whose validity 'maintain their validity' applies to. The CA keys? You're going to maintain the validity of the keys beyond the end of the validity period of the keys? > This cryptographic maintenance activity is part of the responsibilities of a > long-term archive service and will be performed according to one or more > cryptographic maintenance policies." I think cryptographic maintenance activities are one way of providing long-term assurance, certainly. > > 3. Introduction > > The third paragraph needs to be revisited because it is inappropriate. > > Validation of assertions of agreements originally asserted with digital > signatures is not a task that is within the scope of a long-term archive > service. Proposed replacement: > > "A long-term archive service may optionally support a service able to check > an evidence demonstrating that an archive package has been originally > accepted for storage, at a given time, by a server belonging to another > given long-term archive service." I'm not sure why it is out of scope. It seems like a natural service for long-term archive services to offer. > 4. Introduction > 5. Introduction I think my suggestions here are more explicit than yours, but I hope I've accomplished the same goal. > 6. Terminology ... > Cryptographic maintenance policy: a named set of rules that > defines how to maintain the validity of digitally signed objects > should one of the hash functions or asymmetrical algorithm used > to create a digital signature of a signed object become weak or > one of the private keys used to create a > digital signature of a signed object be compromised or become weak. When there is a 'named set of rules', what is the namespace? Who maintains it? Note that all of the maintenance should happen BEFORE 'hash functions or asymmetrical algorithms become week' and BEFORE private keys are compromised or become weak and not after. > "A long-term archive service may operate in two modes: > > - a passive mode, where the archived data object is an opaque > collection of bytes, or/and > > - an active mode, where the archived data object is associated > with cryptographic maintenance parameters. I think what you're saying is that cryptographic maintenance is an option for providing long-term assurance. Of course, you could consider this 'two modes', but calling them 'active' and 'passive' is misleading. There may be other operational ways of providing long-term assurance that don't involve cryptographic maintenance but are still 'active'. > When operating is the active mode, a long-term archive service has to apply > a cryptographic maintenance policy on archived data objects using the > critical cryptographic parameters associated with every archived data object. > > When operating either in the passive or the active mode, a long-term archive > service has to apply a cryptographic maintenance policy on the archived > packages using the cryptographic maintenance parameters associated with a > set of archived packages". Cryptographic maintenance is only applied when cryptographic maintenance is applied, though. So how could a service with opaque data and no information about its signatures apply a cryptographic maintenance policy? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i930g5Cu068956; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i930g57P068955; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob2.obsmtp.com [64.18.1.212]) by above.proper.com (8.12.11/8.12.9) with SMTP id i930g5N2068949 for ; Sat, 2 Oct 2004 17:42:05 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob2.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 17:42:09 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i930fobA024352; Sat, 2 Oct 2004 17:41:55 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i930fokq029786; Sat, 2 Oct 2004 17:41:50 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007HKGLPE3@mailsj-v1.corp.adobe.com>; Sat, 02 Oct 2004 17:41:50 -0700 (PDT) Date: Sat, 02 Oct 2004 17:41:50 -0700 From: Larry Masinter Subject: RE: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> To: "'Richard Hansberger'" , ietf-ltans@imc.org Message-id: <0I4Z007HLGLPE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSWBPi37cC6KZyTThCl59ulnT982wAALaMg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > In answer to your first question, we've always understood the > term "Notary Service" to be a technology that Notaries could use, not a > technology that others can use in lieu of notarization. If that > means the name of the service needs to change, I'll leave that > decision in more capable hands. While "Notary Service" might be ambiguous, I don't think this means we have to rename it. After all, the ways in which one noun can modify another is ambiguous: steak knife, steel knife, boy-scout knife use different kinds of modification. (From the Addams Family movie, about Girl Scout cookies: "Are they made from real Girl Scouts?") In the context of LTANS, "notary service" seems to have been intended as something much more narrow than what a Notary does. http://www.ietf.org/html.charters/ltans-charter.html focuses on a fairly narrow set of workflows: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. ... Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. I think we should stick to a narrow definition for notary service requirements, and focus on those services that can reasonably be accomplished without manual (human) intervention;the use of 'notary' in the title is evocative (notary-like services; just like a 'stone lion' is a lion-like stone). I see, from http://www.nationalnotary.org/enjoa/index.cfm?text=enjoaHome and related web pages, that there is an industry focused on tools that Notaries can use, including for support of notarization in electronic workflows. I suggest we do not include these in the notary service requirements. Larry -- http://larry.masinter.net Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i92LBhsk055642; Sat, 2 Oct 2004 14:11:45 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i92LBhHx055623; Sat, 2 Oct 2004 14:11:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob1.obsmtp.com [64.18.1.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i92LBf1v055591 for ; Sat, 2 Oct 2004 14:11:41 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob1.obsmtp.com ([64.18.5.12]) with SMTP; Sat, 02 Oct 2004 14:11:43 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i92LBUbA022006 for ; Sat, 2 Oct 2004 14:11:35 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i92LBKkq024440 for ; Sat, 2 Oct 2004 14:11:30 -0700 (PDT) Received: from MasinterT40 ([130.248.178.144]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4Z007DO6UVE3@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sat, 02 Oct 2004 14:11:20 -0700 (PDT) Date: Sat, 02 Oct 2004 14:11:19 -0700 From: Larry Masinter Subject: editorial comments on draft-ietf-ltans-reqs-02.txt To: ietf-ltans@imc.org Message-id: <0I4Z007DP6UVE3@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSoxFwtXP/JKGrYSb+OFNlx1fxTAQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: These are mainly editorial comments; the only non-editorial comments are marked with ****. I also have a number of questions which might turn into substantive comments depending on what was meant. I'm sorry for the length, but I thought I should do a careful review: Title: Long-Term Archive Service Requirements It's traditional to capitalize words (except prepositions) in titles. I think "Long-Term" is better than "Long Term" throughout the document (used inconsistently). =============== Abstract In many scenarios, users need to be able to prove the existence of data at a given time and integrity of data, especially digitally signed data, in a common and reproducible way after an arbitrarily long period. This document specifies the technical requirements for a long-term archive service to support such scenarios. This is a little hard to parse and perhaps misleading; the document should describe long-term archive services and provide the technical requirements for Internet protocols that interact with such services. I would suggest: # There are many scenarios in which users, even after an arbitrarily # long period of time, will need to prove the original existance of # data and the integrity of that data in the duration. In addition, # there are requirements to prove the original validity of the # signatures of digitally signed data, even after an arbitrarily # long period. This document describes a class of long-term archive # services which support such scenarios, and the technical requirements # for protocols for interacting with such services. =============== 1. Introduction Digital data durability is undermined by continual progress and change on a number of fronts. The useful lifetime of data may exceed the life span of formats and mechanisms used to store the data. The lifetime of digitally signed data may exceed the validity periods of public-key certificates used to verify signatures or the cryptanalysis period of the cryptographic algorithms used to generate the signatures. I think you mean 'required lifetime' instead of 'useful lifetime' (in sentence 2) and 'lifetime' in sentence 3. =============== "...external service accessible via an internet" perhaps "via the Internet". =============== "... credible assertion of something that is currently asserted at points well into the future." I suggest # ... credible assertion, at points well into the future, of something # that is currently asserted. or just put a comma between "asserted at" above. =============== Section 2: I think this section could use a preface, e.g., # We define the following terms based on their usage in the archiving # community, in order to provide a vocabulary for describing requirements # and the standards around them. =============== "Arbitrator" is defined but not used. =============== An evidence record may include acknowledgements from a LTA I suggest writing out 'long-term archive service' here, since it is a forward reference. =============== You might want to define 'attestation'. =============== "Originator" is defined but not used. If you keep it, 'object.The' missing a space. =============== Timestamp: A signed attestation generated by a Time Stamping Authority (TSA) that a data item existed at a certain time. [RFC3161] specifies a structure for timestamps and a protocol for communicating with a Timestamp Authority (TSA). I think it would be better to use the definitions from RFC 3161 rather than redefine the terms. RFC 3161 uses "time-stamp" and not "timestamp", but defines 'time-stamp token'. Is it appropriate to insist that long-term archive services use RFC 3161 (i.e., are we defining a 'time-stamp' as a RFC 3161 signed time-stamp token) or are we just using RFC 3161 as an example? I would suggest # Time-stamp: An attestation generated by a Time Stamping # Authority (TSA) that a data item existed at a certain time. # For example, [RFC 3161] specifies a structure for signed # time-stamp tokens as part of a protocol for communicating # with a Time-Stamp Authority (TSA). # Time-Stamp Authority (TSA): A trusted service that provides # attestations of existance of data at particular points in # time. For example, [RFC 3161] defines protocol elements for # interacting with a TSA. =============== In general, we should double check spelling and terminology and try to be a little more consistent with RFC 3161, at least if the intent is to talk about the same thing. =============== 3. General principles A long-term archive service may accept any type of data for preservation, including digitally signed data, encrypted data, time stamped data, data that has not been the subject of any cryptographic processing, textual data or images. I think the last point "textual data or images" should be expanded, e.g., # A long-term archive service may accept any type of data for # preservation. The data might be in any format, whether textual # data, images, documents, applications, or compound packages # of multiple components. The data may be digitally # signed, time-stamped, encrypted, or not subject to any cryptographic # processing. *** Is this a requirement that all of these be accepted, or is this something where variability is allowed? What is the general principle here? =============== A long-term archive service does not operate upon evidence related to the content of archived data objects. Content-focused operations, including data format migration or translation, may be performed by a notary or notarization service. *** This sounds like you intent it to be disallowed for a long-term archive service to provide any content-focused operations. Shouldn't this be 'is not required to operate upon' rather than 'does not operate on'? In any case, even if it isn't the long-term archive service doing the operating, I think it should be left open whether the content-focused operations are performed by notary services or, at least in part, by some other third-party service. For example, there could be an (untrusted) content-transformation service whose output would be validated by a (trusted) notary service. So I suggest something like: # A long-term archive service is not required to operate upon evidence # related to the content of archived data objects. Content-focused operations, # including data format migration or translation, may be performed by a # other services, e.g., notary services. ================= A long-term archive service preserves archived data objects over arbitrarily long periods of time. This reads like it is a definition. You could have a service which only guarantees to preserve data for 30 years, not 'arbitrary long periods of time'. However, removing the word 'arbitrarily' leaves this general principle not actually saying much. Perhaps you mean something like: # Different long-term archive services may establish policies and procedures # for archiving data objects over different lengths of time. is meant? I'm not sure. ================= 4. Technical Requirements This section describes requirements for a long-term archive system. I think something like: # This section describes the requirements for the protocol for # accessing a long-term archive system. ================= - submit data and receive an acknowledgement or proof of deposit perhaps 'acknowledgement or evidence of deposit'? I'm uncomfortable because we haven't defined 'proof'. Is 'attestation' better than 'acknowledgement' here (assuming we define attestation)? Or is 'proof of deposit' just the definition of 'acknowledgement'? Perhaps something like # - submit data objects for archive and then, later, with the other requirements on 'the format for the acknowledgement' # When a data object is submitted for archive, an acknowledgement # is returned. The acknowledgement includes an attestation by the # archive service of the deposit of the data object. ================= - delete archived data objects/terminate archivation period for an archived data object. Later, you point out that 'deletion may not involve physical deletion'; so this is confusing. I think the first thing to do is to change "permit clients to perform the following" to "permit clients to request the following"; the client may request deletion, just as the client may submit data, but find that the LTA can't deposit it. **** May someone request the archivation period being shortened but not immediately? (E.g., employee records are usually kept 'for the length of employement plus N years', so at employment termination, you might request shortening the lifetime to N years.) Right now the only operations are 'delete' and 'extend'. ================== Submitters must be able to specify an archivation period. I would include this in the bulleted list above with a -. ======================== It should be possible to extend the archiving period after the initial submission. Who should be able to do this? ======================== Submitters should be able to specify metadata that, for example, can be used to enable retrievers to render the data correctly. I think this may be worthy of some amplification and clarification. Do you mean explicitly content-type or other MIME-like headers? **** Usually the word 'metadata' is also associated with indexing information (Title, Author, Date, etc.). Is that kind of metadata for long-term archived data included? Is it possible to search on metadata in the long-term archive? Or is it explicitly excluded, required to be part of the archived package or part of the archived data? ===================== Following submission, the service must provide a value that can be used to retrieve the archived data and/or associated evidence. It may be possible to retrieve archive packages by using a hash value of an archived data object. **** Is this value a capability? Or does it also require authorization? Is the requirement that this retrieval handle be generated by the submitter, the long-term archive service, or by both (when it uses a hash value of the archived data object)? While I think using a hash value of an archived data object is an interesting approach, I'm not sure why it's in the requirements. ======================= Deletion requests must be authorized and an authorization policy must be defined and observed by the long-term archive service (as part of an archive policy). I assume the authorization policy is not just for 'deletion'? I think this is just editorially talking about authorization policies. I'm not sure whether the policy is per LTA or per archived document, though. ======================= The format for the acknowledgements must allow the identification of the archiving provider. **** Why is this optional? Is it the identification of the operator of the LTA? Or of the LTA itself? ======================= The format for the acknowledgements must allow the identification of the participating client. **** I think this is a more substantial requirement, that the submitting client must identify itself, and that identity may (or must? or should?) be included in the acknowledgement? ======================== 4.1.2 Rationale Given that this is just once sentence (and most of the Rationale subsections are short), I would suggest readability might be improved by eliminating the section head. # 4.1 Requirements for LTA operations # # A long-term archive service must ... # # ... end of current 4.1.1.... # # Rationale: # Submission, retrieval and deletion of archived data objects # are necessary basic functions of a long-term archive service. # 4.2 Requirements to provide evidence records # # A long-term archive service.... ====================== 4.2 Provide evidence records I think this section could be expanded. For example, the term 'trust anchors' isn't defined in the document or referenced. And it isn't clear why 'trust anchors' have to be provided by other services, rather than just 'might be provided by other services'. I think this section puts some of the requirements in the 'Rationale'. (I'm running out of steam or I would try for a rewrite). I don't think the requirements outline sufficiently what is necessary to transfer data from one archive to another, and what it means to do that; it's not just the archived data, it's the evidence, and the requirements for creating a chain of evidence could be spelled out. Perhaps the transferability requirement belongs in 4.6 and not here. The 'Submitters must be able to specify metadata ...' belongs in 4.1 and not in 4.2, because it is a requirement that submitters should be allowed to specify metadata (or must be required to specify metadata?) =============================== 4.3 Again, some of the requirements seem to be in the 'Rationale', and I'm not sure why Content-focused operations are disallowed rather than just 'not required'. I'm not sure what it means to demonstrate data integrity without also providing evidence records. If you can't demonstrate that you had the data at a particular date, how can you demonstrate that the data you have is 'the same'? ================================= 4.4 Long-term archive policy I think a reference for 'certificate policy' is called for here, and needs to be spelled out. This probably goes back to the Long-term archive policy: A named set of rules that define operational characteristics of a long-term archive service. in the definitions: what is the namespace of rule set names? Do different LTAs share named archive policies? It may be that this section has a part that is defining what a Long-term archive service does (it operates according to a policy), and that the requirements are not operational requirements but interface requirements, e.g., providing information identifying the policies. I'm not sure what 'in use at any point in time'. Are services allowed to change their policies? Can you ask today 'what were your policies 10 years ago'? The policy may define characteristics such as the quality of timestamps obtained or generated by the long-term archive service or triggers for preservation activities, e.g. timestamp refresh or data format migration. So we need to invent protocol elements for describing such things? What is the measure of 'quality of time-stamp'? ================================= 4.5 Data confidentiality Again, this is a combination of description of what a long-term archive service is, coupled with some requirements for the interface to it. # Standard encryption algorithms and formats, e.g. AES and CMS, should # be supported. I'm not sure what this means -- is this an operational requirement for how the LTA operates internally, or a protocol requirement for the submitter/retriever <-> LTA protocol. Elsewhere it said that transport security might be used to provide confidentiality, which might not use AES or CMS. ================================== 4.6 Data and evidence transferability See notes for 4.2 above. I think that it might be possible to be clearer about what the actual functional requirements are to 'support the transfer'. In fact, 'transfer' isn't really an accurate description of the operation, because when the archived data object may actually be 'transferred', most attestations and elements of trust will require another layer.' ===================================== 4.7 Supporting Groups I would put into this category "a document and its translation into another format". Consider all of the subcategories of multipart: multipart/alternative, multipart/mixed, multipart/signed... to cover the important cases. ======================= 8. References Current practice is to separate informative vs. normative references. I suppose all of these are informative. I believe that it would be very useful to provide additional informative references to records management practices. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GruL7041630; Fri, 1 Oct 2004 09:53:56 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91GruOP041629; Fri, 1 Oct 2004 09:53:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91GrtFF041599 for ; Fri, 1 Oct 2004 09:53:55 -0700 (PDT) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i91GrkN08082; Fri, 1 Oct 2004 18:53:46 +0200 (MEST) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 1 Oct 2004 18:53:46 +0200 (MET DST) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i91Grkp23823; Fri, 1 Oct 2004 18:53:46 +0200 (MEST) Date: Fri, 1 Oct 2004 18:53:46 +0200 (MEST) From: Peter Sylvester Message-Id: <200410011653.i91Grkp23823@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I seem to agree with many of Denis remarks, unfortuntely I don't have the time to answer before Tuesday, very late for personal reasons. So I just make one remark (a detail) > Since these evidences will be provided using cryptographic means, it is > important to maintain the cryptographic quality of theses evidences, even if > the signature policy under which the signatures have been done has expired. I seem to have a wording problem here: IMO The evidence may be PROTECTED by cryptographic means. Not provided? In general, the document seems mainly to address interfaces to some backend, and not really front end user interface, some elements being things mentioned by denis as: - a first one to demonstrate to third parties the data originally placed originates from a given entity, - a second one to demonstrate to third parties that the data was originally accepted for storage, at a given time, by a server belonging to a given long-term archive service. Denis proposes a lot of new text, which I think should be carefully read and combined with the current req if we agree all on that. Peter Off to homeland :-) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Ftk1d037612; Fri, 1 Oct 2004 08:55:46 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Ftkxh037611; Fri, 1 Oct 2004 08:55:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91Ftjef037601 for ; Fri, 1 Oct 2004 08:55:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA21378; Fri, 1 Oct 2004 18:07:08 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100117554060:1417 ; Fri, 1 Oct 2004 17:55:40 +0200 Message-ID: <415D7DFC.4030509@bull.net> Date: Fri, 01 Oct 2004 17:55:40 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Tobias Gondrom CC: IETF LTANS Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <3C1BE8610E44734499EF92FB35F5B0702C694D@MUCXGC1.opentext.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:55:40, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:55:43, Serialize complete at 01/10/2004 17:55:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, > Denis, > a small remark to your first comment in advance > Concerning your comments, I will not be able to study them before. > Monday, but maybe others are faster. I would suggest that you wait until the end of the last call comment period before answering. >> the first document of our working group is coming to a final state. >> I asked Carl and the authors of the document to integrate the input >> of he last discussions inspired by Denis into the document so that we >> get to a final version. From my feeling the discussion here on the >> mailing-list has come to the time of conclusion about the >> requirements for long-term archive. >>I do no have that feeling yet. Until we agree on this document, a Last >>Call for the ERS document would be premature. > It seems that you misunderstood my mail: > I have been talking about the discussion about the requirements document > not the ERS (although this is also very stable too in my eyes) - > Of course I want to open the last call for the ERS _after_ closing > the last call for reqs and making sure that we finish this document > first. I guess you do not mean mean, "_after_ closing the last call for reqs" since it will be closed on tuesday, but until the reqs document has passed the IESG Last Call. This does not prevent to progress the ERS draft, as well as other drafts, if needed, but the focus should be kept first on the requirements. Regards, Denis > Best regards > > Tobias > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FZGUD036459; Fri, 1 Oct 2004 08:35:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FZGc4036458; Fri, 1 Oct 2004 08:35:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FZEXP036446 for ; Fri, 1 Oct 2004 08:35:15 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i91FYcNp001474; Fri, 1 Oct 2004 17:34:39 +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: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Date: Fri, 1 Oct 2004 17:34:36 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0702C694D@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Thread-Index: AcSnyO2DoDG7ilmtTgSZ0qgDLJ7gzAAAjO/Q From: "Tobias Gondrom" To: "Denis Pinkas" Cc: "Carl Wallace" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91FZFXP036451 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, a small remark to your first comment in advance Concerning your comments, I will not be able to study them before Monday, but maybe others are faster. > > the first document of our working group is coming to a final state. > > I asked Carl and the authors of the document to integrate the input of > > the last discussions inspired by Denis into the document so that we get > > to a final version. From my feeling the discussion here on the > > mailing-list has come to the time of conclusion about the requirements > > for long-term archive. > > I do no have that feeling yet. Until we agree on this document, a Last > Call for the ERS document would be premature. It seems that you misunderstood my mail: I have been talking about the discussion about the requirements document not the ERS (although this is also very stable too in my eyes) - Of course I want to open the last call for the ERS _after_ closing the last call for reqs and making sure that we finish this document first. Best regards Tobias Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FBHdl034818; Fri, 1 Oct 2004 08:11:17 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91FBHnH034817; Fri, 1 Oct 2004 08:11:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91FBAmV034785 for ; Fri, 1 Oct 2004 08:11:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA39370; Fri, 1 Oct 2004 17:22:31 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004100117110495:1397 ; Fri, 1 Oct 2004 17:11:04 +0200 Message-ID: <415D7388.3000003@bull.net> Date: Fri, 01 Oct 2004 17:11:04 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: ietf-ltans@imc.org CC: Tobias Gondrom , Carl Wallace Subject: Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt References: <3C1BE8610E44734499EF92FB35F5B0702C6645@MUCXGC1.opentext.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:11:05, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 01/10/2004 17:11:06, Serialize complete at 01/10/2004 17:11:06 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i91FBCmV034805 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hello friends, > the first document of our working group is coming to a final state. > I asked Carl and the authors of the document to integrate the input of > the last discussions inspired by Denis into the document so that we get > to a final version. From my feeling the discussion here on the > mailing-list has come to the time of conclusion about the requirements > for long-term archive. I do no have that feeling yet. Until we agree on this document, a Last Call for the ERS document would be premature. > Many discussions and ideas have been presented. > For me it was very insightful and interesting to learn the different > views and requirements from all over the world. We took our time for all > the aspects, now I think we can move to a conclusion with this document > so that we can lead our discussions concerning the Notary Services > easier. We still need to agree on what is or is not a Notary Service, but we have not finished the discussion on the requirements for a long-term archive service. > I think that Carl, Ulrich and Ralf did a good job on this and > hope that you agree. > So I start the WG LAST CALL for our first WG document: > "draft-ietf-ltans-reqs-02.txt" > I declare WG Last Call (period 2 weeks) terminating at 7th October 2004 > 12:00 EST. You will find my comments below: It is believed that the last call was made to force comments to be done shortly, since the document is not yet mature. All the comments below are focussed on usage of cryptography for the short and long term, thus concerns like longevity of the storage media (although very important) are not considered. The following comments are thus offered: 1. Abstract The abstract is not correct and should be changed. The document misses to indicate that it is necessary to demonstrate the origin of the data and that the document has been placed in a storage before a given date so that even the system engineers in charge of the archive system do not have the possibility to modify any more stored documents. It is proposed to delete the present abstract and to replace it with: “This document specifies the technical requirement for long-term archive services able to support non repudiation of data origin with integrity and existence of data at a given time. Data to be stored and retrieved may include signed data. Long-term archive services operate under an archive policy which will need to be periodically redefined as the time goes. This document specifies the main constituents of an archive policy”. In fact the main constituents of an archive policy still need to be defined. The following comments focus on one of the components of an archiving policy, i.e. the cryptographic maintenance policy, so the work still needs to be done. 2. Introduction The second paragraph needs to be revisited (besides the two typos in the first sentence) because it is too vague. Proposed replacement: “A long term archive service accepts data from users. This data may be confidential data or public data. When it is confidential data, it is the responsibility of users only to take care of the confidentiality of the data they submit. If users care that their data shall not have its semantics disclosed to the system engineers from the long term archive service, then they shall take care themselves of the protection of their data. When data is confidential data, it is important that submitters can check for themselves: - that the data was placed in a server from the long-term archive service, - that the data has been unmodified since the time of its placement (*), and - that the data originates from them (either symmetric or asymmetric cryptography may be used). (*) more precisely a proof of existence of data at a given time preceding the archival time, to demonstrate that the data was placed in a server from the long-term archive before that time. When the data is public data, it is important to be able to demonstrate to someone else (i.e. obtain a non-repudiation evidence): - that the data was placed in a server from the long-term archive service, - that the data has been unmodified since the time of its placement, and - that the data originally placed originates from a given entity (different from servers belonging to the long-term archive service). Note: that entity may or may not be a Notary. Since the document addresses long term storage, transfer from one data storage unit to another may happen. Retrieval of data may thus be done from a server different from the server where the data was originally stored. It is therefor important to attach the security to the data itself and not to rely only on the security mechanisms and procedures performed by the server where the data is stored or retrieved. Two non-repudiation evidences will need to be provided: - a first one to demonstrate to third parties the data originally placed originates from a given entity, - a second one to demonstrate to third parties that the data was originally accepted for storage, at a given time, by a server belonging to a given long-term archive service. Since these evidences will be provided using cryptographic means, it is important to maintain the cryptographic quality of theses evidences, even if the signature policy under which the signatures have been done has expired. A signature policy cannot last longer than the resistance of the root keys used in that policy, so it will always be limited in time. Some CA keys used to validate an electronic signature may last in practice shorter that the end of the validity period of a signature policy. So it is important to be able to maintain their validity beyond the end of the validity period of the signature policy. This cryptographic maintenance activity is part of the responsibilities of a long-term archive service and will be performed according to one or more cryptographic maintenance policies.” 3. Introduction The third paragraph needs to be revisited because it is inappropriate. Validation of assertions of agreements originally asserted with digital signatures is not a task that is within the scope of a long-term archive service. Proposed replacement: “A long-term archive service may optionally support a service able to check an evidence demonstrating that an archive package has been originally accepted for storage, at a given time, by a server belonging to another given long-term archive service.” 4. Introduction The first sentence from last (i.e. fifth) paragraph from page 3 needs to be revisited because it is to vague (what is the “something ?”). Delete the first sentence. 5. Introduction The very last sentence from the paragraph from page 3 needs to be revisited because it is too vague. Since notarization is an undefined or controversial term, it cannot be said that it will or will not be covered in this document. It is proposed to delete that sentence and not to use the words notarization and notary at any place within this document. 6. Terminology The overall new terminology looks fine. However, it would be useful to introduce three new terms: Cryptographic maintenance policy: a named set of rules that defines how to maintain the validity of digitally signed objects should one of the hash functions or asymmetrical algorithm used to create a digital signature of a signed object become weak or one of the private keys used to create a digital signature of a signed object be compromised or become weak. Critical cryptographic parameters: collection of cryptographic parameters, together with their associated parameters, if any (e.g. key lengths), associated with data, to be used to maintain the validity of digitally signed objects under a cryptographic maintenance policy. Cryptographic maintenance parameters: Critical cryptographic parameters together with a reference to a cryptographic maintenance policy. 7. General Principles Starting from the second sentence on page 6, the text needs to be revisited, since the text is only addressing one case out of two. As mentioned previously two non-repudiation evidences may be attached to a given archived data object. These non-repudiation evidences will need to be maintained over time. If the data object that is submitted does not include an evidence to demonstrate to third parties the data originally placed originates from a given entity, then it is correct to say that the data object is opaque. However, this is no more the case, when the data object that is submitted includes an evidence to demonstrate to third parties the data originally placed originates from a given entity. The “conclusion” made in the third paragraph is therefor incorrect. A long-term archive service may need to operate in accordance with the content of the archived data objets. In addition, as said earlier, since notarization is an undefined or controversial term, it should not be used at any place within this document. Proposed replacement for both the second and third paragraphs: “A long-term archive service may operate in two modes: - a passive mode, where the archived data object is an opaque collection of bytes, or/and - an active mode, where the archived data object is associated with cryptographic maintenance parameters. When operating is the active mode, a long-term archive service has to apply a cryptographic maintenance policy on archived data objects using the critical cryptographic parameters associated with every archived data object. When operating either in the passive or the active mode, a long-term archive service has to apply a cryptographic maintenance policy on the archived packages using the cryptographic maintenance parameters associated with a set of archived packages”. 8. General Principles The text from the last sentence, on page 6, needs to be revisited. Proposed replacement: “ A long term archive service provides material that may be used to demonstrate the existence at a given time of archived data objects, and both the integrity and authenticity of these archived data objects (i.e. that they originate from servers under the responsibility of a given long term archive service.” 9. Section 4. Technical requirements This section describes, quite well, the functions dedicated to storage and retrieval. However, it currently misses to describe the functions associated with the use of cryptographic maintenance policies and cryptographic maintenance parameters which are always associated with archived packages and with critical security parameters which may be associated with archived data objects. In order to fill-in this gap, some text in provided below: “4.X Cryptographic maintenance 4.X.1 Functional requirements A long term archive service must maintain the cryptographic validity of its evidence records. It needs to perform the following basic operations: - attach cryptographic maintenance parameters to one or a set of archived packages, - apply the cryptographic maintenance policy referenced within the cryptographic maintenance parameters to maintain the validity of its evidence records using the critical cryptographic parameters, - periodically apply the original cryptographic maintenance policy using the critical cryptographic parameters, - periodically apply a new cryptographic maintenance policy should the previous cryptographic maintenance policy become weak or inappropriate. When an archived data objet is submitted to a long term archive service with cryptographic maintenance parameters, then the long term archive service shall either maintain the cryptographic validity of that archived data objet or refuse to accept the service. If it accepts, then it needs to perform the following basic operations: - apply the cryptographic maintenance policy requested by the submitter within the cryptographic maintenance parameters and maintain the validity of the archived data objet according to that cryptographic maintenance policy using the critical cryptographic parameters that are present in the cryptographic maintenance policy associated with the archived data objet, - periodically apply the original cryptographic maintenance policy that has been used in accordance with the critical cryptographic parameters, - periodically apply a new cryptographic maintenance policy if the previous cryptographic maintenance policy becomes too weak or inappropriate. 4.X.1 Rational Maintenance of the validity of archived packages is a necessary basic function of a long-term archive service. Maintenance of the validity of archived data objets is an optional function of a long-term archive service”. 10. A new section should be introduced to address the requirement of some data structures. Proposed text; “ Y. Requirements on some data objects Y.1 Requirements on cryptographic maintenance policies A cryptographic maintenance policy: - must be unambiguously identified by an object identifier (e.g. an OID), - must include a validity period, - must specify how the necessary bindings to the time scale will be guaranteed, for example it can specify the Time-Stamping Units (TSU) recognized under that policy, - may unambiguously reference a sequence of one or more previously defined cryptographic maintenance policies. Y.2 Requirements on critical cryptographic parameters Critical cryptographic parameters shall include data objects describing all the algorithms, and the associated key lengths used in the object to which the critical cryptographic parameters are associated. These data objects may be in the form of data objects identified using an OID, and may include one or more algorithm specific parameters. Y.3 Requirements on cryptographic maintenance parameters Cryptographic maintenance parameters shall include two components: - critical cryptographic parameters, and - an unambiguous reference to one cryptographic maintenance policy. 11. In formation should be added to address cryptographic maintenance issues in case a hash function exhibits collisions. Proposed text to be included in the security considerations section: “Cryptographic maintenance issues in case a hash function exhibits collisions Submitters may submit: 1) signed data and their associated signatures, or 2) signatures only (i.e. without the signed data). In case the hash function used to compute the digital signature over the original data exhibits collisions, it is necessary to recompute a hash of that original data using another hash function. This is not feasible if signatures only are submitted (i.e. without the signed data)”. 12. Minor comment on section 4.2.1. page 8. The first sentence is too vague since “non-repudiation of data” is not a well defined service. It is believed it is meant there something like: “non-repudiation of the fact that some data was placed in a server from the long-term archive service, and that the data has been unmodified since the time of its placement”. A similar change should be done in section 4.2.2. 13. Comment on section 4.3. page 8. This section is confusing since the previous one already covers data integrity. Its text should be merged with the previous section. 14. Comment on section 4.4.1 page 9. This section introduces the term “long-term archive service policy”. Since the concept of cryptographic maintenance policy has now be introduced, it would be more exact to say that the “characteristics such as quality of the time-stamps” are part of the cryptographic maintenance policy, which itself may be part of a long-term archive service policy. The text should be changed accordingly. 15. Comment on section 6 page 12. The second paragraph should be modified to refer to the cryptographic maintenance policy. Note: the very last sentence of the section is very true, but should be moved in the main body of the document with additional explanations, since the chain of policies has also to do with a chain of cryptographic maintenance policies. END OF COMMENTS Denis > Best regards > > Tobias > Chair of LTANS > > > > Ps.: Small remark: Soon after completion of this Last Call I prepare to > start the Last Call for the ERS document so that we can focus our work > fully on the notary services problems at the 61st IETF meeting in > November. > > > > >>-----Original Message----- >>From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > >>On Behalf Of Internet-Drafts@ietf.org >>Sent: Tuesday, September 21, 2004 9:39 PM >>To: i-d-announce@ietf.org >>Cc: ietf-ltans@imc.org >>Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>This draft is a work item of the Long-Term Archive and Notary Services >>Working Group of the IETF. >> >> Title : Long term archive service requirements >> Author(s) : C. Wallace, et al. >> Filename : draft-ietf-ltans-reqs-02.txt >> Pages : 17 >> Date : 2004-9-21 >> >>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 technical requirements >>for a long-term archive service to support such scenarios. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.txt >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the > >>message. >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the >>username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-ltans-reqs-02.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-ltans-reqs-02.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CiohC026060; Fri, 1 Oct 2004 05:44:50 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i91Cio1l026059; Fri, 1 Oct 2004 05:44:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i91CineZ026051 for ; Fri, 1 Oct 2004 05:44:49 -0700 (PDT) (envelope-from wwilbur@orionsec.com) Received: from wwwilbur (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i91Ciaql020490 for ; Fri, 1 Oct 2004 08:44:50 -0400 Message-Id: <200410011244.i91Ciaql020490@host13.websitesource.com> From: "Warren Wilbur" To: Subject: Proposal for using WebDAV to implement a trusted archive server Date: Fri, 1 Oct 2004 08:44:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C4A792.E9E8D2F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcSntGfq2EulBARZSiisZPDB5DHExQ== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C4A792.E9E8D2F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I'm new to the LTANS community but I understand that someone has suggested using the WebDAV protocol to implement a long term archive. I've spent some time thinking about whether this would be desirable/feasible and would like to hear your opinion on that. 1. Why use WebDAV? WebDAV is already supported on Microsoft Windows and Linux as a virtual mounted drive. The archive _could_ be designed to allow users the convenience of using their favorite application to file/save and file/load their data directly to and from the archive server. The popular Apache web server includes a module supporting WebDAV which allows the implementer to implement an arbitrary back end for WebDAV data storage (i.e. file system, database, etc.). WebDAV already provides the basic functionality of a file archive through it's GET, PUT, MKCOL (i.e. mkdir), COPY, MOVE, DELETE, LOCK, UNLOCK, PROPFIND (property find), and PROPPATCH (property write/create) operations. WebDAV properties can be associated with data objects and collection objects (i.e. collections are similar to directories). WebDAV creates a namespace very similar to the hierarchical directory structure used in a file-system but allows the user to declare and manage arbitrary properties for each file or collection. 2. How would the basic requirements of LTANS be implemented using WebDAV? Submit data - PUT (creates or overwrites a data object in the WebDAV archive) Retrieve data - GET (reads a data object in the WebDAV archive) Delete data - DELETE (removes a data object from the WebDAV archive) Specify/extend archivation period - PROPPATCH (store the 'archivation period' in metadata associated with data object) Request/response authentication - Using Apache with mod_dav to host WebDAV allows a large list of authentication methods for secure communication with users. Delete must be authenticated - Each individual WebDAV command (e.g. DELETE) may be individually restricted. Submitting data together with previously generated evidence - PUT and PROPPATCH (evidence placed in metadata associated with data object) Providing evidence records for data objects - PROPFIND (get the evidence in metadata associated with data object) Work efficiently even for large amounts of archived data objects - Using the Apache webserver to provide WebDAV allows the use of an industrial strength server. Support for evidence that applies to a collection of data objects - PROPPATCH/PROPFIND on the properties of the containing collection object NOTE: The 'archivation period' and 'evidence' associated with a data object should be implemented using WebDAV properties associated with each data object. Trusted archive client software would have to be provided to support WebDAV property management (i.e. using PROPFIND/PROPPATCH) for the data objects in the archive. NOTE2: For each WebDAV operation the URI of the resource must be specified. Most WebDAV operations will also work on a collection (i.e. dir) if that is specified. 3. How can we store binary evidence data using WebDAV properties? WebDAV stores unbound file metadata as XML properties. XML cannot store binary data without a conversion into one of the supported character sets specified in the XML standard. Binary data must be converted or the XML parser will halt with an error as soon as it encounters an invalid character for the specified character set. There are a number of common conversion methods (e.g. base64, Huffman coding, etc.) but none of them are as efficient as leaving the data in binary form. Having binary data in the data object isn't a problem. For the properties associated with the data object binary data must be converted. Summary: WebDAV can provide the basic archive services required for LTANS. Further work must be done to map the server's evidence preservation activities into the WebDAV model. This is just a rough cut at trying to provide a mapping of the LTANS requirements onto WebDAV. If this idea is accepted favorably then I would recommend additional research on WebDAV and the preparation of a more detailed proposal. It would be nice to have a proposal that includes detailed use cases to explain how WebDAV structures would be managed. I will look forward to your feedback and would be willing to further develop these concepts... Warren Wilbur Orion Security Solutions, Inc. wwilbur@orionsec.com 703-917-0060 x34 ------=_NextPart_000_0065_01C4A792.E9E8D2F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi,

Hi,

 

I’m new to the LTANS community but I understand = that someone has suggested using the WebDAV protocol to implement a long term = archive. I’ve spent some time thinking about whether this would be desirable/feasible and would like to hear your opinion on = that.

 

1. Why use WebDAV?

 

WebDAV is already supported on Microsoft Windows and = Linux as a virtual mounted drive. The archive _could_ be designed to allow = users the convenience of using their favorite application to file/save and = file/load their data directly to and from the archive server. The popular Apache = web server includes a module supporting WebDAV which allows the implementer = to implement an arbitrary back end for WebDAV data storage (i.e. file = system, database, etc.). WebDAV already provides the basic functionality of a = file archive through it’s GET, PUT, MKCOL (i.e. mkdir), COPY, MOVE, = DELETE, LOCK, UNLOCK, PROPFIND (property find), and PROPPATCH (property = write/create) operations. WebDAV properties can be associated with data objects and collection = objects (i.e. collections are similar to directories). WebDAV creates a = namespace very similar to the hierarchical directory structure used in a file-system = but allows the user to declare and manage arbitrary properties for each file = or collection.

 

2. How would the basic requirements of LTANS be = implemented using WebDAV?

 

Submit data – PUT (creates or overwrites a data = object in the WebDAV archive)

Retrieve data – GET (reads a data object in the = WebDAV archive)

Delete data – DELETE (removes a data object = from the WebDAV archive)

Specify/extend archivation period – PROPPATCH = (store the ‘archivation period’ in metadata associated with data = object)

Request/response authentication – Using Apache = with mod_dav to host WebDAV allows a large list of authentication methods for = secure communication with users.

Delete must be authenticated – Each individual = WebDAV command (e.g. DELETE) may be individually = restricted.

Submitting data together with previously generated = evidence – PUT and PROPPATCH (evidence placed in metadata associated with = data object)

Providing evidence records for data objects – = PROPFIND (get the evidence in metadata associated with data = object)

Work efficiently even for large amounts of archived = data objects – Using the Apache webserver to provide WebDAV allows the = use of an industrial strength server.

Support for evidence that applies to a collection of = data objects – PROPPATCH/PROPFIND on the properties of the containing collection object

 

NOTE: The ‘archivation period’ and ‘evidence’ associated with a data object should be = implemented using WebDAV properties associated with each data object. Trusted = archive client software would have to be provided to support WebDAV property = management (i.e. using PROPFIND/PROPPATCH) for the data objects in the = archive.

NOTE2: For each WebDAV operation the URI of the = resource must be specified. Most WebDAV operations will also work on a collection = (i.e. dir) if that is specified.

 

3. How can we store binary evidence data using WebDAV properties?

 

WebDAV stores unbound file metadata as XML = properties. XML cannot store binary data without a conversion into one of the supported = character sets specified in the XML standard. Binary data must be converted or the = XML parser will halt with an error as soon as it encounters an invalid = character for the specified character set. There are a number of common conversion methods (e.g. base64, Huffman coding, etc…) but none of them are = as efficient as leaving the data in binary form. Having binary data in the = data object isn’t a problem. For the properties associated with the = data object binary data must be converted.

 

Summary: WebDAV can provide the basic archive = services required for LTANS. Further work must be done to map the server’s evidence preservation activities into the WebDAV = model.

 

 

This is just a rough cut at trying to provide a mapping of the LTANS requirements onto = WebDAV. If this idea is accepted favorably then I would recommend additional = research on WebDAV and the preparation of a more detailed proposal. It would be nice = to have a proposal that includes detailed use cases to explain how WebDAV structures would be managed. I will look forward to your feedback and = would be willing to further develop these = concepts...

 

Warren Wilbur

Orion Security Solutions, Inc.

wwilbur@orionsec.com<= /span>

703-917-0060 x34

 

------=_NextPart_000_0065_01C4A792.E9E8D2F0--