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 l9JJf4pC017656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 12:41: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 l9JJf4NW017655; Fri, 19 Oct 2007 12:41: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 elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JJf3lq017649 for ; Fri, 19 Oct 2007 12:41:03 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=saGS2M5Xns7G89yXNGnbC8brZmTWtC8LkEpAMbSgyXVdEtLijIJky2YH95/14aKY; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IixiM-0001N0-3c; Fri, 19 Oct 2007 15:40:58 -0400 Message-ID: <008101c81288$0c4ec440$6401a8c0@tsg1> From: "TS Glassey" To: "Aljosa Jerman Blazic" , References: Subject: Re: Encryption and ERS Date: Fri, 19 Oct 2007 12:41:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c3b7a29787c239a041490d0bfad60416350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Which is why its so important to keep a full chain of custody on all changes to the content. The amount of data being stored is irrelevant to the issue of this technology. A key Goal of LTANS should not be constrained by the size or amount of data stored but the integrity of the control process around the data. That's one of the things I think is not addressed sufficiently to date. Todd Glassey (as an Auditor). ----- Original Message ----- From: "Aljosa Jerman Blazic" To: Sent: Friday, October 19, 2007 7:01 AM Subject: Encryption and ERS > > Hi > > I am working on the next version of XMLERS and by studying the last ERS > spec (RFC actually), I stumbled over encryption part: > > "When a relying party uses an evidence record to prove the > existence of encrypted data objects, it may be desirable for > clients to only store the unencrypted data objects and to delete > the encrypted copy. In order to use the evidence record, it must > then be possible to unambiguously re-encrypt the unencrypted data > to get exactly the data that was originally archived. Therefore, > additional data necessary to re-encrypt data objects should be > inserted into the evidence record by the client, i.e., the LTA > never sees these values." > > This approach foresees the inclusion of, correct me if I am wrong, data > necessary to re-encrypt data by a client to validate ERS generated. Now > the question here is, how can such information be trusted from a client? > It somehow breaks the point of ERS. It is true that LTA never sees such > data but this, IMO, does not affect the confidentiality issues and it > even does not make sense, as the crypto material used for encryption is > usually public... Or? > > Also, there is a typo on page 19: instead of "ha(1), ha(2), ha(3) are as > defined in step 4 above" it should be "ha(1), ha(2), ha(3) are as > defined in step 3 above" > > A. > > ------------------- > SETCCE > Jamova 39 > SI-1000 Ljubljana > Europe > tel: +386 1 4773505 > fax: +386 1 4773911 > www.setcce.si > ------------------- > 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 l9JGxMhv003790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 09:59:22 -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 l9JGxMGn003789; Fri, 19 Oct 2007 09:59:22 -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 elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JGxLiA003782 for ; Fri, 19 Oct 2007 09:59:21 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=oF26Xj/4zORQ6n17RTU3n9VCxQadPTARWkGSI1u1SYQwSJ02U22pR524utlx1ohr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IivBw-0000j8-7H; Fri, 19 Oct 2007 12:59:20 -0400 Message-ID: <003f01c81271$77e09330$6401a8c0@tsg1> From: "TS Glassey" To: "Aljosa Jerman Blazic" , References: Subject: Re: Encryption and ERS Date: Fri, 19 Oct 2007 09:59:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796bc4c747effd6863b790fba02884b1fb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Aljosa Jerman Blazic" To: Sent: Friday, October 19, 2007 9:14 AM Subject: RE: Encryption and ERS > > Hello > >> Hi, >> >> as it is said in the paragraph before: >> >> "Only encryption methods should be used that make it possible >> to prove that archive-timestamped encrypted data objects >> unambiguously represent unencrypted data objects. >> All data necessary to prove unambiguous representation should >> be included in the archived data objects." > > Indeed, but the next paragraph states: "...additional data necessary to > re-encrypt data objects should be inserted into the evidence record by the > client..." meaning that data is inserted in an evidence record by a client > after it is created. Or am I missing something...? The problem is in editing the data object to create a derivative of the original IP and representing that this is the original IP. Its not... its IP that was reencapsulated or chaned cryptographically inside of an LTANS carrier. What needs to happen is restamped images need to be 'and'ed into the envelope as an additional instance of the document. That is to say there are both legal and business reasons for maintaining the document's signature status, and to do that a chain of custody as to the changes that it underwent also have to be included with the newly updated evedntiary content envelope IMHO. > >> Note, that this implies a 1:n - Function (1 unencrypted >> message may represented by n encrypted messages) not a 1:1 - Function. >> In practice some encryption functions - e.g. used in CMS - >> use additional start parameters (random numbers) - in order >> to avoid some kind of attacks knowing plaintexts. > > I am aware of the additional parameters, however 1 encrypted message may > result in n unencrypted messages when different cryptographic material is > used. And this is where I see the problem as there is no hard proof that > 1:1 transformation is provided for ERS checking. If a client is in control > of such information (crypto material) then there is hard to set a proper > level of trust as the (encrypted) data submitted for ERS generation may > actually originate from n different data sets... In theory at least. > >> Therfore these additional Parameters may be necessary to >> reconstruct the (archive-)timestamped encrypted message, if >> it was deleted. >> >> >> Nethertheless, there is no security problem, if these >> parameters are not time-stamped - because of the requirement, >> that the encrypted message should unambiguous represent the >> clear-text message. > > Hmmm, I understood that by inserting some of the information into the ERS > this "unambiguousity" is achieved... > > AJB > >> Ulrich Pordesch >> >> -----Ursprüngliche Nachricht----- >> Von: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Aljosa >> Jerman Blazic >> Gesendet: Freitag, 19. Oktober 2007 16:01 >> An: ietf-ltans@imc.org >> Betreff: Encryption and ERS >> >> >> Hi >> >> I am working on the next version of XMLERS and by studying >> the last ERS spec (RFC actually), I stumbled over encryption part: >> >> "When a relying party uses an evidence record to prove the >> existence of encrypted data objects, it may be desirable for >> clients to only store the unencrypted data objects and to delete >> the encrypted copy. In order to use the evidence >> record, it must >> then be possible to unambiguously re-encrypt the >> unencrypted data >> to get exactly the data that was originally archived. >> Therefore, >> additional data necessary to re-encrypt data objects should be >> inserted into the evidence record by the client, i.e., the LTA >> never sees these values." >> >> This approach foresees the inclusion of, correct me if I am >> wrong, data necessary to re-encrypt data by a client to >> validate ERS generated. Now the question here is, how can >> such information be trusted from a client? >> It somehow breaks the point of ERS. It is true that LTA never >> sees such data but this, IMO, does not affect the >> confidentiality issues and it even does not make sense, as >> the crypto material used for encryption is usually public... Or? >> >> Also, there is a typo on page 19: instead of "ha(1), ha(2), >> ha(3) are as defined in step 4 above" it should be "ha(1), >> ha(2), ha(3) are as defined in step 3 above" >> >> A. >> >> ------------------- >> SETCCE >> Jamova 39 >> SI-1000 Ljubljana >> Europe >> tel: +386 1 4773505 >> fax: +386 1 4773911 >> www.setcce.si >> ------------------- >> >> >> >> > 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 l9JGDlEc099013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 09:13:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l9JGDl4e099012; Fri, 19 Oct 2007 09:13:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from setcce.si (localpolitix.setcce.org [193.138.1.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JGDjdh099004 for ; Fri, 19 Oct 2007 09:13:46 -0700 (MST) (envelope-from aljosa@setcce.si) Content-class: urn:content-classes:message Subject: RE: Encryption and ERS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 19 Oct 2007 18:14:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Encryption and ERS Thread-Index: AcgSWIkdjiW/Ba4uR0yeMyyxZ8UhtQABNiqgAAMa0AA= From: "Aljosa Jerman Blazic" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9JGDkdh099007 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello > Hi, > > as it is said in the paragraph before: > > "Only encryption methods should be used that make it possible > to prove that archive-timestamped encrypted data objects > unambiguously represent unencrypted data objects. > All data necessary to prove unambiguous representation should > be included in the archived data objects." Indeed, but the next paragraph states: "...additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client..." meaning that data is inserted in an evidence record by a client after it is created. Or am I missing something...? > Note, that this implies a 1:n - Function (1 unencrypted > message may represented by n encrypted messages) not a 1:1 - Function. > In practice some encryption functions - e.g. used in CMS - > use additional start parameters (random numbers) - in order > to avoid some kind of attacks knowing plaintexts. I am aware of the additional parameters, however 1 encrypted message may result in n unencrypted messages when different cryptographic material is used. And this is where I see the problem as there is no hard proof that 1:1 transformation is provided for ERS checking. If a client is in control of such information (crypto material) then there is hard to set a proper level of trust as the (encrypted) data submitted for ERS generation may actually originate from n different data sets... In theory at least. > Therfore these additional Parameters may be necessary to > reconstruct the (archive-)timestamped encrypted message, if > it was deleted. > > > Nethertheless, there is no security problem, if these > parameters are not time-stamped - because of the requirement, > that the encrypted message should unambiguous represent the > clear-text message. Hmmm, I understood that by inserting some of the information into the ERS this "unambiguousity" is achieved... AJB > Ulrich Pordesch > > -----Ursprüngliche Nachricht----- > Von: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Aljosa > Jerman Blazic > Gesendet: Freitag, 19. Oktober 2007 16:01 > An: ietf-ltans@imc.org > Betreff: Encryption and ERS > > > Hi > > I am working on the next version of XMLERS and by studying > the last ERS spec (RFC actually), I stumbled over encryption part: > > "When a relying party uses an evidence record to prove the > existence of encrypted data objects, it may be desirable for > clients to only store the unencrypted data objects and to delete > the encrypted copy. In order to use the evidence > record, it must > then be possible to unambiguously re-encrypt the > unencrypted data > to get exactly the data that was originally archived. > Therefore, > additional data necessary to re-encrypt data objects should be > inserted into the evidence record by the client, i.e., the LTA > never sees these values." > > This approach foresees the inclusion of, correct me if I am > wrong, data necessary to re-encrypt data by a client to > validate ERS generated. Now the question here is, how can > such information be trusted from a client? > It somehow breaks the point of ERS. It is true that LTA never > sees such data but this, IMO, does not affect the > confidentiality issues and it even does not make sense, as > the crypto material used for encryption is usually public... Or? > > Also, there is a typo on page 19: instead of "ha(1), ha(2), > ha(3) are as defined in step 4 above" it should be "ha(1), > ha(2), ha(3) are as defined in step 3 above" > > A. > > ------------------- > SETCCE > Jamova 39 > SI-1000 Ljubljana > Europe > tel: +386 1 4773505 > fax: +386 1 4773911 > www.setcce.si > ------------------- > > > > 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 l9JEcaSd089551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 07:38:36 -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 l9JEcaGg089550; Fri, 19 Oct 2007 07:38:36 -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 mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JEcXFM089537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Oct 2007 07:38:35 -0700 (MST) (envelope-from ulrich.pordesch@sit.fraunhofer.de) Received: from pcpordeschlab (vpnsit2_2.sit.fraunhofer.de [141.12.111.2]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with SMTP id l9JEcVIM006799 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 19 Oct 2007 16:38:31 +0200 From: "Ulrich Pordesch" To: References: In-Reply-To: Subject: AW: Encryption and ERS Date: Fri, 19 Oct 2007 16:38:25 +0200 Message-ID: <002601c8125d$b90ca010$2b25e030$@pordesch@sit.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgSWIkdjiW/Ba4uR0yeMyyxZ8UhtQABNiqg Content-Language: de Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9JEcZFL089544 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, as it is said in the paragraph before: "Only encryption methods should be used that make it possible to prove that archive-timestamped encrypted data objects unambiguously represent unencrypted data objects. All data necessary to prove unambiguous representation should be included in the archived data objects." Note, that this implies a 1:n - Function (1 unencrypted message may represented by n encrypted messages) not a 1:1 - Function. In practice some encryption functions - e.g. used in CMS - use additional start parameters (random numbers) - in order to avoid some kind of attacks knowing plaintexts. Therfore these additional Parameters may be necessary to reconstruct the (archive-)timestamped encrypted message, if it was deleted. Nethertheless, there is no security problem, if these parameters are not time-stamped - because of the requirement, that the encrypted message should unambiguous represent the clear-text message. Ulrich Pordesch -----Ursprüngliche Nachricht----- Von: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] Im Auftrag von Aljosa Jerman Blazic Gesendet: Freitag, 19. Oktober 2007 16:01 An: ietf-ltans@imc.org Betreff: Encryption and ERS Hi I am working on the next version of XMLERS and by studying the last ERS spec (RFC actually), I stumbled over encryption part: "When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. In order to use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values." This approach foresees the inclusion of, correct me if I am wrong, data necessary to re-encrypt data by a client to validate ERS generated. Now the question here is, how can such information be trusted from a client? It somehow breaks the point of ERS. It is true that LTA never sees such data but this, IMO, does not affect the confidentiality issues and it even does not make sense, as the crypto material used for encryption is usually public... Or? Also, there is a typo on page 19: instead of "ha(1), ha(2), ha(3) are as defined in step 4 above" it should be "ha(1), ha(2), ha(3) are as defined in step 3 above" A. ------------------- SETCCE Jamova 39 SI-1000 Ljubljana Europe tel: +386 1 4773505 fax: +386 1 4773911 www.setcce.si ------------------- 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 l9JE0LaN085289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2007 07:00:21 -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 l9JE0Lx3085288; Fri, 19 Oct 2007 07:00:21 -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 setcce.si (localpolitix.setcce.org [193.138.1.155]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9JE0JIP085280 for ; Fri, 19 Oct 2007 07:00:20 -0700 (MST) (envelope-from aljosa@setcce.si) Content-class: urn:content-classes:message Subject: Encryption and ERS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Oct 2007 16:01:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Encryption and ERS Thread-Index: AcgSWIkdjiW/Ba4uR0yeMyyxZ8UhtQ== From: "Aljosa Jerman Blazic" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id l9JE0LIP085283 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi I am working on the next version of XMLERS and by studying the last ERS spec (RFC actually), I stumbled over encryption part: "When a relying party uses an evidence record to prove the existence of encrypted data objects, it may be desirable for clients to only store the unencrypted data objects and to delete the encrypted copy. In order to use the evidence record, it must then be possible to unambiguously re-encrypt the unencrypted data to get exactly the data that was originally archived. Therefore, additional data necessary to re-encrypt data objects should be inserted into the evidence record by the client, i.e., the LTA never sees these values." This approach foresees the inclusion of, correct me if I am wrong, data necessary to re-encrypt data by a client to validate ERS generated. Now the question here is, how can such information be trusted from a client? It somehow breaks the point of ERS. It is true that LTA never sees such data but this, IMO, does not affect the confidentiality issues and it even does not make sense, as the crypto material used for encryption is usually public... Or? Also, there is a typo on page 19: instead of "ha(1), ha(2), ha(3) are as defined in step 4 above" it should be "ha(1), ha(2), ha(3) are as defined in step 3 above" A. ------------------- SETCCE Jamova 39 SI-1000 Ljubljana Europe tel: +386 1 4773505 fax: +386 1 4773911 www.setcce.si ------------------- 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 l9G7U9rs075825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 00:30: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 l9G7U9V4075824; Tue, 16 Oct 2007 00:30: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 ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9G7U8X4075818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Oct 2007 00:30:09 -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 9992A175AB; Tue, 16 Oct 2007 07:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IhgsM-0001aY-5P; Tue, 16 Oct 2007 03:30:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-dssc-01.txt Message-Id: Date: Tue, 16 Oct 2007 03:30:02 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-01.txt Pages : 34 Date : 2007-10-16 In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the used cryptographic algorithms. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure for security suitabilities of cryptographic algorithms which may be automatically interpreted.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-dssc-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-dssc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-dssc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-10-16032024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-dssc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-dssc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-16032024.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 l9G7KTXl075359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 00:20: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 l9G7KT7Q075358; Tue, 16 Oct 2007 00:20: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 ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l9G7KRZM075351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Oct 2007 00:20:28 -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 2A8B4328E4; Tue, 16 Oct 2007 07:20:27 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Ihgj5-00017X-2V; Tue, 16 Oct 2007 03:20:27 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: thomas.kunz@sit.fraunhofer.de Cc: ietf-ltans@imc.org, susanne.okunick@sit.fraunhofer.de, ulrich.pordesch@zv.fraunhofer.de From: IETF I-D Submission Tool Subject: New Version Notification for draft-ietf-ltans-dssc-01 Message-Id: Date: Tue, 16 Oct 2007 03:20:27 -0400 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new version of I-D, draft-ietf-ltans-dssc-01.txt has been successfuly submitted by Thomas Kunz and posted to the IETF repository. Filename: draft-ietf-ltans-dssc Revision: 01 Title: Data Structure for Security Suitabilities of Cryptographic Algorithms (DSSC) Creation_date: 2007-10-15 WG ID: ltans Number_of_pages: 34 Abstract: In many application areas it must be possible to prove the existence and integrity of digital signed data. This proof depends on the security suitability of the used cryptographic algorithms. Because algorithms can become weak over the years, it is necessary to periodically evaluate these security suitabilities. When signing or verifying data, these evaluations must be considered. This document specifies a data structure for security suitabilities of cryptographic algorithms which may be automatically interpreted.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]. The IETF Secretariat.