RE: ERS - using hash tree?
"Tobias Gondrom" <tgondrom@opentext.com> Wed, 28 November 2007 15:16 UTC
Return-path: <owner-ietf-ltans@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOe9-0003Ct-NP for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 28 Nov 2007 10:16:17 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOe7-0002vF-6L for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 28 Nov 2007 10:16:17 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASEsTo5041415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 07:54:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lASEsTYC041414; Wed, 28 Nov 2007 07:54:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASEsPq5041399 for <ietf-ltans@imc.org>; Wed, 28 Nov 2007 07:54:28 -0700 (MST) (envelope-from tgondrom@opentext.com)
Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lASEsFFg024929; Wed, 28 Nov 2007 15:54:15 +0100 (MET)
Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lASEsEln001959; Wed, 28 Nov 2007 09:54:14 -0500 (envelope-from tgondrom@opentext.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: ERS - using hash tree?
Date: Wed, 28 Nov 2007 15:54:13 +0100
Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net>
In-Reply-To: <c58e154b0711270754k68004dbei7a89f473d511e244@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: ERS - using hash tree?
Thread-Index: AcgxDeBcRRyEdIbaQMS/+Q0bt5+ozwAvZRUA
From: Tobias Gondrom <tgondrom@opentext.com>
To: Jesus Maria Mendez Perez <jesusmmp@gmail.com>
Cc: ietf-ltans@imc.org
X-Archived: msg.Bv71uGR:2007-11-28:mucpm02.smtp.dmz.opentext.com
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lASEsTq5041407
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lASEsTo5041415
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080
Hello Jesus, Hm, am not sure I understand your question completely, but let me explain a bit more about ERS. (if you like we can also talk in at the Vancouver meeting next week, or you can give me a short call, as this is maybe a lot easier in person or via phone.) However: Typically you will build one hashtree per time interval (e.g. lets say per day) for all your documents independent of how long you want to keep the individual documents. Lets say you get one day 2 groups of 3 documents each and a set of 5 individual documents (d1...d5). Then you would e.g. group them on the lowest level in four groups: group-1 group-2 and a generic group-3 (d-1, d2, d-3) and a generic group-4 (d4, d-5, hash(of null or random)) You get your timestamp and keep the whole ER until the last of the documents can be deleted. Let's look at the retention: Let's say d-1 passes its retention time first: then you delete d-1 normally. You leave the ER intact as it only contains the hash value of d-1 but not the document itself. If for the other documents a ERS is requested you send back the specific ER for this document. Personal comment: a few systems I know of actually do not care about the possible semantics of data object groups in ERS, but only look at the individual data objects. They just group the received data objects in binary ascending order and then bundle them together to groups (based on a system wide defined/customized arity of the hashtree). (you give away the advantage of the semantics of the data object group, but can parse and build the ER structures a lot faster as you always know the exact arity/group sizes on every level.) Hope this explains it a bit more. Tobias Ps.: can you maybe tell me a bit more about your goal: e.g. a verification tool would have to be much more flexible in respect to e.g. what arities and node geometry it accepts of ER hashtrees, compared to if you build a TAS, in which case you could e.g. define a fixed arity for your system generated trees, decide whether to offer users "data object groups" and other parameters of your system as you like. Pss.: I'll be at the IETF conf in Vancouver next week and back on Dec-10. So if you like you can give me a short call tomorrow, meet next week at the LTANS meeting, or call me after Dec-10th. __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler > -----Original Message----- > From: Jesus Maria Mendez Perez [mailto:jesusmmp@gmail.com] > Sent: Tuesday, November 27, 2007 4:55 PM > To: Tobias Gondrom > Cc: ietf-ltans@imc.org > Subject: Re: ERS - using hash tree? > > On Nov 22, 2007 7:27 PM, Tobias Gondrom <tgondrom@opentext.com> wrote: > > Hello Jesus, > > > > 1. > > > Then, what is the meaning of building the hash tree if you really > > > after of building it you can´t add or remove any data object?. > > > > Yes, after you completed the hashtree and protect it with a timestamp > you can not add further nodes. (Comment: Typical ERS-systems build one > hashtree per day for all documents that were archived during that day and > sign the hashtree every evening with a timestamp.) > > Then, if I want to preserve some documents in the same day, for > example 3, and to archive them during differents periods of time, the > first one (d1) until 01-12-07, the second (d2) until 15-12-07 and the > last one (d3) until 01-01-08 for example and I send independently to > the TAS server. > > How have they been manage? > What evidences are the TAS server archiving? > Has the TAS server to built 2 evidences? (first to preserve each > document separately (Fig 1)) > > ----- ------ -- > ---- > | d1 | | d2 | | > d3 | > ------ ------ > ------ > | | > | > | | > | > ------ ------- > ------ > | h1 | | h2 | | h3 | > ------ ----- > ------ > | | > | > ---------------- ------------------- > --------------------- > | TS(01-12-07) | | TS(15-12-07 | | TS(01-01-08) | > ------------------ ------------------- > -------------------- > Fig 1 > > and after that a second evidence to include them in the evening > hash-tree (Fig 2)? > Suppose another user, send during the same day the document > "anotherd4". In the same day only were sent d1,d2,d3 and anotherd4. > > ------ ------ ------ > --------------- > | d1 | | d2 | | d3 | | > anotherd4 | > ------ ------ ------ > ---------------- > | | | > | > | | | > | > ------ ------ ------ --- > --- > | h1 | | h2 | | h3 | | h4 | > ------ ------ ------ --- > --- > | | | > | > | | | | > | | > -------- ------ > | h12 | | h34 | > -------- ------ > | | > | | > | > ----------- > | h1234 | > ----------- > | > -------------- > | TSh1234 | > -------------- > Fig 2 > > > And what is the evening's timestamp during? > > > Another doubt: But then can I send a group of documents to preserving > and preserve it independently all other (Fig 3), (without including > them in the evening hash-tree)? > Can I decide what groups of documents form the evening-hash-tree? Can > the TAS server archive "little" hash-trees, like folders and in every > folder contains the hash tree of a group of documents? > > ------ ------ | > | d1 | | d2 | | > ------ ------ | > | | | > And, in this side > | | | > the evenging hash tree > ------ ------ | > | h1 | | h2 | | > ------ ------ | > | | | > | | | > | | > -------- | > | h12 | | > -------- | > | | > | | > ------------ | > | TS12 | | > ------------ > > > I try to explain the best I can.. > > Thanks Tobias > > > > > > > > 2. Arity (number of branches at each node) of the hashtree: > > Actually the arity of the hash tree is not restricted by the ERS > standard and can be decided by the implementer. > > Several performance and efficiency tests I have seen, have shown that > typically a tertiary (or binary) hashtree offers the highest efficiency > and performance when handling larger numbers of documents. > > > > E.g. hashtree for about 2000 documents > > With tertiary: > > 2187 nodes on the lowest level > > 729 nodes on 2nd level > > 243 nodes on 3rd level > > 81 nodes on 4th level > > 27 nodes on 5th level > > 9 nodes on 6th level > > 3 nodes on 7th level > > And the timestamp at the top. > > > > That way the reduced ERS for one specific document is a lot smaller as > it does not need to contain all 2000 nodes of all neighbours, but a lot > less. > > > > Plus other operational parameters have also been more efficient. > > (Typically I would recommend a tertiary tree.) > > > > But if you like you can also use a tree with arity n, e.g. n=1000 or > n=1.000.000. > > > > Hope this helps, Tobias > > > > > > > > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org] > > > On Behalf Of Jesus Maria Mendez Perez > > > Sent: Thursday, November 22, 2007 6:48 PM > > > To: ietf-ltans@imc.org > > > Subject: ERS - using hash tree? > > > > > > > > > Hello, > > > > > > I´m Jesus and I don´t understand some aspects about using the > > > hash-tree to preserving data objects. > > > > > > According to ERS if you have 4 data objects the working will be the > next > > > one: > > > > > > ------ ------ ------ > --- > > > --- > > > | d1 | | d2 | | d3 | | > d4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | > | > > > ------ ------ ------ > --- > > > --- > > > | h1 | | h2 | | h3 | | > h4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | | > > > | | > > > -------- ------ > > > | h12 | | h34 | > > > -------- ------ > > > | | > > > | | > > > | > > > ----------- > > > | h1234 | > > > ----------- > > > | > > > -------------- > > > | TSh1234 | > > > -------------- > > > > > > where "d" are the data objects and "h" are the hash of the data > > > objects and "TS" is the timestamp. > > > > > > In this case you´ll have to do 7 hashes and the additional > timestamping. > > > > > > Then, what is the meaning of building the hash tree if you really > > > after of building it you can´t add or remove any data object?. > > > > > > You can simply add the 4 hashes of the 4 data objects and do the > finish > > > hash. > > > Then we´ll have to do 5 hashes and the additonal timestamping versus 7 > > > hashes we had before. > > > > > > ------ ------ ------ > --- > > > --- > > > | d1 | | d2 | | d3 | | d4 > | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | > | > > > ------ ------ ------ > --- > > > --- > > > | h1 | + | h2 | + | h3 | + | h4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | | > > > | | | | > > > ------------------------- > > > | h1234 | > > > ------------------------- > > > | > > > ---------------------------- > > > | TSh1234 | > > > --------------------------- > > > > > > I dont know if we could do it this last way or if i don´t understand > > > the processing of Generation and Verification at all.. > > > > > > Thanks. > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASEsTo5041415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 28 Nov 2007 07:54:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lASEsTYC041414; Wed, 28 Nov 2007 07:54:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASEsPq5041399 for <ietf-ltans@imc.org>; Wed, 28 Nov 2007 07:54:28 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lASEsFFg024929; Wed, 28 Nov 2007 15:54:15 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lASEsEln001959; Wed, 28 Nov 2007 09:54:14 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ERS - using hash tree? Date: Wed, 28 Nov 2007 15:54:13 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> In-Reply-To: <c58e154b0711270754k68004dbei7a89f473d511e244@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS - using hash tree? Thread-Index: AcgxDeBcRRyEdIbaQMS/+Q0bt5+ozwAvZRUA From: "Tobias Gondrom" <tgondrom@opentext.com> To: "Jesus Maria Mendez Perez" <jesusmmp@gmail.com> Cc: <ietf-ltans@imc.org> X-Archived: msg.Bv71uGR:2007-11-28:mucpm02.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lASEsTq5041407 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Hello Jesus, Hm, am not sure I understand your question completely, but let me explain a bit more about ERS. (if you like we can also talk in at the Vancouver meeting next week, or you can give me a short call, as this is maybe a lot easier in person or via phone.) However: Typically you will build one hashtree per time interval (e.g. lets say per day) for all your documents independent of how long you want to keep the individual documents. Lets say you get one day 2 groups of 3 documents each and a set of 5 individual documents (d1...d5). Then you would e.g. group them on the lowest level in four groups: group-1 group-2 and a generic group-3 (d-1, d2, d-3) and a generic group-4 (d4, d-5, hash(of null or random)) You get your timestamp and keep the whole ER until the last of the documents can be deleted. Let's look at the retention: Let's say d-1 passes its retention time first: then you delete d-1 normally. You leave the ER intact as it only contains the hash value of d-1 but not the document itself. If for the other documents a ERS is requested you send back the specific ER for this document. Personal comment: a few systems I know of actually do not care about the possible semantics of data object groups in ERS, but only look at the individual data objects. They just group the received data objects in binary ascending order and then bundle them together to groups (based on a system wide defined/customized arity of the hashtree). (you give away the advantage of the semantics of the data object group, but can parse and build the ER structures a lot faster as you always know the exact arity/group sizes on every level.) Hope this explains it a bit more. Tobias Ps.: can you maybe tell me a bit more about your goal: e.g. a verification tool would have to be much more flexible in respect to e.g. what arities and node geometry it accepts of ER hashtrees, compared to if you build a TAS, in which case you could e.g. define a fixed arity for your system generated trees, decide whether to offer users "data object groups" and other parameters of your system as you like. Pss.: I'll be at the IETF conf in Vancouver next week and back on Dec-10. So if you like you can give me a short call tomorrow, meet next week at the LTANS meeting, or call me after Dec-10th. __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler > -----Original Message----- > From: Jesus Maria Mendez Perez [mailto:jesusmmp@gmail.com] > Sent: Tuesday, November 27, 2007 4:55 PM > To: Tobias Gondrom > Cc: ietf-ltans@imc.org > Subject: Re: ERS - using hash tree? > > On Nov 22, 2007 7:27 PM, Tobias Gondrom <tgondrom@opentext.com> wrote: > > Hello Jesus, > > > > 1. > > > Then, what is the meaning of building the hash tree if you really > > > after of building it you can´t add or remove any data object?. > > > > Yes, after you completed the hashtree and protect it with a timestamp > you can not add further nodes. (Comment: Typical ERS-systems build one > hashtree per day for all documents that were archived during that day and > sign the hashtree every evening with a timestamp.) > > Then, if I want to preserve some documents in the same day, for > example 3, and to archive them during differents periods of time, the > first one (d1) until 01-12-07, the second (d2) until 15-12-07 and the > last one (d3) until 01-01-08 for example and I send independently to > the TAS server. > > How have they been manage? > What evidences are the TAS server archiving? > Has the TAS server to built 2 evidences? (first to preserve each > document separately (Fig 1)) > > ----- ------ -- > ---- > | d1 | | d2 | | > d3 | > ------ ------ > ------ > | | > | > | | > | > ------ ------- > ------ > | h1 | | h2 | | h3 | > ------ ----- > ------ > | | > | > ---------------- ------------------- > --------------------- > | TS(01-12-07) | | TS(15-12-07 | | TS(01-01-08) | > ------------------ ------------------- > -------------------- > Fig 1 > > and after that a second evidence to include them in the evening > hash-tree (Fig 2)? > Suppose another user, send during the same day the document > "anotherd4". In the same day only were sent d1,d2,d3 and anotherd4. > > ------ ------ ------ > --------------- > | d1 | | d2 | | d3 | | > anotherd4 | > ------ ------ ------ > ---------------- > | | | > | > | | | > | > ------ ------ ------ --- > --- > | h1 | | h2 | | h3 | | h4 | > ------ ------ ------ --- > --- > | | | > | > | | | | > | | > -------- ------ > | h12 | | h34 | > -------- ------ > | | > | | > | > ----------- > | h1234 | > ----------- > | > -------------- > | TSh1234 | > -------------- > Fig 2 > > > And what is the evening's timestamp during? > > > Another doubt: But then can I send a group of documents to preserving > and preserve it independently all other (Fig 3), (without including > them in the evening hash-tree)? > Can I decide what groups of documents form the evening-hash-tree? Can > the TAS server archive "little" hash-trees, like folders and in every > folder contains the hash tree of a group of documents? > > ------ ------ | > | d1 | | d2 | | > ------ ------ | > | | | > And, in this side > | | | > the evenging hash tree > ------ ------ | > | h1 | | h2 | | > ------ ------ | > | | | > | | | > | | > -------- | > | h12 | | > -------- | > | | > | | > ------------ | > | TS12 | | > ------------ > > > I try to explain the best I can.. > > Thanks Tobias > > > > > > > > 2. Arity (number of branches at each node) of the hashtree: > > Actually the arity of the hash tree is not restricted by the ERS > standard and can be decided by the implementer. > > Several performance and efficiency tests I have seen, have shown that > typically a tertiary (or binary) hashtree offers the highest efficiency > and performance when handling larger numbers of documents. > > > > E.g. hashtree for about 2000 documents > > With tertiary: > > 2187 nodes on the lowest level > > 729 nodes on 2nd level > > 243 nodes on 3rd level > > 81 nodes on 4th level > > 27 nodes on 5th level > > 9 nodes on 6th level > > 3 nodes on 7th level > > And the timestamp at the top. > > > > That way the reduced ERS for one specific document is a lot smaller as > it does not need to contain all 2000 nodes of all neighbours, but a lot > less. > > > > Plus other operational parameters have also been more efficient. > > (Typically I would recommend a tertiary tree.) > > > > But if you like you can also use a tree with arity n, e.g. n00 or > n=1.000.000. > > > > Hope this helps, Tobias > > > > > > > > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org] > > > On Behalf Of Jesus Maria Mendez Perez > > > Sent: Thursday, November 22, 2007 6:48 PM > > > To: ietf-ltans@imc.org > > > Subject: ERS - using hash tree? > > > > > > > > > Hello, > > > > > > I´m Jesus and I don´t understand some aspects about using the > > > hash-tree to preserving data objects. > > > > > > According to ERS if you have 4 data objects the working will be the > next > > > one: > > > > > > ------ ------ ------ > --- > > > --- > > > | d1 | | d2 | | d3 | | > d4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | > | > > > ------ ------ ------ > --- > > > --- > > > | h1 | | h2 | | h3 | | > h4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | | > > > | | > > > -------- ------ > > > | h12 | | h34 | > > > -------- ------ > > > | | > > > | | > > > | > > > ----------- > > > | h1234 | > > > ----------- > > > | > > > -------------- > > > | TSh1234 | > > > -------------- > > > > > > where "d" are the data objects and "h" are the hash of the data > > > objects and "TS" is the timestamp. > > > > > > In this case you´ll have to do 7 hashes and the additional > timestamping. > > > > > > Then, what is the meaning of building the hash tree if you really > > > after of building it you can´t add or remove any data object?. > > > > > > You can simply add the 4 hashes of the 4 data objects and do the > finish > > > hash. > > > Then we´ll have to do 5 hashes and the additonal timestamping versus 7 > > > hashes we had before. > > > > > > ------ ------ ------ > --- > > > --- > > > | d1 | | d2 | | d3 | | d4 > | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | > | > > > ------ ------ ------ > --- > > > --- > > > | h1 | + | h2 | + | h3 | + | h4 | > > > ------ ------ ------ > --- > > > --- > > > | | | > | > > > | | | | > > > | | | | > > > ------------------------- > > > | h1234 | > > > ------------------------- > > > | > > > ---------------------------- > > > | TSh1234 | > > > --------------------------- > > > > > > I dont know if we could do it this last way or if i don´t understand > > > the processing of Generation and Verification at all.. > > > > > > Thanks. > > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARFt1Xb055456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 27 Nov 2007 08:55:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lARFt1mu055455; Tue, 27 Nov 2007 08:55:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lARFt0vg055429 for <ietf-ltans@imc.org>; Tue, 27 Nov 2007 08:55:00 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so1439311waf for <ietf-ltans@imc.org>; Tue, 27 Nov 2007 07:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pNmpYnWQHBdA3cHvVYi1BsuyMlPLpj69kGPEHbwEs6M=; b=gOXqf+JA/LVYjNrOEiMfdJ0o0sKaNqGBynq6sciModvVZ78vFINFLcoblBT62JhOX4WacOvj8Iaq6ZZPUbry7I6qDIDVkYQCAxHb6MC46rr/O6QcTsXA9sKHEKIzO3/6QdYUjTpXHjGTFs112iqIEAbtSPYq0yvVnyoxtDPgWUMDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VGnKXQSCsyLqS21rsTxrt/dZ2qX6x44axC+gVbpBEBH6VETnfZFInjeB97Z/a/9rFKXgXu2nOYVW4J9PTpFTyp6BYPEjsMHWDr7mKPoWArrjBHYUEHu/lUFCXwqo5/HQ7yMPoL3ZTjZa1AYcf1YRXLmS5H6VG4MP484gZ+vIgekReceived: by 10.114.123.1 with SMTP id v1mr186164wac.1196178899837; Tue, 27 Nov 2007 07:54:59 -0800 (PST) Received: by 10.114.156.10 with HTTP; Tue, 27 Nov 2007 07:54:59 -0800 (PST) Message-ID: <c58e154b0711270754k68004dbei7a89f473d511e244@mail.gmail.com> Date: Tue, 27 Nov 2007 16:54:59 +0100 From: "Jesus Maria Mendez Perez" <jesusmmp@gmail.com> To: "Tobias Gondrom" <tgondrom@opentext.com> Subject: Re: ERS - using hash tree? Cc: ietf-ltans@imc.org In-Reply-To: <2666EB2A846BAC4BB2D7F593301A786801E0761F@MUCXGC2.opentext.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <c58e154b0711220948r7127d066n328dba170510dde6@mail.gmail.com> <2666EB2A846BAC4BB2D7F593301A786801E0761F@MUCXGC2.opentext.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lARFt1vg055449 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> On Nov 22, 2007 7:27 PM, Tobias Gondrom <tgondrom@opentext.com> wrote: > Hello Jesus, > > 1. > > Then, what is the meaning of building the hash tree if you really > > after of building it you can´t add or remove any data object?. > > Yes, after you completed the hashtree and protect it with a timestamp you can not add further nodes. (Comment: Typical ERS-systems build one hashtree per day for all documents that were archived during that day and sign the hashtree every evening with a timestamp.) Then, if I want to preserve some documents in the same day, for example 3, and to archive them during differents periods of time, the first one (d1) until 01-12-07, the second (d2) until 15-12-07 and the last one (d3) until 01-01-08 for example and I send independently to the TAS server. How have they been manage? What evidences are the TAS server archiving? Has the TAS server to built 2 evidences? (first to preserve each document separately (Fig 1)) ----- ------ ------ | d1 | | d2 | | d3 | ------ ------ ------ | | | | | | ------ ------- ------ | h1 | | h2 | | h3 | ------ ----- ------ | | | ---------------- ------------------- --------------------- | TS(01-12-07) | | TS(15-12-07 | | TS(01-01-08) | ------------------ ------------------- -------------------- Fig 1 and after that a second evidence to include them in the evening hash-tree (Fig 2)? Suppose another user, send during the same day the document "anotherd4". In the same day only were sent d1,d2,d3 and anotherd4. ------ ------ ------ --------------- | d1 | | d2 | | d3 | | anotherd4 | ------ ------ ------ ---------------- | | | | | | | | ------ ------ ------ ------ | h1 | | h2 | | h3 | | h4 | ------ ------ ------ ------ | | | | | | | | | | -------- ------ | h12 | | h34 | -------- ------ | | | | | ----------- | h1234 | ----------- | -------------- | TSh1234 | -------------- Fig 2 And what is the evening's timestamp during? Another doubt: But then can I send a group of documents to preserving and preserve it independently all other (Fig 3), (without including them in the evening hash-tree)? Can I decide what groups of documents form the evening-hash-tree? Can the TAS server archive "little" hash-trees, like folders and in every folder contains the hash tree of a group of documents? ------ ------ | | d1 | | d2 | | ------ ------ | | | | And, in this side | | | the evenging hash tree ------ ------ | | h1 | | h2 | | ------ ------ | | | | | | | | | -------- | | h12 | | -------- | | | | | ------------ | | TS12 | | ------------ I try to explain the best I can.. Thanks Tobias > > > 2. Arity (number of branches at each node) of the hashtree: > Actually the arity of the hash tree is not restricted by the ERS standard and can be decided by the implementer. > Several performance and efficiency tests I have seen, have shown that typically a tertiary (or binary) hashtree offers the highest efficiency and performance when handling larger numbers of documents. > > E.g. hashtree for about 2000 documents > With tertiary: > 2187 nodes on the lowest level > 729 nodes on 2nd level > 243 nodes on 3rd level > 81 nodes on 4th level > 27 nodes on 5th level > 9 nodes on 6th level > 3 nodes on 7th level > And the timestamp at the top. > > That way the reduced ERS for one specific document is a lot smaller as it does not need to contain all 2000 nodes of all neighbours, but a lot less. > > Plus other operational parameters have also been more efficient. > (Typically I would recommend a tertiary tree.) > > But if you like you can also use a tree with arity n, e.g. n00 or n=1.000.000. > > Hope this helps, Tobias > > > > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of Jesus Maria Mendez Perez > > Sent: Thursday, November 22, 2007 6:48 PM > > To: ietf-ltans@imc.org > > Subject: ERS - using hash tree? > > > > > > Hello, > > > > I´m Jesus and I don´t understand some aspects about using the > > hash-tree to preserving data objects. > > > > According to ERS if you have 4 data objects the working will be the next > > one: > > > > ------ ------ ------ --- > > --- > > | d1 | | d2 | | d3 | | d4 | > > ------ ------ ------ --- > > --- > > | | | | > > | | | | > > ------ ------ ------ --- > > --- > > | h1 | | h2 | | h3 | | h4 | > > ------ ------ ------ --- > > --- > > | | | | > > | | | | > > | | > > -------- ------ > > | h12 | | h34 | > > -------- ------ > > | | > > | | > > | > > ----------- > > | h1234 | > > ----------- > > | > > -------------- > > | TSh1234 | > > -------------- > > > > where "d" are the data objects and "h" are the hash of the data > > objects and "TS" is the timestamp. > > > > In this case you´ll have to do 7 hashes and the additional timestamping. > > > > Then, what is the meaning of building the hash tree if you really > > after of building it you can´t add or remove any data object?. > > > > You can simply add the 4 hashes of the 4 data objects and do the finish > > hash. > > Then we´ll have to do 5 hashes and the additonal timestamping versus 7 > > hashes we had before. > > > > ------ ------ ------ --- > > --- > > | d1 | | d2 | | d3 | | d4 | > > ------ ------ ------ --- > > --- > > | | | | > > | | | | > > ------ ------ ------ --- > > --- > > | h1 | + | h2 | + | h3 | + | h4 | > > ------ ------ ------ --- > > --- > > | | | | > > | | | | > > | | | | > > ------------------------- > > | h1234 | > > ------------------------- > > | > > ---------------------------- > > | TSh1234 | > > --------------------------- > > > > I dont know if we could do it this last way or if i don´t understand > > the processing of Generation and Verification at all.. > > > > Thanks. > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMIR9uc037174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 22 Nov 2007 11:27:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAMIR96I037173; Thu, 22 Nov 2007 11:27:09 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMIR7Vt037157 for <ietf-ltans@imc.org>; Thu, 22 Nov 2007 11:27:08 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lAMIR4KH016775; Thu, 22 Nov 2007 19:27:04 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lAMIR2NS031640; Thu, 22 Nov 2007 13:27:04 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ERS - using hash tree? Date: Thu, 22 Nov 2007 19:27:01 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801E0761F@MUCXGC2.opentext.net> In-Reply-To: <c58e154b0711220948r7127d066n328dba170510dde6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ERS - using hash tree? Thread-Index: AcgtMdCgc2PfYiYER+SOkmu0UKJu+wAAU1tw From: "Tobias Gondrom" <tgondrom@opentext.com> To: "Jesus Maria Mendez Perez" <jesusmmp@gmail.com> Cc: <ietf-ltans@imc.org> X-Archived: msg.BbOq0uu:2007-11-22:mucpm02.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAMIR9Vt037166 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Hello Jesus, 1. > Then, what is the meaning of building the hash tree if you really > after of building it you can´t add or remove any data object?. Yes, after you completed the hashtree and protect it with a timestamp you can not add further nodes. (Comment: Typical ERS-systems build one hashtree per day for all documents that were archived during that day and sign the hashtree every evening with a timestamp.) 2. Arity (number of branches at each node) of the hashtree: Actually the arity of the hash tree is not restricted by the ERS standard and can be decided by the implementer. Several performance and efficiency tests I have seen, have shown that typically a tertiary (or binary) hashtree offers the highest efficiency and performance when handling larger numbers of documents. E.g. hashtree for about 2000 documents With tertiary: 2187 nodes on the lowest level 729 nodes on 2nd level 243 nodes on 3rd level 81 nodes on 4th level 27 nodes on 5th level 9 nodes on 6th level 3 nodes on 7th level And the timestamp at the top. That way the reduced ERS for one specific document is a lot smaller as it does not need to contain all 2000 nodes of all neighbours, but a lot less. Plus other operational parameters have also been more efficient. (Typically I would recommend a tertiary tree.) But if you like you can also use a tree with arity n, e.g. n00 or n=1.000.000. Hope this helps, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Jesus Maria Mendez Perez > Sent: Thursday, November 22, 2007 6:48 PM > To: ietf-ltans@imc.org > Subject: ERS - using hash tree? > > > Hello, > > I´m Jesus and I don´t understand some aspects about using the > hash-tree to preserving data objects. > > According to ERS if you have 4 data objects the working will be the next > one: > > ------ ------ ------ --- > --- > | d1 | | d2 | | d3 | | d4 | > ------ ------ ------ --- > --- > | | | | > | | | | > ------ ------ ------ --- > --- > | h1 | | h2 | | h3 | | h4 | > ------ ------ ------ --- > --- > | | | | > | | | | > | | > -------- ------ > | h12 | | h34 | > -------- ------ > | | > | | > | > ----------- > | h1234 | > ----------- > | > -------------- > | TSh1234 | > -------------- > > where "d" are the data objects and "h" are the hash of the data > objects and "TS" is the timestamp. > > In this case you´ll have to do 7 hashes and the additional timestamping. > > Then, what is the meaning of building the hash tree if you really > after of building it you can´t add or remove any data object?. > > You can simply add the 4 hashes of the 4 data objects and do the finish > hash. > Then we´ll have to do 5 hashes and the additonal timestamping versus 7 > hashes we had before. > > ------ ------ ------ --- > --- > | d1 | | d2 | | d3 | | d4 | > ------ ------ ------ --- > --- > | | | | > | | | | > ------ ------ ------ --- > --- > | h1 | + | h2 | + | h3 | + | h4 | > ------ ------ ------ --- > --- > | | | | > | | | | > | | | | > ------------------------- > | h1234 | > ------------------------- > | > ---------------------------- > | TSh1234 | > --------------------------- > > I dont know if we could do it this last way or if i don´t understand > the processing of Generation and Verification at all.. > > Thanks. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMHmP6e033873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 22 Nov 2007 10:48:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAMHmPAd033872; Thu, 22 Nov 2007 10:48:25 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAMHmO1b033865 for <ietf-ltans@imc.org>; Thu, 22 Nov 2007 10:48:24 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so1471071wra for <ietf-ltans@imc.org>; Thu, 22 Nov 2007 09:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s¾ta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=mmk/WOOeRGKUTn7gJCkF6Y95XRuJZuzq/HY4uu4+jEY=; b=HkQdqRHcvG2jAfjfSX+6IeBUTs98thf4jU/Xoc6ya/8pXMKL72Kdueo3yVBRGEwQqKCE9Nq5oyl4MJ4V03hKL7Ny88UIE9uXmWzXT8qQu37fPkAcKq7V+KiFGIju87UblOEELJR2Fe+YTifFTId+97J6+oH/9C5JdWd1vK98IzYDomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s¾ta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fpRkS3YFlhWIfXoqcy+K+vvhMJmTcKhPTa1OkW2wYZkqi/NcTOpAcBkSg5QHyNc6vRZ8JMxJwZMiGaawKPjte78HrKPEYQ4oFJsmRh5wluctY1BbjZzmDLdVYMXW8CEl+JTXddIjI+lTMI3+kApou5DPXUUOpBqcMTslqCYbQ8oReceived: by 10.115.107.1 with SMTP id j1mr14023wam.1195753701984; Thu, 22 Nov 2007 09:48:21 -0800 (PST) Received: by 10.114.156.10 with HTTP; Thu, 22 Nov 2007 09:48:21 -0800 (PST) Message-ID: <c58e154b0711220948r7127d066n328dba170510dde6@mail.gmail.com> Date: Thu, 22 Nov 2007 18:48:21 +0100 From: "Jesus Maria Mendez Perez" <jesusmmp@gmail.com> To: ietf-ltans@imc.org Subject: ERS - using hash tree? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lAMHmO1b033867 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> Hello, I´m Jesus and I don´t understand some aspects about using the hash-tree to preserving data objects. According to ERS if you have 4 data objects the working will be the next one: ------ ------ ------ ------ | d1 | | d2 | | d3 | | d4 | ------ ------ ------ ------ | | | | | | | | ------ ------ ------ ------ | h1 | | h2 | | h3 | | h4 | ------ ------ ------ ------ | | | | | | | | | | -------- ------ | h12 | | h34 | -------- ------ | | | | | ----------- | h1234 | ----------- | -------------- | TSh1234 | -------------- where "d" are the data objects and "h" are the hash of the data objects and "TS" is the timestamp. In this case you´ll have to do 7 hashes and the additional timestamping. Then, what is the meaning of building the hash tree if you really after of building it you can´t add or remove any data object?. You can simply add the 4 hashes of the 4 data objects and do the finish hash. Then we´ll have to do 5 hashes and the additonal timestamping versus 7 hashes we had before. ------ ------ ------ ------ | d1 | | d2 | | d3 | | d4 | ------ ------ ------ ------ | | | | | | | | ------ ------ ------ ------ | h1 | + | h2 | + | h3 | + | h4 | ------ ------ ------ ------ | | | | | | | | | | | | ------------------------- | h1234 | ------------------------- | ---------------------------- | TSh1234 | --------------------------- I dont know if we could do it this last way or if i don´t understand the processing of Generation and Verification at all.. Thanks. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGCCi1004070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 20 Nov 2007 09:12:12 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKGCCDH004069; Tue, 20 Nov 2007 09:12:12 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKGCAv1004059 for <ietf-ltans@imc.org>; Tue, 20 Nov 2007 09:12:11 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lAKGC7Cu001498; Tue, 20 Nov 2007 17:12:07 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lAKGC6HZ017695; Tue, 20 Nov 2007 11:12:06 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82B90.182878E0" Subject: LTANS meeting in Vancouver - agenda items Date: Tue, 20 Nov 2007 17:12:05 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801E07229@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS meeting in Vancouver - agenda items Thread-Index: AcgrkBfju53AwzGSQpSPMCY3v01sQw= X-Priority: 1 Importance: high From: "Tobias Gondrom" <tgondrom@opentext.com> To: <ietf-ltans@imc.org> Cc: "Carl Wallace" <CWallace@cygnacom.com> X-Archived: msg.AymKjyY:2007-11-20:mucpm01.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C82B90.182878E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, Carl and myself have to prepare the agenda for our meeting in Vancouver. So if you have any proposals for items, please contact Carl and me until the end of this week (Nov-23). Please provide item name, requested time and speaker name. If you have a presentation, but can not attend in person, we can also offer to find s.o. to present on your behalf (while you attend via audio and jabber). My current draft agenda (still searching for a few presenter names) looks like this: 0. org stuff 1. ers-scvp - final status 2. dssc - status and final feedback, WG LC? 3. ltap - status 4. ersxml - status 5. validate - status and feedback Hopefully we will be able to finish ers-scvp and dssc in Vancouver and make significant progress on the other drafts. Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C82B90.182878E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59"> <TITLE>LTANS meeting in Vancouver - agenda items</TITLE> </HEAD> <BODY> <!-- Converted from text/rtf format --> <P ALIGN=LEFT><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Hello all, </FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Carl and myself</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> have to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">prepare</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> the agenda for our meeting in Vancouver.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">So if you have any proposal</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">s</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> for items, please contact Carl and me until the end of this week (Nov-</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">23). </FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Please provide i</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">tem</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> name</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">, requested time and speaker name.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">If you have a presentation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> but can not attend in person, we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">can</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> also</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">offer to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">find s.o. to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">present on your behalf</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> (while you attend via audio and jabber).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">My current draft</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">agenda</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">(still searching for</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> a few</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">presenter names)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> looks like this</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">0. org stuff</FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">1.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ers-scvp</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">–</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> final status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">2.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">dssc -</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">status and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">final</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">feedback</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">, WG LC?</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">3.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> ltap</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">–</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">4.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ersxml</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> - status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">5.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> validate</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">–</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> status and feedback</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">H</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">opefully we will be able to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">finish</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ers-scvp and dssc i</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">n</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> Va</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">n</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">couver</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> and make significant progress on the other</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> drafts</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Tobias</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P> <BR> <BR> <P ALIGN=LEFT><B><SPAN LANG="de-de"></SPAN></B><A NAME=""><B><SPAN LANG="de-de"><FONT SIZE=2 FACE="Arial">__________________________________________</FONT></SPAN></B></A><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR> </SPAN><SPAN LANG="de"><B></B></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Tobias Gondrom</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR> </SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Head of Open Text Security Team<BR> Director, Product Security<BR> </FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR> </SPAN><SPAN LANG="de"><B></B></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Open Text</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR> </SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000">Technopark 2<BR> Werner-von-Siemens-Ring 20<BR> D-85630 Grasbrunn</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR> </SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"></SPAN></P> <P ALIGN=LEFT><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Phone: +49 (0) 89 4629-1816<BR> Mobile: +49 (0) 173 5942987<BR> Telefax: +49 (0) 89 4629-33-1816<BR> eMail:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"> <FONT SIZE=2 FACE="Arial"><A HREF="mailto:tobias.gondrom@opentext.com">mailto:tobias.gondrom@opentext.com</A><BR> </FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Internet:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"> <FONT SIZE=2 FACE="Arial"><A HREF="http://www.opentext.com/">http://www.opentext.com/</A> </FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="de-de"><FONT SIZE=1 FACE="Arial">Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler</FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="de-de"><FONT SIZE=1 FACE="Arial">This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.</FONT></SPAN></P> <P ALIGN=LEFT><SPAN LANG="en-gb"></SPAN></P> </BODY> </HTML> ------_=_NextPart_001_01C82B90.182878E0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAKD2Uak086543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Tue, 20 Nov 2007 06:02:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAKD2Uhf086542; Tue, 20 Nov 2007 06:02:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAKD2SNf086531 for <ietf-ltans@imc.org>; Tue, 20 Nov 2007 06:02:29 -0700 (MST) (envelope-from Internet-Drafts@ietf.org) Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2a474307da; Tue, 20 Nov 2007 21:15:27 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmc473dfd2b; Sat, 17 Nov 2007 03:14:29 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 17 Nov 2007 03:14:29 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5x8-00080C-K3; Fri, 16 Nov 2007 13:30:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5x5-0007wu-Cy for i-d-announce@ietf.org; Fri, 16 Nov 2007 13:30:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It5x4-0005PM-Vk for i-d-announce@ietf.org; Fri, 16 Nov 2007 13:30:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 97A1C1759E; Fri, 16 Nov 2007 18:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It5x4-0005Nf-53; Fri, 16 Nov 2007 13:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1It5x4-0005Nf-53@stiedprstage1.ietf.org> Date: Fri, 16 Nov 2007 13:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ietf-ltans@imc.org Subject: I-D Action:draft-ietf-ltans-ers-scvp-05.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/i-d-announce> List-Post: <mailto:i-d-announce@ietf.org> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --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-05.txt Pages : 17 Date : 2007-11-16 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 in the certificates can be established 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-05.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-05.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-05.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: <2007-11-16132804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16132804.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGIU40o014151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 16 Nov 2007 11:30:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAGIU4Qj014150; Fri, 16 Nov 2007 11:30:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGIU3nj014133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <ietf-ltans@imc.org>; Fri, 16 Nov 2007 11:30:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 97A1C1759E; Fri, 16 Nov 2007 18:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It5x4-0005Nf-53; Fri, 16 Nov 2007 13:30:02 -0500 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-05.txt Message-Id: <E1It5x4-0005Nf-53@stiedprstage1.ietf.org> Date: Fri, 16 Nov 2007 13:30:02 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --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-05.txt Pages : 17 Date : 2007-11-16 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 in the certificates can be established 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-05.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-05.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-05.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: <2007-11-16132804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16132804.I-D\@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGISSW0013948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 16 Nov 2007 11:28:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAGISShU013946; Fri, 16 Nov 2007 11:28:28 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lAGISOcd013937 for <ietf-ltans@imc.org>; Fri, 16 Nov 2007 11:28:27 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 16953 invoked from network); 16 Nov 2007 18:23:09 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;16 Nov 2007 18:23:09 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 16 Nov 2007 18:23:08 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <L49PJVCW>; Fri, 16 Nov 2007 13:28:22 -0500 Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48149590@scygexch1.cygnacom.com> From: Carl Wallace <CWallace@cygnacom.com> To: ietf-ltans@imc.org, Tobias Gondrom <tgondrom@opentext.com> Subject: RE: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions Date: Fri, 16 Nov 2007 13:28:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8287E.727CFCC3" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C8287E.727CFCC3 Content-Type: text/plain Thanks for the thorough review Tobias. I made almost all of the changes you recommended. Responses are in line below. I posted a new draft immediately because the deadline is so soon. I can post a follow-up after the IETF meeting if there're any additional changes required. _____ From: Tobias Gondrom [mailto:tgondrom@opentext.com] Sent: Wednesday, November 14, 2007 1:55 PM To: Carl Wallace Cc: ietf-ltans@imc.org Subject: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions Hello Carl, thank you very much for the update. To prepare for the next finishing steps of ers-scvp (to go to IETF LC), I also did a last review again and would propose just a few small editorial changes. Don't be shocked by the number of 18 items, it's all just very minor wording things and three questions rather for my own personal understanding. I like the draft very much and think it will be ready for IETF LC. Please consider my comments below only as suggestions. 1. in the Abstract: Old: "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." Should this be changed to: "Evidence records can be used to preserve materials that comprise a certification path, such that trust in the certificates can be established 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." [CRW] Fixed 2. Section 1 Introduction: first paragraph Should it be? s/When verifying digital signatures many/To verify digital signatures many [CRW] Fixed 3. Section 1 Introduction: second paragraph s/server for the purposes of preserving evidence records/server for the purpose of preserving evidence records [CRW] Fixed 4. section 2: list after second paragraph The list covers two items where I wonder if they should not be slightly reworded? Old: "- certification paths containing end entity certificates through trust anchors - certification paths containing intermediate certificates through trust anchors" New: "- certification paths containing end entity certificates up to their trust anchors - certification paths containing intermediate certificates up to their trust anchors" [CRW] Changed using slightly different wording. "containing an end entity certificate up to a trust anchor" and similar for intermediate bullet. 5. section 2: list at end of section: s/- SCVP server returns a response with status as of time of interest and including requested evidence records/- SCVP server returns a response with status as of time of interest and includes requested evidence records [CRW] Fixed 6. section 3: second paragraph: s/CA who issued the end entity certificate through a trust anchor/CA who issued the end entity certificate up to its trust anchor/ [CRW] I didn't change this one. Paths may exist from the end entity certificate to more than one trust anchor. 7. section 4: first paragraph: This is just a proposal/question whether it might be better??? But maybe a "MUST" is too strong here? s/For id-swb-ers-pkc-cert, the evidence record is calculated over the value of the cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object. And maybe also a "MUST" instead of the "is" in the sentence following this one? [CRW] I agree. Changed to MUST. Changed both of the instances you cited plus one more in the best-cert-path section. 8. section 4: second paragraph: s/If the server can not return an EvidenceRecord for the requested information/If the server can not return an EvidenceRecord for the requested information item [CRW] Fixed 9.section 4: second paragraph: And this is only a personal question just for my understanding: Is the "empty field" sufficient compared to a possible field value e.g. "Not available". Could there be cases where an "empty field" can result and not mean the value can not be provided, e.g. value is unclear or undefined? But probably this is a quite theoretical question? [CRW] I think the current text is sufficient. The reply will either have an evidence record or it won't. Since the field is a non-optional OCTET STRING, empty is used when no evidence record is available. 10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4 These paragraphs all state analogue to "Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path." Question: What happens if not both are in the request but only "id-swb-ers-best-cert-path"? [CRW] I added the following to the beginning of section 5: Each wantBack for an evidence record requires a corresponding wantBack for the object covered by the evidence record to be present in the request. Upon receipt of a request missing the corresponding wantBack for the object covered by a requested evidence record, the server MUST indicate wantBackUnsatisfied in the ReplyStatus. Clients MAY ignore evidence record wantBacks when the wantBack for the corresponding object is not present. 11. section 5.4: title: s/Evidence record for a revocation information/Evidence record for revocation information [CRW] Fixed 12. section 5.4: second paragraph: And again a personal question for my understanding. (Probably I just miss the point?) Why can the generation of cumulative CRLs simplify the maintenance of evidence records? [CRW] It helps by avoiding the need to hang on to all CRLs. An archive could simply maintain the final CRL generated by a CA provided it contained expired certs. 13. section 5.5: first paragraph: s/all information returned via in the replyWantBacks field/all information returned via the replyWantBacks field [CRW] Fixed 14. section 5.5: last paragraph: s/indicates the type of replyWantBack is covered by the associated EvidenceRecord./indicates the type of replyWantBack covered by the associated EvidenceRecord. [CRW] Fixed 15. section 5.5: last paragraph: s/does not have an EvidenceRecord for particular replyWantBack object/does not have an EvidenceRecord for a particular replyWantBack object [CRW] Fixed 16. section 5.6: first paragraph: I am not sure I understand the first two sentences: "The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is the only OID defined in this document for which an EvidenceRecord is not returned in the response." This sounds to me like a contradiction to section 5.2 which I understood that an Evidence record to be returned in the response??? [CRW] Section 5.2 discusses the id-swb-ers-partial-cert-path wantBack, which corresponds to the id-swb-partial-cert-path wantBack. id-swb-partial-cert-path returns a CertBundle and id-swb-ers-partial-cert-path returns an EvidenceRecord. 17. section 5.6: second paragraph: Is this a spelling mistake? s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can include id-swb-partial-cert-path [CRW] Fixed. 18. section 6: second paragraph: Should this be a capital "SHOULD" in the sense of RFC2119? s/Relying parties should ignore trust anchors contained in unsigned SCVP responses./Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses. [CRW] Fixed. Thanks, Tobias _____ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, November 08, 2007 7:01 PM To: ietf-ltans@imc.org Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack. > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org <mailto:idsubmission@ietf.org> ] > Sent: Thursday, November 08, 2007 12:52 PM > To: cwallace@cygnacom.com > Cc: ietf-ltans@imc.org > Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 > > > A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has > been successfuly submitted by Carl Wallace and posted to the > IETF repository. > > Filename: draft-ietf-ltans-ers-scvp > Revision: 04 > Title: Using SCVP to Convey Long-term Evidence Records > Creation_date: 2007-11-08 > WG ID: ltans > Number_of_pages: 18 > > Abstract: > 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. > > > > > The IETF Secretariat. > > ------_=_NextPart_001_01C8287E.727CFCC3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word"><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <TITLE>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04</TITLE> <META content="MSHTML 6.00.2900.3199" name=GENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: Tahoma; } @page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm 70.85pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: blue; TEXT-DECORATION: underline } P { FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto } SPAN.EmailStyle18 { COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=DE vLink=blue link=blue> <DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN class=346395911-16112007>Thanks for the thorough review Tobias. I made almost all of the changes you recommended. Responses are in line below. I posted a new draft immediately because the deadline is so soon. I can post a follow-up after the IETF meeting if there're any additional changes required. </SPAN></FONT></DIV><BR> <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left> <HR tabIndex=-1> <FONT face=Tahoma size=2><B>From:</B> Tobias Gondrom [mailto:tgondrom@opentext.com] <BR><B>Sent:</B> Wednesday, November 14, 2007 1:55 PM<BR><B>To:</B> Carl Wallace<BR><B>Cc:</B> ietf-ltans@imc.org<BR><B>Subject:</B> draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=Section1> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hello Carl, <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">thank you very much for the update.<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">To prepare for the next finishing steps of ers-scvp (to go to IETF LC), I also did a last review again and would propose just a few small editorial changes. <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Don’t be shocked by the number of 18 items, it’s all just very minor wording things and three questions rather for my own personal understanding. <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I like the draft very much and think it will be ready for IETF LC. Please consider my comments below only as suggestions. <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1. in the Abstract: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Old: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“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.”<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should this be changed to: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“Evidence records can be used to preserve materials that comprise a certification path, such that trust in the certificates can be established 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.”<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">2. Section 1 Introduction: first paragraph<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should it be?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/When verifying digital signatures many/To verify digital signatures many<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></FONT></P> <P class=MsoNormal> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">3. Section 1 Introduction: second paragraph<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/server for the purposes of preserving evidence records/server for the purpose of preserving evidence records<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></FONT></P></o:p></SPAN></FONT> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">4. section 2: list after second paragraph <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The list covers two items where I wonder if they should not be slightly reworded?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Old: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“- certification paths containing end entity certificates through trust anchors<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- certification paths containing intermediate certificates through trust anchors”<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">New: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“- certification paths containing end entity certificates up to their trust anchors<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- certification paths containing intermediate certificates up to their trust anchors”<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Changed using slightly different wording. "containing an end entity certificate up to a trust anchor" and similar for intermediate bullet.</SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">5. section 2: list at end of section: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/- SCVP server returns a response with status as of time of interest and including requested evidence records/- SCVP server returns a response with status as of time of interest and includes requested evidence records<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></FONT></P></SPAN><o:p></o:p></FONT></SPAN></FONT> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">6. section 3: second paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/CA who issued the end entity certificate through a trust anchor/CA who issued the end entity certificate up to its trust anchor/<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] I didn't change this one. Paths may exist from the end entity certificate to more than one trust anchor. </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">7. section 4: first paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This is just a proposal/question whether it might be better??? But maybe a “MUST” is too strong here?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/For id-swb-ers-pkc-cert, the evidence record is calculated over the value of the cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object.<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And maybe also a “MUST” instead of the “is” in the sentence following this one?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN class=346395911-16112007><FONT color=#0000ff>[CRW] I agree. Changed to MUST.</FONT></SPAN> <SPAN class=346395911-16112007><FONT color=#0000ff> Changed both of the instances you cited plus one more in the best-cert-path section. </FONT></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">8. section 4: second paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/If the server can not return an EvidenceRecord for the requested information/If the server can not return an EvidenceRecord for the requested information item<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">9.section 4: second paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And this is only a personal question just for my understanding: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is the “empty field” sufficient compared to a possible field value e.g. “Not available”. Could there be cases where an “empty field” can result and not mean the value can not be provided, e.g. value is unclear or undefined? But probably this is a quite theoretical question?<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] I think the current text is sufficient. The reply will either have an evidence record or it won't. Since the field is a non-optional OCTET STRING, empty is used when no evidence record is available. </SPAN><o:p></o:p></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">These paragraphs all state analogue to <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path.”<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Question: What happens if not both are in the request but only “id-swb-ers-best-cert-path”?<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] I added the following to the beginning of section 5:</SPAN></FONT></SPAN></FONT></P><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN class=346395911-16112007><FONT color=#0000ff size=2><FONT size=2> <P>Each wantBack for an evidence record requires a corresponding wantBack for the object covered by the evidence record to be present in the request. Upon receipt of a request missing the corresponding wantBack for the object covered by a requested evidence record, the server MUST indicate wantBackUnsatisfied in the ReplyStatus. Clients MAY ignore evidence record wantBacks when the wantBack for the corresponding object is not present.</P></FONT><SPAN class=346395911-16112007><FONT face=Arial size=2><FONT size=2></FONT></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">11. section 5.4: title:<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/Evidence record for a revocation information/Evidence record for revocation information<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">12. section 5.4: second paragraph:<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And again a personal question for my understanding. (Probably I just miss the point?)<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Why can the generation of cumulative CRLs simplify the maintenance of evidence records?<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] It helps by avoiding the need to hang on to all CRLs. An archive could simply maintain the final CRL generated by a CA provided it contained expired certs. </SPAN><o:p></o:p></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">13. section 5.5: first paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/all information returned via in the replyWantBacks field/all information returned via the replyWantBacks field<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">14. section 5.5: last paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/indicates the type of replyWantBack is covered by the associated EvidenceRecord./indicates the type of replyWantBack covered by the associated EvidenceRecord.<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">15. section 5.5: last paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/does not have an EvidenceRecord for particular replyWantBack object/does not have an EvidenceRecord for a particular replyWantBack object<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> <SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Fixed </SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">16. section 5.6: first paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I am not sure I understand the first two sentences: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">“The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is the only OID defined in this document for which an EvidenceRecord is not returned in the response.”<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This sounds to me like a contradiction to section 5.2 which I understood that an Evidence record to be returned in the response???<FONT color=#0000ff><SPAN class=346395911-16112007> </SPAN></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007></SPAN></FONT></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT color=#0000ff><SPAN class=346395911-16112007>[CRW] Section 5.2 discusses the id-swb-ers-partial-cert-path wantBack, which corresponds to the <FONT color=#000080> id-swb-partial-cert-path wantBack. id-swb-partial-cert-path returns a CertBundle and </FONT><FONT color=#0000ff>id-swb-ers-partial-cert-path returns an EvidenceRecord. </FONT></P> <P class=MsoNormal> </SPAN><o:p></o:p></FONT></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">17. section 5.6: second paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is this a spelling mistake?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can include id-swb-partial-cert-path<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN class=346395911-16112007><FONT color=#0000ff>[CRW] Fixed.</FONT></SPAN> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT> </P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">18. section 6: second paragraph: <o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should this be a capital “SHOULD” in the sense of RFC2119?<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/Relying parties should ignore trust anchors contained in unsigned SCVP responses./Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses.<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN class=346395911-16112007><FONT color=#0000ff>[CRW] Fixed.</FONT></SPAN> </o:p></SPAN></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks, Tobias<o:p></o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p> </o:p></SPAN></FONT></P> <DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none"> <DIV> <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt"> <HR tabIndex=-1 align=center width="100%" SIZE=2> </SPAN></FONT></DIV> <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN lang=EN-US style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT face=Tahoma size=2><SPAN lang=EN-US style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] <B><SPAN style="FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Carl Wallace<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, November 08, 2007 7:01 PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> ietf-ltans@imc.org<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </SPAN></FONT><SPAN lang=EN-US><o:p></o:p></SPAN></P></DIV> <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN style="FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack.</SPAN></FONT><o:p></o:p></P> <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">> -----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> From: IETF I-D Submission Tool [<A href="mailto:idsubmission@ietf.org">mailto:idsubmission@ietf.org</A>] </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Sent: Thursday, November 08, 2007 12:52 PM</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> To: cwallace@cygnacom.com</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Cc: ietf-ltans@imc.org</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> been successfuly submitted by Carl Wallace and posted to the </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> IETF repository.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Filename: draft-ietf-ltans-ers-scvp</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Revision: 04</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Title: Using SCVP to Convey Long-term Evidence Records</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Creation_date: 2007-11-08</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> WG ID: ltans</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Number_of_pages: 18</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Abstract:</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> The Simple Certificate Validation Protocol (SCVP) defines an </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> extensible means of delegating the development and validation </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> of certification paths to a server. It can be used to </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> support the development and validation of certification paths </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> well after the expiration of the certificates in the path by </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> specifying a time of interest in the past. The Evidence </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Record Syntax (ERS) defines structures, called evidence </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> records, to support non-repudiation of existence of data. </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> Evidence records can be used to preserve materials that </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> comprise a certification path such that trust can be </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> established in the certificates after the expiration of the </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> certificates in the path and after the cryptographic </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> algorithms used to sign the certificates in the path are no </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> longer secure. This document describes an application of </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> SCVP to serve this purpose using the WantBack feature of SCVP </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> to convey evidence records.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> The IETF Secretariat.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">> </SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C8287E.727CFCC3-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGGU3An003334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Fri, 16 Nov 2007 09:30:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAGGU3QQ003333; Fri, 16 Nov 2007 09:30:03 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAGGU2q3003326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <ietf-ltans@imc.org>; Fri, 16 Nov 2007 09:30:02 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 16C9F2AC7C; Fri, 16 Nov 2007 16:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1It44v-0000DC-Rp; Fri, 16 Nov 2007 11:30:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-validate-02.txt Message-Id: <E1It44v-0000DC-Rp@stiedprstage1.ietf.org> Date: Fri, 16 Nov 2007 11:30:01 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Validation and long term verification data for Evidence Records and signed documents Author(s) : T. Gondrom Filename : draft-ietf-ltans-validate-02.txt Pages : 11 Date : 2007-11-16 Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-validate-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-validate-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-validate-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. --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: <2007-11-16112204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-validate-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-validate-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-16112204.I-D\@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEItI4E057924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 14 Nov 2007 11:55:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lAEItI7j057923; Wed, 14 Nov 2007 11:55:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lAEItD49057914 for <ietf-ltans@imc.org>; Wed, 14 Nov 2007 11:55:17 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lAEIt9G3016034; Wed, 14 Nov 2007 19:55:10 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lAEIt8OK009974; Wed, 14 Nov 2007 13:55:08 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C826EF.DE95B6B0" Subject: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions Date: Wed, 14 Nov 2007 19:55:04 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801E06B16@MUCXGC2.opentext.net> In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D481491A7@scygexch1.cygnacom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions Thread-Index: AcgiM08Qp6/S9AYFR4GZhNA+McdXxgEtgjEQ From: "Tobias Gondrom" <tgondrom@opentext.com> To: "Carl Wallace" <CWallace@cygnacom.com> Cc: <ietf-ltans@imc.org> X-Archived: msg.Avv2GZA:2007-11-14:mucpm01.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This is a multi-part message in MIME format. ------_=_NextPart_001_01C826EF.DE95B6B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Carl, thank you very much for the update. To prepare for the next finishing steps of ers-scvp (to go to IETF LC), I also did a last review again and would propose just a few small editorial changes. Don't be shocked by the number of 18 items, it's all just very minor wording things and three questions rather for my own personal understanding. I like the draft very much and think it will be ready for IETF LC. Please consider my comments below only as suggestions. 1. in the Abstract: Old: "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." Should this be changed to: "Evidence records can be used to preserve materials that comprise a certification path, such that trust in the certificates can be established 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." 2. Section 1 Introduction: first paragraph Should it be? s/When verifying digital signatures many/To verify digital signatures many 3. Section 1 Introduction: second paragraph s/server for the purposes of preserving evidence records/server for the purpose of preserving evidence records 4. section 2: list after second paragraph The list covers two items where I wonder if they should not be slightly reworded? Old: "- certification paths containing end entity certificates through trust anchors - certification paths containing intermediate certificates through trust anchors" New: "- certification paths containing end entity certificates up to their trust anchors - certification paths containing intermediate certificates up to their trust anchors" 5. section 2: list at end of section: s/- SCVP server returns a response with status as of time of interest and including requested evidence records/- SCVP server returns a response with status as of time of interest and includes requested evidence records 6. section 3: second paragraph: s/CA who issued the end entity certificate through a trust anchor/CA who issued the end entity certificate up to its trust anchor/ 7. section 4: first paragraph: This is just a proposal/question whether it might be better??? But maybe a "MUST" is too strong here? s/For id-swb-ers-pkc-cert, the evidence record is calculated over the value of the cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object. And maybe also a "MUST" instead of the "is" in the sentence following this one? 8. section 4: second paragraph: s/If the server can not return an EvidenceRecord for the requested information/If the server can not return an EvidenceRecord for the requested information item 9.section 4: second paragraph: And this is only a personal question just for my understanding: Is the "empty field" sufficient compared to a possible field value e.g. "Not available". Could there be cases where an "empty field" can result and not mean the value can not be provided, e.g. value is unclear or undefined? But probably this is a quite theoretical question? 10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4 These paragraphs all state analogue to "Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path." Question: What happens if not both are in the request but only "id-swb-ers-best-cert-path"? 11. section 5.4: title: s/Evidence record for a revocation information/Evidence record for revocation information 12. section 5.4: second paragraph: And again a personal question for my understanding. (Probably I just miss the point?) Why can the generation of cumulative CRLs simplify the maintenance of evidence records? 13. section 5.5: first paragraph: s/all information returned via in the replyWantBacks field/all information returned via the replyWantBacks field 14. section 5.5: last paragraph: s/indicates the type of replyWantBack is covered by the associated EvidenceRecord./indicates the type of replyWantBack covered by the associated EvidenceRecord. 15. section 5.5: last paragraph: s/does not have an EvidenceRecord for particular replyWantBack object/does not have an EvidenceRecord for a particular replyWantBack object 16. section 5.6: first paragraph: I am not sure I understand the first two sentences: "The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is the only OID defined in this document for which an EvidenceRecord is not returned in the response." This sounds to me like a contradiction to section 5.2 which I understood that an Evidence record to be returned in the response??? 17. section 5.6: second paragraph: Is this a spelling mistake? s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can include id-swb-partial-cert-path 18. section 6: second paragraph: Should this be a capital "SHOULD" in the sense of RFC2119? s/Relying parties should ignore trust anchors contained in unsigned SCVP responses./Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses. Thanks, Tobias ________________________________ From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Carl Wallace Sent: Thursday, November 08, 2007 7:01 PM To: ietf-ltans@imc.org Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack. > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, November 08, 2007 12:52 PM > To: cwallace@cygnacom.com > Cc: ietf-ltans@imc.org > Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 > > > A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has > been successfuly submitted by Carl Wallace and posted to the > IETF repository. > > Filename: draft-ietf-ltans-ers-scvp > Revision: 04 > Title: Using SCVP to Convey Long-term Evidence Records > Creation_date: 2007-11-08 > WG ID: ltans > Number_of_pages: 18 > > Abstract: > 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. > > > > > The IETF Secretariat. > > ------_=_NextPart_001_01C826EF.DE95B6B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </title> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:595.3pt 841.9pt; margin:70.85pt 70.85pt 2.0cm 70.85pt;} div.Section1 {page:Section1;} --> </style> </head> <body lang=DE link=blue vlink=blue> <div class=Section1> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'>Hello Carl, <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size: 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>thank you very much for the update.<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>To prepare for the next finishing steps of ers-scvp (to go to IETF LC), I also did a last review again and would propose just a few small editorial changes. <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Don’t be shocked by the number of 18 items, it’s all just very minor wording things and three questions rather for my own personal understanding. <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>I like the draft very much and think it will be ready for IETF LC. Please consider my comments below only as suggestions. <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>1. in the Abstract: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Old: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“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.”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Should this be changed to: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“Evidence records can be used to preserve materials that comprise a certification path, such that trust in the certificates can be established 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.”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>2. Section 1 Introduction: first paragraph<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Should it be?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/When verifying digital signatures many/To verify digital signatures many<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>3. Section 1 Introduction: second paragraph<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/server for the purposes of preserving evidence records/server for the purpose of preserving evidence records<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>4. section 2: list after second paragraph <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>The list covers two items where I wonder if they should not be slightly reworded?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Old: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“- certification paths containing end entity certificates through trust anchors<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>- certification paths containing intermediate certificates through trust anchors”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>New: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“- certification paths containing end entity certificates up to their trust anchors<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>- certification paths containing intermediate certificates up to their trust anchors”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>5. section 2: list at end of section: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/- SCVP server returns a response with status as of time of interest and including requested evidence records/- SCVP server returns a response with status as of time of interest and includes requested evidence records<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>6. section 3: second paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/CA who issued the end entity certificate through a trust anchor/CA who issued the end entity certificate up to its trust anchor/<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>7. section 4: first paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>This is just a proposal/question whether it might be better??? But maybe a “MUST” is too strong here?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/For id-swb-ers-pkc-cert, the evidence record is calculated over the value of the cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence record MUST be calculated over the value of the cert field in the CertReply object.<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>And maybe also a “MUST” instead of the “is” in the sentence following this one?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>8. section 4: second paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/If the server can not return an EvidenceRecord for the requested information/If the server can not return an EvidenceRecord for the requested information item<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>9.section 4: second paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>And this is only a personal question just for my understanding: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Is the “empty field” sufficient compared to a possible field value e.g. “Not available”. Could there be cases where an “empty field” can result and not mean the value can not be provided, e.g. value is unclear or undefined? But probably this is a quite theoretical question?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>These paragraphs all state analogue to <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“Requests containing id-swb-ers-best-cert-path as a WantBack MUST also contain id-swb-best-cert-path.”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Question: What happens if not both are in the request but only “id-swb-ers-best-cert-path”?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>11. section 5.4: title:<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/Evidence record for a revocation information/Evidence record for revocation information<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>12. section 5.4: second paragraph:<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>And again a personal question for my understanding. (Probably I just miss the point?)<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Why can the generation of cumulative CRLs simplify the maintenance of evidence records?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>13. section 5.5: first paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/all information returned via in the replyWantBacks field/all information returned via the replyWantBacks field<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>14. section 5.5: last paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/indicates the type of replyWantBack is covered by the associated EvidenceRecord./indicates the type of replyWantBack covered by the associated EvidenceRecord.<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>15. section 5.5: last paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/does not have an EvidenceRecord for particular replyWantBack object/does not have an EvidenceRecord for a particular replyWantBack object<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>16. section 5.6: first paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>I am not sure I understand the first two sentences: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>“The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is the only OID defined in this document for which an EvidenceRecord is not returned in the response.”<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>This sounds to me like a contradiction to section 5.2 which I understood that an Evidence record to be returned in the response???<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>17. section 5.6: second paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Is this a spelling mistake?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can include id-swb-partial-cert-path<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>18. section 6: second paragraph: <o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Should this be a capital “SHOULD” in the sense of RFC2119?<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>s/Relying parties should ignore trust anchors contained in unsigned SCVP responses./Relying parties SHOULD ignore trust anchors contained in unsigned SCVP responses.<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'>Thanks, Tobias<o:p></o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB style='font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p> <div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'> <div> <div class=MsoNormal align=center style='text-align:center'><font size=3 face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'> <hr size=2 width="100%" align=center tabindex=-1> </span></font></div> <p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'> owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] <b><span style='font-weight:bold'>On Behalf Of </span></b>Carl Wallace<br> <b><span style='font-weight:bold'>Sent:</span></b> Thursday, November 08, 2007 7:01 PM<br> <b><span style='font-weight:bold'>To:</span></b> ietf-ltans@imc.org<br> <b><span style='font-weight:bold'>Subject:</span></b> RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </span></font><span lang=EN-US><o:p></o:p></span></p> </div> <p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size: 12.0pt'><o:p> </o:p></span></font></p> <p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack.</span></font><o:p></o:p></p> <p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>> -----Original Message-----</span></font> <br> <font size=2><span style='font-size:10.0pt'>> From: IETF I-D Submission Tool [<a href="mailto:idsubmission@ietf.org">mailto:idsubmission@ietf.org</a>] </span></font><br> <font size=2><span style='font-size:10.0pt'>> Sent: Thursday, November 08, 2007 12:52 PM</span></font> <br> <font size=2><span style='font-size:10.0pt'>> To: cwallace@cygnacom.com</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Cc: ietf-ltans@imc.org</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has </span></font><br> <font size=2><span style='font-size:10.0pt'>> been successfuly submitted by Carl Wallace and posted to the </span></font><br> <font size=2><span style='font-size:10.0pt'>> IETF repository.</span></font> <br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> Filename: draft-ietf-ltans-ers-scvp</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Revision: 04</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Title: Using SCVP to Convey Long-term Evidence Records</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Creation_date: 2007-11-08</span></font> <br> <font size=2><span style='font-size:10.0pt'>> WG ID: ltans</span></font> <br> <font size=2><span style='font-size:10.0pt'>> Number_of_pages: 18</span></font> <br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> Abstract:</span></font> <br> <font size=2><span style='font-size:10.0pt'>> The Simple Certificate Validation Protocol (SCVP) defines an </span></font><br> <font size=2><span style='font-size:10.0pt'>> extensible means of delegating the development and validation </span></font><br> <font size=2><span style='font-size:10.0pt'>> of certification paths to a server. It can be used to </span></font><br> <font size=2><span style='font-size:10.0pt'>> support the development and validation of certification paths </span></font><br> <font size=2><span style='font-size:10.0pt'>> well after the expiration of the certificates in the path by </span></font><br> <font size=2><span style='font-size:10.0pt'>> specifying a time of interest in the past. The Evidence </span></font><br> <font size=2><span style='font-size:10.0pt'>> Record Syntax (ERS) defines structures, called evidence </span></font><br> <font size=2><span style='font-size:10.0pt'>> records, to support non-repudiation of existence of data. </span></font><br> <font size=2><span style='font-size:10.0pt'>> Evidence records can be used to preserve materials that </span></font><br> <font size=2><span style='font-size:10.0pt'>> comprise a certification path such that trust can be </span></font><br> <font size=2><span style='font-size:10.0pt'>> established in the certificates after the expiration of the </span></font><br> <font size=2><span style='font-size:10.0pt'>> certificates in the path and after the cryptographic </span></font><br> <font size=2><span style='font-size:10.0pt'>> algorithms used to sign the certificates in the path are no </span></font><br> <font size=2><span style='font-size:10.0pt'>> longer secure. This document describes an application of </span></font><br> <font size=2><span style='font-size:10.0pt'>> SCVP to serve this purpose using the WantBack feature of SCVP </span></font><br> <font size=2><span style='font-size:10.0pt'>> to convey evidence records.</span></font> <br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> The IETF Secretariat.</span></font> <br> <font size=2><span style='font-size:10.0pt'>> </span></font><br> <font size=2><span style='font-size:10.0pt'>> </span></font><o:p></o:p></p> </div> </div> </body> </html> ------_=_NextPart_001_01C826EF.DE95B6B0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8I1bNP023046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 8 Nov 2007 11:01:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8I1bad023045; Thu, 8 Nov 2007 11:01:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lA8I1aYj023036 for <ietf-ltans@imc.org>; Thu, 8 Nov 2007 11:01:37 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 28790 invoked from network); 8 Nov 2007 17:56:33 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;08 Nov 2007 17:56:33 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 8 Nov 2007 17:56:32 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id <L49PJL8H>; Thu, 8 Nov 2007 13:01:34 -0500 Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D481491A7@scygexch1.cygnacom.com> From: Carl Wallace <CWallace@cygnacom.com> To: ietf-ltans@imc.org Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 Date: Thu, 8 Nov 2007 13:01:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82231.61FDE1C7" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C82231.61FDE1C7 Content-Type: text/plain The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack. > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Thursday, November 08, 2007 12:52 PM > To: cwallace@cygnacom.com > Cc: ietf-ltans@imc.org > Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 > > > A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has > been successfuly submitted by Carl Wallace and posted to the > IETF repository. > > Filename: draft-ietf-ltans-ers-scvp > Revision: 04 > Title: Using SCVP to Convey Long-term Evidence Records > Creation_date: 2007-11-08 > WG ID: ltans > Number_of_pages: 18 > > Abstract: > 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. > > > > > The IETF Secretariat. > > ------_=_NextPart_001_01C82231.61FDE1C7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34"> <TITLE>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </TITLE> </HEAD> <BODY> <P><FONT SIZE=2>The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set. The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned. Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack.</FONT></P> <P><FONT SIZE=2>> -----Original Message-----</FONT> <BR><FONT SIZE=2>> From: IETF I-D Submission Tool [<A HREF="mailto:idsubmission@ietf.org">mailto:idsubmission@ietf.org</A>] </FONT> <BR><FONT SIZE=2>> Sent: Thursday, November 08, 2007 12:52 PM</FONT> <BR><FONT SIZE=2>> To: cwallace@cygnacom.com</FONT> <BR><FONT SIZE=2>> Cc: ietf-ltans@imc.org</FONT> <BR><FONT SIZE=2>> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 </FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has </FONT> <BR><FONT SIZE=2>> been successfuly submitted by Carl Wallace and posted to the </FONT> <BR><FONT SIZE=2>> IETF repository.</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> Filename: draft-ietf-ltans-ers-scvp</FONT> <BR><FONT SIZE=2>> Revision: 04</FONT> <BR><FONT SIZE=2>> Title: Using SCVP to Convey Long-term Evidence Records</FONT> <BR><FONT SIZE=2>> Creation_date: 2007-11-08</FONT> <BR><FONT SIZE=2>> WG ID: ltans</FONT> <BR><FONT SIZE=2>> Number_of_pages: 18</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> Abstract:</FONT> <BR><FONT SIZE=2>> The Simple Certificate Validation Protocol (SCVP) defines an </FONT> <BR><FONT SIZE=2>> extensible means of delegating the development and validation </FONT> <BR><FONT SIZE=2>> of certification paths to a server. It can be used to </FONT> <BR><FONT SIZE=2>> support the development and validation of certification paths </FONT> <BR><FONT SIZE=2>> well after the expiration of the certificates in the path by </FONT> <BR><FONT SIZE=2>> specifying a time of interest in the past. The Evidence </FONT> <BR><FONT SIZE=2>> Record Syntax (ERS) defines structures, called evidence </FONT> <BR><FONT SIZE=2>> records, to support non-repudiation of existence of data. </FONT> <BR><FONT SIZE=2>> Evidence records can be used to preserve materials that </FONT> <BR><FONT SIZE=2>> comprise a certification path such that trust can be </FONT> <BR><FONT SIZE=2>> established in the certificates after the expiration of the </FONT> <BR><FONT SIZE=2>> certificates in the path and after the cryptographic </FONT> <BR><FONT SIZE=2>> algorithms used to sign the certificates in the path are no </FONT> <BR><FONT SIZE=2>> longer secure. This document describes an application of </FONT> <BR><FONT SIZE=2>> SCVP to serve this purpose using the WantBack feature of SCVP </FONT> <BR><FONT SIZE=2>> to convey evidence records.</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> The IETF Secretariat.</FONT> <BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C82231.61FDE1C7-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8I04wD022865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 8 Nov 2007 11:00:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8I04Qo022864; Thu, 8 Nov 2007 11:00:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8I03Em022856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <ietf-ltans@imc.org>; Thu, 8 Nov 2007 11:00:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B5C6E2AC7B; Thu, 8 Nov 2007 18:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqBfe-0000Qw-A4; Thu, 08 Nov 2007 13:00:02 -0500 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-04.txt Message-Id: <E1IqBfe-0000Qw-A4@stiedprstage1.ietf.org> Date: Thu, 08 Nov 2007 13:00:02 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> --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-04.txt Pages : 18 Date : 2007-11-08 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-04.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-04.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-04.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: <2007-11-08125140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-ers-scvp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-ers-scvp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-08125140.I-D\@ietf.org> --OtherAccess-- --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8Hpk9d021756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Thu, 8 Nov 2007 10:51:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lA8HpkJf021755; Thu, 8 Nov 2007 10:51:46 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lA8HpjBa021747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL) for <ietf-ltans@imc.org>; Thu, 8 Nov 2007 10:51:46 -0700 (MST) (envelope-from mirror@ietf.org) Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 94C29328B9; Thu, 8 Nov 2007 17:51:44 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IqBXc-0007Xs-Fb; Thu, 08 Nov 2007 12:51:44 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: cwallace@cygnacom.com Cc: ietf-ltans@imc.org From: IETF I-D Submission Tool <idsubmission@ietf.org> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 Message-Id: <E1IqBXc-0007Xs-Fb@ietf.org> Date: Thu, 08 Nov 2007 12:51:44 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/> List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe> List-ID: <ietf-ltans.imc.org> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has been successfuly submitted by Carl Wallace and posted to the IETF repository. Filename: draft-ietf-ltans-ers-scvp Revision: 04 Title: Using SCVP to Convey Long-term Evidence Records Creation_date: 2007-11-08 WG ID: ltans Number_of_pages: 18 Abstract: 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. The IETF Secretariat.
- ERS - using hash tree? Jesus Maria Mendez Perez
- RE: ERS - using hash tree? Tobias Gondrom
- Re: ERS - using hash tree? Jesus Maria Mendez Perez
- RE: ERS - using hash tree? Tobias Gondrom
- Re: ERS - using hash tree? Jesus Maria Mendez Perez
- Re: ERS - using hash tree? todd glassey
- Re: ERS - using hash tree? Jeffrey A. Williams
- Re: ERS - using hash tree? Peter Sylvester
- Re: ERS - using hash tree? Peter Sylvester