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 j8TMo3q5086042; Thu, 29 Sep 2005 15:50: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 j8TMo3Jo086041; Thu, 29 Sep 2005 15:50:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8TMo2sI086034 for ; Thu, 29 Sep 2005 15:50:02 -0700 (PDT) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EL7E2-0004CQ-2r; Thu, 29 Sep 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-ers-scvp-00.txt Message-Id: Date: Thu, 29 Sep 2005 18:50:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Using SCVP to Convey Long-term Evidence Records Author(s) : C. Wallace Filename : draft-ietf-ltans-ers-scvp-00.txt Pages : 16 Date : 2005-9-29 The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust can be established in the certificates after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-scvp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-ers-scvp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-ers-scvp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-29155319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-29155319.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 j86FBH2j044044; Tue, 6 Sep 2005 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 j86FBHfc044043; Tue, 6 Sep 2005 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 e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id j86FBG12044035 for ; Tue, 6 Sep 2005 08:11:16 -0700 (PDT) (envelope-from aljosa@e5.ijs.si) Message-Id: <200509061511.j86FBG12044035@above.proper.com> Received: (qmail 20151 invoked from network); 6 Sep 2005 15:11:15 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 6 Sep 2005 15:11:15 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 20093-01 for ; Tue, 6 Sep 2005 17:11:13 +0200 (CEST) Received: (qmail 20144 invoked from network); 6 Sep 2005 15:11:13 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 6 Sep 2005 15:11:13 -0000 From: "A. Jerman Blazic" To: Subject: RE: LTAP questions and discussion Date: Tue, 6 Sep 2005 17:14:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWy5+W9MCcq+Z4wS4yAAsN1jZEOJwADBGhQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3C1BE8610E44734499EF92FB35F5B0700123D10B@MUCXGC1.opentext.net> X-Virus-Scanned: amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j86FBH12044038 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias, see inline > Hello, > > > > I studied the LTAP document last weekend completely and > although it’s a good start for the document there are still > many places where you left the “TBD” mark in the document. Well, the result of rush and deadlines.... > I have some questions for discussion about it: > > a) in Section 2 the sentence “Such attributes may come as e.g. meta > > information or digital signatures” – I though signatures > would be transmitted as data (i.e. in a file) not in separate > attributes associated with the files – AFAIK you typically > store signatures together with the content in one container > (e.g. CMS) or in two separate files (also pkcs#7 or CMS) Hmm, a discussion was raised over this. The fact is that, raw data and signatures needed to be processed separately, i.e. different methods for sustaining the validity of signatures or integrity of data needs to be in place, hence the differentiation of the data. Security attributes is the expression that seems more suitable.... But I agree that data and signatures are stored in one container (archive object). It may happen that signature has more references, but this is altogether another issue. > b) in 3 you speak of the EXPORT function and later (4 or 5) > of the MODIFY function both with nearly the same scope. > > I think we should agree on one name – maybe even none of the > both but e.g. “RETRIEVE” or . else? – otherwise I would > prefer EXPORT over MODIFY I was not aware of this. EXPORT is the correct word. > c) the fact that we separate the protocol from the layers for > identification and authentication is ok for me (as we already > discussed in Paris) – but I think we should consolidate the > number of locations we speak of this in whole document – it > seems to me that we duplicate statement several times within > the document. Agree. > d) concerning the content of the requests and responses: > > In your proposal you write that ASN.1 and XML should be > specified. I am wondering whether we might also be able to > just get along with XML in the request and response data > structures with the content of archived files and the ERS > (which is in ASN.1 encoded) simply as the payload of such > protocol calls. For me it seems acceptable that we would have > only one protocol specification in XML with binary (including > ASN.1) payloads. XML is the favourable approach (analogue to let's say SOAP), however ERS should follow the same syntax (as done for our implementation). > e) a simple example call for each of the five functions might > be helpful for understanding. Will include. BR Aleksej 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 j86DZojT034687; Tue, 6 Sep 2005 06:35: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 j86DZnmT034686; Tue, 6 Sep 2005 06:35:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx02.ixos.de (HOST.128.47.ixos.de [149.235.128.47]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j86DZm2n034676 for ; Tue, 6 Sep 2005 06:35:49 -0700 (PDT) (envelope-from tgondrom@opentext.com) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx02.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id j86DZaWR007270 for ; Tue, 6 Sep 2005 15:35:42 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5B2E7.DE8322C1" Subject: LTAP questions and discussion Date: Tue, 6 Sep 2005 15:35:51 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0700123D10B@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTAP questions and discussion Thread-Index: AcWy5+W9MCcq+Z4wS4yAAsN1jZEOJw== From: "Tobias Gondrom" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C5B2E7.DE8322C1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I studied the LTAP document last weekend completely and although it's a = good start for the document there are still many places where you left = the "TBD" mark in the document.=20 =20 I have some questions for discussion about it: a) in Section 2 the sentence "Such attributes may come as e.g. meta information or digital signatures" - I though signatures would be = transmitted as data (i.e. in a file) not in separate attributes = associated with the files - AFAIK you typically store signatures = together with the content in one container (e.g. CMS) or in two separate = files (also pkcs#7 or CMS) b) in 3 you speak of the EXPORT function and later (4 or 5) of the = MODIFY function both with nearly the same scope. I think we should agree on one name - maybe even none of the both but = e.g. "RETRIEVE" or s.th. else? - otherwise I would prefer EXPORT over = MODIFY c) the fact that we separate the protocol from the layers for = identification and authentication is ok for me (as we already discussed = in Paris) - but I think we should consolidate the number of locations we = speak of this in whole document - it seems to me that we duplicate = statement several times within the document. d) concerning the content of the requests and responses: In your proposal you write that ASN.1 and XML should be specified. I am = wondering whether we might also be able to just get along with XML in = the request and response data structures with the content of archived = files and the ERS (which is in ASN.1 encoded) simply as the payload of = such protocol calls. For me it seems acceptable that we would have only = one protocol specification in XML with binary (including ASN.1) = payloads. e) a simple example call for each of the five functions might be helpful = for understanding. =20 Best regards, Tobias =20 =20 Ps.: in addition to the two implementations I mentioned last week, = Aleksej notified me of a third one currently on the way - so the numbers = are rising. =20 =20 =20 __________________________________________ Tobias Gondrom Senior Security Architect Head of Open Text Security Team Open Text Corporation Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ This eMail may contain confidential and/or privileged information. If = you are not the intended recipient or have received this eMail in error, = please notify the sender immediately and destroy this eMail. Any use, = disclosure or distribution of the material in this eMail is strictly = forbidden. Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte = Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den = Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet. =20 ------_=_NextPart_001_01C5B2E7.DE8322C1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I studied the LTAP document last weekend completely = and although it’s a good start for the document there are still many places = where you left the “TBD” mark in the document. =

 

I have some questions for discussion about = it:

a) in Section 2 the sentence “Such attributes = may come as e.g. meta

=A0=A0 information or digital signatures” = – I though signatures would be transmitted as data (i.e. in a file) not in separate attributes associated with the files – AFAIK you typically store signatures together with the content in one container (e.g. CMS) or in = two separate files (also pkcs#7 or CMS)

b) in 3 you speak of the EXPORT function and later (4 = or 5) of the MODIFY function both with nearly the same = scope.

I think we should agree on one name – maybe = even none of the both but e.g. “RETRIEVE” or s.th. else? – = otherwise I would prefer EXPORT over MODIFY

c) the fact that we separate the protocol from the = layers for identification and authentication is ok for me (as we already = discussed in Paris) – but I think we should consolidate the number of locations = we speak of this in whole document – it seems to me that we duplicate = statement several times within the document.

d) concerning the content of the requests and = responses:

=A0In your proposal you write that ASN.1 and XML = should be specified. I am wondering whether we might also be able to just get = along with XML in the request and response data structures with the content of = archived files and the ERS (which is in ASN.1 encoded) simply as the payload of = such protocol calls. For me it seems acceptable that we would have only one = protocol specification in XML with binary (including ASN.1) = payloads.

e) a simple example call for each of the five = functions might be helpful for understanding.

 

Best regards, Tobias

 

 

Ps.: in addition to the two implementations I = mentioned last week, Aleksej notified me of a third one currently on the way – so = the numbers are rising.

 

 

 

__________________________________________
Tobias = Gondrom
Senior Security Architect
Head of Open Text Security Team

Open Text = Corporation
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 = 4629-33-1816
eMail:  mailto:tobias.gondrom@opentex= t.com
Internet:      http://www.opentext.com/

This eMail may contain confidential = and/or privileged information. If you are not the intended recipient or have = received this eMail in error, please notify the sender immediately and destroy = this eMail. Any use, disclosure or distribution of the material in this eMail = is strictly forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich = gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese = eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese eMail. Jegliche Art der Verwendung, = Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

 

------_=_NextPart_001_01C5B2E7.DE8322C1--