From owner-ietf-ltans Mon Nov 1 09:51:49 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HpnQl015115; Mon, 1 Nov 2004 09:51:49 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HpnEW015114; Mon, 1 Nov 2004 09:51:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA1HphKV015014 for ; Mon, 1 Nov 2004 09:51:48 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200411011751.iA1HphKV015014@above.proper.com> Received: (qmail 7195 invoked from network); 1 Nov 2004 17:51:39 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 1 Nov 2004 17:51:39 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07077-03 for ; Mon, 1 Nov 2004 18:51:39 +0100 (CET) Received: (qmail 7190 invoked from network); 1 Nov 2004 17:51:39 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 1 Nov 2004 17:51:39 -0000 From: "A. Jerman Blazic" To: Subject: RE: Discussion of notareqs document Date: Mon, 1 Nov 2004 19:52:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTAQ+Q013UmD6euRw29pdJ8sbk9CA== In-Reply-To: <41810D94.60202@edelweb.fr> X-Virus-Scanned: by amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1HpnKV015108 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, Following the "e-notary" discussion in the last month I see that requirements have been rapidly shifted and are now reflecting the certification and validation services. Coming to this point I would like to draw your attention to the fundamental problem that at least I have when playing around with the scenario of digitally signed documents, which is however the crucial focus of TAS services at this point. I also think that real scenarios would help us understand the problems more clearly and find appropriate solution(s). Now let's assume that a signed document enters an archive. What happens in the first place is signature validation (since we assume that there is no point to archive a non-valid document, although such scenarios are also possible). We also assume that TAS protocols and ERS are in place. So, what we need is some fixation in time that signature (and document) existed at some point in time (archiving time!). Providing evidence for a document is not a problem, but for a signature there are some sequence issues. Preserving signatures is based on reference information and evidence record. Let's start with T1, when a CRL has been issued and the next time the CRL is issued is marked with T5. Now we need to collect some reference information (certificates, CRLs, etc.), validate the signature and pack everything together before creating the evidence record (timestamp). At time T2 a timestamp is requested for collected data following by timestamp issued at T3. Until T5 we have enough time to revoke the certificate related to digital signature archived, which happens at T4 and we can end up with archived invalid signature, although it was submitted to the archive before revocation happened. The problem with CRLs is that they might not be synchronized with revocation mechanisms and there is no real information whether a signature is valid or not at specific point in time. In theory CRLs should be issued immediately after a certificate is revoked, but in practice things are not the same, since the procedure itself already has some timeframe (the ideal solution is to stop the time during the validation process). Now, there are options to use more than one evidence record for a single data (signature) but I am afraid such procedures might get overall concept very complicated and bulky, especially when performing procedures over groups of data. I think we should pay some more attention to archival data structures and mechanisms supporting TAS operation. I would appreciate if some feedback would reach my inbox concerning the mentioned problem and I also hope such discussion(s) would unveil the black box internal mechanisms, which we named TAS or whatever and after all, solve the main problem of LTANS requirements on data export. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > Sent: Thursday, October 28, 2004 4:18 PM > To: ietf-ltans@imc.org > Subject: Re: Discussion of notareqs document > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > Paul-André, > > (text deleted) > > > > This is another proof of the sound approach of > LTANS which links "data certs" and "secure archived". Any > "data cert" must not only be signed, but a detailed log entry > must be archived in a secure way (non rewritable medium, hash > linking). This mandatory combination was a major rationale of > the openevidence project (the technical solution by then was > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > There is no such mandatory comnbination for LTANS: data > needs to be signed (and time-stamped) by the archive service, > but the log is not intended to be used as an evidence. > > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a > posteriori" rationale for a given protocol or service. My > strong suggestion, based on several years activities for > several customers, is indeed that the "certified archival" of > "detailed and signed" log is a "must" for a large majority of > actual applications and uses cases. > > What the most "educated" or aware customers do require is a > complete set of "evidence management" services. (What they > call in France "Gestion de la Preuve" or "Administration de > la Preuve"; what they will be able to exhibit in order to > dissuade "others" to initiate a litigation, or whenever > unsuccessfull, what they will be able to exhibit as evidence > elements in a court). > > My personal view of the whole justification of LTANS context > is, as I am convinced that this type of requirements will be > generalized, that the IETF succeeds in proposing and > establishing standards that wil enable : > > > 1. technical interop between business partners > 2. technical interop between solution providers > > 3. the judges and their expert to master the e-material > (because it conforms to standard and because there exist > tools enbling to manipulate them) > 4. the possibility of mutual recognition within a business > community > > And I have no longer any doubt that "certified archived > logs" (more or less equivalent of the certified archival of > requests and receipts) will be one of, if not, the most > usefull component. > > > > > Denis > > > > > > > > > -- > > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > > From owner-ietf-ltans Mon Nov 1 11:12:35 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1JCZDx057490; Mon, 1 Nov 2004 11:12:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1JCZcl057484; Mon, 1 Nov 2004 11:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1JCYQG057473 for ; Mon, 1 Nov 2004 11:12:34 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA1JCbph012024 for ; Mon, 1 Nov 2004 14:12:37 -0500 From: "Santosh Chokhani" To: Subject: RE: Discussion of notareqs document Date: Mon, 1 Nov 2004 14:12:37 -0500 Message-ID: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <200411011751.iA1HphKV015014@above.proper.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1JCZQG057479 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej, The archive package should contain the CRL used to verify the transaction. That coupled with other times will show when the transaction was received and processed. When speed is of not essence, the relying party can always wait for a CRL issued after the transaction was received to verify. This will ensure that the certificate was not revoked in the interim. Relying party can use the later CRL for archiving the transaction. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Monday, November 01, 2004 1:52 PM To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document Dear all, Following the "e-notary" discussion in the last month I see that requirements have been rapidly shifted and are now reflecting the certification and validation services. Coming to this point I would like to draw your attention to the fundamental problem that at least I have when playing around with the scenario of digitally signed documents, which is however the crucial focus of TAS services at this point. I also think that real scenarios would help us understand the problems more clearly and find appropriate solution(s). Now let's assume that a signed document enters an archive. What happens in the first place is signature validation (since we assume that there is no point to archive a non-valid document, although such scenarios are also possible). We also assume that TAS protocols and ERS are in place. So, what we need is some fixation in time that signature (and document) existed at some point in time (archiving time!). Providing evidence for a document is not a problem, but for a signature there are some sequence issues. Preserving signatures is based on reference information and evidence record. Let's start with T1, when a CRL has been issued and the next time the CRL is issued is marked with T5. Now we need to collect some reference information (certificates, CRLs, etc.), validate the signature and pack everything together before creating the evidence record (timestamp). At time T2 a timestamp is requested for collected data following by timestamp issued at T3. Until T5 we have enough time to revoke the certificate related to digital signature archived, which happens at T4 and we can end up with archived invalid signature, although it was submitted to the archive before revocation happened. The problem with CRLs is that they might not be synchronized with revocation mechanisms and there is no real information whether a signature is valid or not at specific point in time. In theory CRLs should be issued immediately after a certificate is revoked, but in practice things are not the same, since the procedure itself already has some timeframe (the ideal solution is to stop the time during the validation process). Now, there are options to use more than one evidence record for a single data (signature) but I am afraid such procedures might get overall concept very complicated and bulky, especially when performing procedures over groups of data. I think we should pay some more attention to archival data structures and mechanisms supporting TAS operation. I would appreciate if some feedback would reach my inbox concerning the mentioned problem and I also hope such discussion(s) would unveil the black box internal mechanisms, which we named TAS or whatever and after all, solve the main problem of LTANS requirements on data export. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > Sent: Thursday, October 28, 2004 4:18 PM > To: ietf-ltans@imc.org > Subject: Re: Discussion of notareqs document > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > Paul-André, > > (text deleted) > > > > This is another proof of the sound approach of > LTANS which links "data certs" and "secure archived". Any > "data cert" must not only be signed, but a detailed log entry > must be archived in a secure way (non rewritable medium, hash > linking). This mandatory combination was a major rationale of > the openevidence project (the technical solution by then was > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > There is no such mandatory comnbination for LTANS: data needs to be > signed (and time-stamped) by the archive service, but the log is not > intended to be used as an evidence. > > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a posteriori" > rationale for a given protocol or service. My strong suggestion, > based on several years activities for several customers, is indeed > that the "certified archival" of "detailed and signed" log is a "must" > for a large majority of actual applications and uses cases. > > What the most "educated" or aware customers do require is a complete > set of "evidence management" services. (What they call in France > "Gestion de la Preuve" or "Administration de la Preuve"; what they > will be able to exhibit in order to dissuade "others" to initiate a > litigation, or whenever unsuccessfull, what they will be able to > exhibit as evidence elements in a court). > > My personal view of the whole justification of LTANS context is, as I > am convinced that this type of requirements will be generalized, that > the IETF succeeds in proposing and establishing standards that wil > enable : > > > 1. technical interop between business partners > 2. technical interop between solution providers > > 3. the judges and their expert to master the e-material > (because it conforms to standard and because there exist tools enbling > to manipulate them) > 4. the possibility of mutual recognition within a business > community > > And I have no longer any doubt that "certified archived logs" (more > or less equivalent of the certified archival of requests and receipts) > will be one of, if not, the most usefull component. > > > > > Denis > > > > > > > > > -- > > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > > From owner-ietf-ltans Tue Nov 2 05:38:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DcWN9030474; Tue, 2 Nov 2004 05:38:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2DcW6T030473; Tue, 2 Nov 2004 05:38:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DcVda030467 for ; Tue, 2 Nov 2004 05:38:31 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (48.sub-166-180-48.myvzw.com [166.180.48.48]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA2DcTAU027628; Tue, 2 Nov 2004 08:38:29 -0500 Message-Id: <200411021338.iA2DcTAU027628@host13.websitesource.com> From: "Carl Wallace" To: "'A. Jerman Blazic'" , Subject: RE: Discussion of notareqs document Date: Tue, 2 Nov 2004 08:38:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200411011751.iA1HphKV015014@above.proper.com> Thread-Index: AcTAQ+Q013UmD6euRw29pdJ8sbk9CAAmNbSA Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA2DcVda030468 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding WG focus, the recent shift in requirements focus has been w.r.t. to the "notary" requirements. The long-term archive requirements focus on the types of concerns you mention. That focus has been relatively stable for some time, though the requirements document itself is still evolving. Regarding signature preservation, as discussed so far, an evidence record is relative to a single time T1, e.g. the time of submission to the archive. Retroactive revocation would need to be considered before committing the data to an archive and initiating an evidence record (using the mechanisms that have been discussed so far). Even if a CRL were issued immediately when a cert was revoked, it's revocation time might be before T1. I don't believe I heard anyone discuss using an evidence record to verify a signature relative to multiple points in time (that could get ugly). It seems unlikely that retroactive revocation applied after several periodic refresh operations (which should be relatively infrequent) at time T4 should invalidate a signature generated at, or before, time T1. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Monday, November 01, 2004 1:52 PM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > Dear all, > > Following the "e-notary" discussion in the last month I see > that requirements have been rapidly shifted and are now > reflecting the certification and validation services. Coming > to this point I would like to draw your attention to the > fundamental problem that at least I have when playing around > with the scenario of digitally signed documents, which is > however the crucial focus of TAS services at this point. I > also think that real scenarios would help us understand the > problems more clearly and find appropriate solution(s). > > Now let's assume that a signed document enters an archive. > What happens in the first place is signature validation > (since we assume that there is no point to archive a > non-valid document, although such scenarios are also > possible). We also assume that TAS protocols and ERS are in > place. So, what we need is some fixation in time that > signature (and document) existed at some point in time > (archiving time!). Providing evidence for a document is not a > problem, but for a signature there are some sequence issues. > > Preserving signatures is based on reference information and > evidence record. > Let's start with T1, when a CRL has been issued and the next > time the CRL is issued is marked with T5. Now we need to > collect some reference information (certificates, CRLs, > etc.), validate the signature and pack everything together > before creating the evidence record (timestamp). At time T2 a > timestamp is requested for collected data following by > timestamp issued at T3. Until T5 we have enough time to > revoke the certificate related to digital signature archived, > which happens at T4 and we can end up with archived invalid > signature, although it was submitted to the archive before > revocation happened. > > The problem with CRLs is that they might not be synchronized > with revocation mechanisms and there is no real information > whether a signature is valid or not at specific point in > time. In theory CRLs should be issued immediately after a > certificate is revoked, but in practice things are not the > same, since the procedure itself already has some timeframe > (the ideal solution is to stop the time during the validation > process). > > Now, there are options to use more than one evidence record > for a single data (signature) but I am afraid such procedures > might get overall concept very complicated and bulky, > especially when performing procedures over groups of data. I > think we should pay some more attention to archival data > structures and mechanisms supporting TAS operation. I would > appreciate if some feedback would reach my inbox concerning > the mentioned problem and I also hope such discussion(s) > would unveil the black box internal mechanisms, which we > named TAS or whatever and after all, solve the main problem > of LTANS requirements on data export. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > Sent: Thursday, October 28, 2004 4:18 PM > > To: ietf-ltans@imc.org > > Subject: Re: Discussion of notareqs document > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > Paul-André, > > > > (text deleted) > > > > > > > > This is another proof of the sound approach of > LTANS which links > > "data certs" and "secure archived". Any "data cert" must > not only be > > signed, but a detailed log entry must be archived in a > secure way (non > > rewritable medium, hash linking). This mandatory combination was a > > major rationale of the openevidence project (the technical > solution by > > then was a a combination of TSP RFC3061, DVCS RFC3029 and > > hash-linking) > > > > > > > > There is no such mandatory comnbination for LTANS: data > needs to be > > signed (and time-stamped) by the archive service, but the > log is not > > intended to be used as an evidence. > > > > > > I am exactly suggesting that it be. > > > > We are preparing a requirements document and not some "a > posteriori" > > rationale for a given protocol or service. My strong suggestion, > > based on several years activities for several customers, is indeed > > that the "certified archival" of "detailed and signed" log > is a "must" > > for a large majority of actual applications and uses cases. > > > > What the most "educated" or aware customers do require is a > complete > > set of "evidence management" services. (What they call in France > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > will be able to exhibit in order to dissuade "others" to initiate a > > litigation, or whenever unsuccessfull, what they will be able to > > exhibit as evidence elements in a court). > > > > My personal view of the whole justification of LTANS > context is, as I > > am convinced that this type of requirements will be > generalized, that > > the IETF succeeds in proposing and establishing standards that wil > > enable : > > > > > > 1. technical interop between business partners > > 2. technical interop between solution providers > > > > 3. the judges and their expert to master the e-material > > (because it conforms to standard and because there exist > tools enbling > > to manipulate them) > > 4. the possibility of mutual recognition within a business > > community > > > > And I have no longer any doubt that "certified archived > logs" (more > > or less equivalent of the certified archival of requests > and receipts) > > will be one of, if not, the most usefull component. > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > -- > > > > Edelweb > > Groupe ON-X Pôle Sécurité > > paul-andre.pays@edelweb.fr papays@on-x.com > > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > From owner-ietf-ltans Wed Nov 3 02:52:42 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3AqgKO036586; Wed, 3 Nov 2004 02:52:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Aqgo4036585; Wed, 3 Nov 2004 02:52:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3AqeS4036436 for ; Wed, 3 Nov 2004 02:52:41 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 24432 invoked by uid 48); 3 Nov 2004 10:52:30 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 11:52:30 +0100 Message-ID: <1099479150.4188b86e846b6@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 11:52:30 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> In-Reply-To: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh, I am afraid it is not that simple. Let's say I want a Premium service for some very important document which is also time critical. There are no rules when CRLs are refreshed and in some scenarios CRLs are not issued for another month or so. Waiting your document to be formally processed after a month... well that is just not the evolving scenario. The basic concept of solving this problem should use two time evidences at least. First one to attest that a signature existed at the time of arrival and the later attestation that proves the validity of a signature based on some reference information (CRL more precisely). The things get a bit more complicated when a document carries several signatures based on certificates issued by (unsynchronized) CAs. However, there are also some conceptual approaches to this problem. One is to assure that CRLs carry some time evidences (when they were actually issued – the same used as for TAS) and that policies clearly declare that CRLs are issued after some action and that post action publishing is strictly forbidden (e.g. a certificate can't be revoked back in time and the revocation is valid only after a CRL is issued). This way we could at least shorten the time frame left for manipulation (I am not counting the processing time here, which is unavoidable). I think we should agree at least on some basic concepts here and define some TAS framework understanding. Also, conclusions should be propagated to other areas and WGs to achieve some consensus on how to properly manage signed documents in time. aleksej Quoting Santosh Chokhani : > > Aleksej, > > The archive package should contain the CRL used to verify the transaction. > That coupled with other times will show when the transaction was received > and processed. > > When speed is of not essence, the relying party can always wait for a CRL > issued after the transaction was received to verify. This will ensure that > the certificate was not revoked in the interim. Relying party can use the > later CRL for archiving the transaction. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of A. Jerman Blazic > Sent: Monday, November 01, 2004 1:52 PM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > > Dear all, > > Following the "e-notary" discussion in the last month I see that > requirements have been rapidly shifted and are now reflecting the > certification and validation services. Coming to this point I would like to > draw your attention to the fundamental problem that at least I have when > playing around with the scenario of digitally signed documents, which is > however the crucial focus of TAS services at this point. I also think that > real scenarios would help us understand the problems more clearly and find > appropriate solution(s). > > Now let's assume that a signed document enters an archive. What happens in > the first place is signature validation (since we assume that there is no > point to archive a non-valid document, although such scenarios are also > possible). We also assume that TAS protocols and ERS are in place. So, what > we need is some fixation in time that signature (and document) existed at > some point in time (archiving time!). Providing evidence for a document is > not a problem, but for a signature there are some sequence issues. > > Preserving signatures is based on reference information and evidence record. > Let's start with T1, when a CRL has been issued and the next time the CRL is > issued is marked with T5. Now we need to collect some reference information > (certificates, CRLs, etc.), validate the signature and pack everything > together before creating the evidence record (timestamp). At time T2 a > timestamp is requested for collected data following by timestamp issued at > T3. Until T5 we have enough time to revoke the certificate related to > digital signature archived, which happens at T4 and we can end up with > archived invalid signature, although it was submitted to the archive before > revocation happened. > > The problem with CRLs is that they might not be synchronized with revocation > mechanisms and there is no real information whether a signature is valid or > not at specific point in time. In theory CRLs should be issued immediately > after a certificate is revoked, but in practice things are not the same, > since the procedure itself already has some timeframe (the ideal solution is > to stop the time during the validation process). > > Now, there are options to use more than one evidence record for a single > data (signature) but I am afraid such procedures might get overall concept > very complicated and bulky, especially when performing procedures over > groups of data. I think we should pay some more attention to archival data > structures and mechanisms supporting TAS operation. I would appreciate if > some feedback would reach my inbox concerning the mentioned problem and I > also hope such discussion(s) would unveil the black box internal mechanisms, > which we named TAS or whatever and after all, solve the main problem of > LTANS requirements on data export. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > Sent: Thursday, October 28, 2004 4:18 PM > > To: ietf-ltans@imc.org > > Subject: Re: Discussion of notareqs document > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > Paul-André, > > > > (text deleted) > > > > > > > > This is another proof of the sound approach of > > LTANS which links "data certs" and "secure archived". Any > > "data cert" must not only be signed, but a detailed log entry > > must be archived in a secure way (non rewritable medium, hash > > linking). This mandatory combination was a major rationale of > > the openevidence project (the technical solution by then was > > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > > > > > There is no such mandatory comnbination for LTANS: data needs to be > > signed (and time-stamped) by the archive service, but the log is not > > intended to be used as an evidence. > > > > > > I am exactly suggesting that it be. > > > > We are preparing a requirements document and not some "a posteriori" > > rationale for a given protocol or service. My strong suggestion, > > based on several years activities for several customers, is indeed > > that the "certified archival" of "detailed and signed" log is a "must" > > for a large majority of actual applications and uses cases. > > > > What the most "educated" or aware customers do require is a complete > > set of "evidence management" services. (What they call in France > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > will be able to exhibit in order to dissuade "others" to initiate a > > litigation, or whenever unsuccessfull, what they will be able to > > exhibit as evidence elements in a court). > > > > My personal view of the whole justification of LTANS context is, as I > > am convinced that this type of requirements will be generalized, that > > the IETF succeeds in proposing and establishing standards that wil > > enable : > > > > > > 1. technical interop between business partners > > 2. technical interop between solution providers > > > > 3. the judges and their expert to master the e-material > > (because it conforms to standard and because there exist tools enbling > > to manipulate them) > > 4. the possibility of mutual recognition within a business > > community > > > > And I have no longer any doubt that "certified archived logs" (more > > or less equivalent of the certified archival of requests and receipts) > > will be one of, if not, the most usefull component. > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > -- > > > > Edelweb > > Groupe ON-X Pôle Sécurité > > paul-andre.pays@edelweb.fr papays@on-x.com > > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > > la signature électronique, http://edelpki.edelweb.fr/ vous > > permet d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > From owner-ietf-ltans Wed Nov 3 05:10:13 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DADwU029636; Wed, 3 Nov 2004 05:10:13 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DADwc029635; Wed, 3 Nov 2004 05:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3DABtt029559 for ; Wed, 3 Nov 2004 05:10:12 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 29430 invoked by uid 48); 3 Nov 2004 13:10:04 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 14:10:04 +0100 Message-ID: <1099487404.4188d8ac64d37@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 14:10:04 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411021338.iA2DcTAU027628@host13.websitesource.com> In-Reply-To: <200411021338.iA2DcTAU027628@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, > Regarding WG focus, the recent shift in requirements focus has been w.r.t. > to the "notary" requirements. The long-term archive requirements focus on > the types of concerns you mention. That focus has been relatively stable > for some time, though the requirements document itself is still evolving. II know that, but correct me if I am wrong: e-notaries were shifted to certification services (and this is not the real point), which should provide among other things some attestation on validity of digital signatures. How this validity is delivered is a crucial question. There might be a DVCS-like service but the service itself should provide enough information by itself to prove that a signature was valid at T1 and not wait until T4. DVCS does provide some attestation, but it is not clear (at least to me), how the attestation is actually generated. Can we take DVCS response as "enough information" to enclose it to a signature and pack everything? Peter? > Regarding signature preservation, as discussed so far, an evidence record is > relative to a single time T1, e.g. the time of submission to the archive. > Retroactive revocation would need to be considered before committing the > data to an archive and initiating an evidence record (using the mechanisms > that have been discussed so far). Even if a CRL were issued immediately > when a cert was revoked, it's revocation time might be before T1. Well that is the general problem. Legislation states that post-festum revocation is not allowed, meaning the time of revocation can not be defined before the time when revocation was requested. It may take some time before next CRL is published, so when this information is published is the main issue. If we consider that time stops at the time of processing, some attestation could be produced. The practice? I am not sure.... Also, TAS performs its own validation at time T1 and by that states that signature existed at T1. Post-festum validation should only provide information that nothing really happened before T1.... I don't > believe I heard anyone discuss using an evidence record to verify a > signature relative to multiple points in time (that could get ugly). It > seems unlikely that retroactive revocation applied after several periodic > refresh operations (which should be relatively infrequent) at time T4 should > invalidate a signature generated at, or before, time T1. Well, I am afraid exactly of that. See my answer to Santosh - I am not stating that this is the way to go, I just would like to clear up this issue before some concrete steps forward are made. We have been playing with implementation of second generation of TAS but this problems causes headaches, not to mention the fulfillment of LTANS data grouping requirement... The main outcome I would like to see is at least a common understanding of the problem and some conclusions on how to manage such data. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > > Sent: Monday, November 01, 2004 1:52 PM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > Dear all, > > > > Following the "e-notary" discussion in the last month I see > > that requirements have been rapidly shifted and are now > > reflecting the certification and validation services. Coming > > to this point I would like to draw your attention to the > > fundamental problem that at least I have when playing around > > with the scenario of digitally signed documents, which is > > however the crucial focus of TAS services at this point. I > > also think that real scenarios would help us understand the > > problems more clearly and find appropriate solution(s). > > > > Now let's assume that a signed document enters an archive. > > What happens in the first place is signature validation > > (since we assume that there is no point to archive a > > non-valid document, although such scenarios are also > > possible). We also assume that TAS protocols and ERS are in > > place. So, what we need is some fixation in time that > > signature (and document) existed at some point in time > > (archiving time!). Providing evidence for a document is not a > > problem, but for a signature there are some sequence issues. > > > > Preserving signatures is based on reference information and > > evidence record. > > Let's start with T1, when a CRL has been issued and the next > > time the CRL is issued is marked with T5. Now we need to > > collect some reference information (certificates, CRLs, > > etc.), validate the signature and pack everything together > > before creating the evidence record (timestamp). At time T2 a > > timestamp is requested for collected data following by > > timestamp issued at T3. Until T5 we have enough time to > > revoke the certificate related to digital signature archived, > > which happens at T4 and we can end up with archived invalid > > signature, although it was submitted to the archive before > > revocation happened. > > > > The problem with CRLs is that they might not be synchronized > > with revocation mechanisms and there is no real information > > whether a signature is valid or not at specific point in > > time. In theory CRLs should be issued immediately after a > > certificate is revoked, but in practice things are not the > > same, since the procedure itself already has some timeframe > > (the ideal solution is to stop the time during the validation > > process). > > > > Now, there are options to use more than one evidence record > > for a single data (signature) but I am afraid such procedures > > might get overall concept very complicated and bulky, > > especially when performing procedures over groups of data. I > > think we should pay some more attention to archival data > > structures and mechanisms supporting TAS operation. I would > > appreciate if some feedback would reach my inbox concerning > > the mentioned problem and I also hope such discussion(s) > > would unveil the black box internal mechanisms, which we > > named TAS or whatever and after all, solve the main problem > > of LTANS requirements on data export. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > > Sent: Thursday, October 28, 2004 4:18 PM > > > To: ietf-ltans@imc.org > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > Paul-André, > > > > > > (text deleted) > > > > > > > > > > > > This is another proof of the sound approach of > > LTANS which links > > > "data certs" and "secure archived". Any "data cert" must > > not only be > > > signed, but a detailed log entry must be archived in a > > secure way (non > > > rewritable medium, hash linking). This mandatory combination was a > > > major rationale of the openevidence project (the technical > > solution by > > > then was a a combination of TSP RFC3061, DVCS RFC3029 and > > > hash-linking) > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > > needs to be > > > signed (and time-stamped) by the archive service, but the > > log is not > > > intended to be used as an evidence. > > > > > > > > > I am exactly suggesting that it be. > > > > > > We are preparing a requirements document and not some "a > > posteriori" > > > rationale for a given protocol or service. My strong suggestion, > > > based on several years activities for several customers, is indeed > > > that the "certified archival" of "detailed and signed" log > > is a "must" > > > for a large majority of actual applications and uses cases. > > > > > > What the most "educated" or aware customers do require is a > > complete > > > set of "evidence management" services. (What they call in France > > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > > will be able to exhibit in order to dissuade "others" to initiate a > > > litigation, or whenever unsuccessfull, what they will be able to > > > exhibit as evidence elements in a court). > > > > > > My personal view of the whole justification of LTANS > > context is, as I > > > am convinced that this type of requirements will be > > generalized, that > > > the IETF succeeds in proposing and establishing standards that wil > > > enable : > > > > > > > > > 1. technical interop between business partners > > > 2. technical interop between solution providers > > > > > > 3. the judges and their expert to master the e-material > > > (because it conforms to standard and because there exist > > tools enbling > > > to manipulate them) > > > 4. the possibility of mutual recognition within a business > > > community > > > > > > And I have no longer any doubt that "certified archived > > logs" (more > > > or less equivalent of the certified archival of requests > > and receipts) > > > will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Edelweb > > > Groupe ON-X Pôle Sécurité > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > From owner-ietf-ltans Wed Nov 3 05:12:59 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DCxmM030820; Wed, 3 Nov 2004 05:12:59 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DCx2T030819; Wed, 3 Nov 2004 05:12:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DCwsO030813 for ; Wed, 3 Nov 2004 05:12:59 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3Cjcn3014772; Wed, 3 Nov 2004 07:45:40 -0500 Message-Id: <200411031245.iA3Cjcn3014772@host13.websitesource.com> From: "Carl Wallace" To: , Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 07:45:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099479150.4188b86e846b6@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBlbL2qLxODQzyQH+DnphOUo1cmgAChFFw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3DCxsO030814 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why would a CRL be issued so infrequently for someone signing documents? Usually that is the case for offline roots and such. In any case, if when the evidence record is validated the signer's certificate is not expired, the relying party (or data validation service) should retrieve the current CRL and see if the certificate has been revoked and if so whether or not there is a revocation date indication. The revocation date can be compared to the T1 in the record. The TAS could be configured to retrieve the CRLs shortly before and immediately after the expiration of each signer's certificate (to capture revocation events during the entire life of the certificate). Alternatively, if CRL publication weren't an unpredictable affair (and in most cases it isn't), the TAS could simply be configured to retrieve a CRL after a grace period to support retroactive revocation. The lta requirements document currently mentions retroactive revocation in the security considerations section. Support for retroactive revocation should be added as a requirement in the body of the document. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of aljosa@e5.ijs.si > Sent: Wednesday, November 03, 2004 5:53 AM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > Santosh, > > I am afraid it is not that simple. Let's say I want a Premium > service for some very important document which is also time > critical. There are no rules when CRLs are refreshed and in > some scenarios CRLs are not issued for another month or so. > Waiting your document to be formally processed after a > month... well that is just not the evolving scenario. The > basic concept of solving this problem should use two time > evidences at least. First one to attest that a signature > existed at the time of arrival and the later attestation that > proves the validity of a signature based on some reference > information (CRL more precisely). The things get a bit more > complicated when a document carries several signatures based > on certificates issued by (unsynchronized) CAs. > > However, there are also some conceptual approaches to this > problem. One is to assure that CRLs carry some time evidences > (when they were actually issued – the same used as for TAS) > and that policies clearly declare that CRLs are issued after > some action and that post action publishing is strictly > forbidden (e.g. a certificate can't be revoked back in time > and the revocation is valid only after a CRL is issued). This > way we could at least shorten the time frame left for > manipulation (I am not counting the processing time here, > which is unavoidable). > > I think we should agree at least on some basic concepts here > and define some TAS framework understanding. Also, > conclusions should be propagated to other areas and WGs to > achieve some consensus on how to properly manage signed > documents in time. > > aleksej > > Quoting Santosh Chokhani : > > > > > Aleksej, > > > > The archive package should contain the CRL used to verify > the transaction. > > That coupled with other times will show when the transaction was > > received and processed. > > > > When speed is of not essence, the relying party can always > wait for a > > CRL issued after the transaction was received to verify. This will > > ensure that the certificate was not revoked in the interim. > Relying > > party can use the later CRL for archiving the transaction. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Monday, November 01, 2004 1:52 PM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > > > Dear all, > > > > Following the "e-notary" discussion in the last month I see that > > requirements have been rapidly shifted and are now reflecting the > > certification and validation services. Coming to this point I would > > like to draw your attention to the fundamental problem that > at least I > > have when playing around with the scenario of digitally signed > > documents, which is however the crucial focus of TAS > services at this > > point. I also think that real scenarios would help us > understand the > > problems more clearly and find appropriate solution(s). > > > > Now let's assume that a signed document enters an archive. What > > happens in the first place is signature validation (since we assume > > that there is no point to archive a non-valid document, > although such > > scenarios are also possible). We also assume that TAS protocols and > > ERS are in place. So, what we need is some fixation in time that > > signature (and document) existed at some point in time (archiving > > time!). Providing evidence for a document is not a problem, > but for a signature there are some sequence issues. > > > > Preserving signatures is based on reference information and > evidence record. > > Let's start with T1, when a CRL has been issued and the > next time the > > CRL is issued is marked with T5. Now we need to collect > some reference > > information (certificates, CRLs, etc.), validate the signature and > > pack everything together before creating the evidence record > > (timestamp). At time T2 a timestamp is requested for collected data > > following by timestamp issued at T3. Until T5 we have > enough time to > > revoke the certificate related to digital signature archived, which > > happens at T4 and we can end up with archived invalid signature, > > although it was submitted to the archive before revocation happened. > > > > The problem with CRLs is that they might not be synchronized with > > revocation mechanisms and there is no real information whether a > > signature is valid or not at specific point in time. In theory CRLs > > should be issued immediately after a certificate is revoked, but in > > practice things are not the same, since the procedure > itself already > > has some timeframe (the ideal solution is to stop the time > during the validation process). > > > > Now, there are options to use more than one evidence record for a > > single data (signature) but I am afraid such procedures might get > > overall concept very complicated and bulky, especially when > performing > > procedures over groups of data. I think we should pay some more > > attention to archival data structures and mechanisms supporting TAS > > operation. I would appreciate if some feedback would reach my inbox > > concerning the mentioned problem and I also hope such discussion(s) > > would unveil the black box internal mechanisms, which we > named TAS or > > whatever and after all, solve the main problem of LTANS > requirements on data export. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > Paul-André PAYS > > > Sent: Thursday, October 28, 2004 4:18 PM > > > To: ietf-ltans@imc.org > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > Paul-André, > > > > > > (text deleted) > > > > > > > > > > > > This is another proof of the sound approach of > LTANS which links > > > "data certs" and "secure archived". Any "data cert" must > not only be > > > signed, but a detailed log entry must be archived in a secure way > > > (non rewritable medium, hash linking). This mandatory combination > > > was a major rationale of the openevidence project (the technical > > > solution by then was a a combination of TSP RFC3061, DVCS RFC3029 > > > and hash-linking) > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > needs to be > > > signed (and time-stamped) by the archive service, but the > log is not > > > intended to be used as an evidence. > > > > > > > > > I am exactly suggesting that it be. > > > > > > We are preparing a requirements document and not some "a > posteriori" > > > rationale for a given protocol or service. My strong suggestion, > > > based on several years activities for several customers, > is indeed > > > that the "certified archival" of "detailed and signed" > log is a "must" > > > for a large majority of actual applications and uses cases. > > > > > > What the most "educated" or aware customers do require is > a complete > > > set of "evidence management" services. (What they call in France > > > "Gestion de la Preuve" or "Administration de la Preuve"; > what they > > > will be able to exhibit in order to dissuade "others" to > initiate a > > > litigation, or whenever unsuccessfull, what they will be able to > > > exhibit as evidence elements in a court). > > > > > > My personal view of the whole justification of LTANS > context is, as > > > I am convinced that this type of requirements will be > generalized, > > > that the IETF succeeds in proposing and establishing > standards that > > > wil enable : > > > > > > > > > 1. technical interop between business partners > > > 2. technical interop between solution providers > > > > > > 3. the judges and their expert to master the e-material > > > (because it conforms to standard and because there exist tools > > > enbling to manipulate them) > > > 4. the possibility of mutual recognition within a business > > > community > > > > > > And I have no longer any doubt that "certified archived > logs" (more > > > or less equivalent of the certified archival of requests and > > > receipts) will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Edelweb > > > Groupe ON-X Pôle Sécurité > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > > > > > From owner-ietf-ltans Wed Nov 3 05:30:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DUg9R038900; Wed, 3 Nov 2004 05:30:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DUg8O038899; Wed, 3 Nov 2004 05:30:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DUgYS038892 for ; Wed, 3 Nov 2004 05:30:42 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3DUfn3022363; Wed, 3 Nov 2004 08:30:42 -0500 Message-Id: <200411031330.iA3DUfn3022363@host13.websitesource.com> From: "Carl Wallace" To: , Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 08:30:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099487404.4188d8ac64d37@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBqBvmS56mK/nlT0aRI7UUcobEegAAG4Hw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Well that is the general problem. Legislation states that > post-festum revocation is not allowed, meaning the time of > revocation can not be defined before the time when revocation > was requested. It may take some time before next CRL is > published, so when this information is published is the main > issue. If we consider that time stops at the time of > processing, some attestation could be produced. The practice? > I am not sure.... CRLs do not provide a means of determining "when revocation was requested" vs. the revocation time included in the CRL. That must be enforced by the CRL issuer. > Also, TAS performs its own validation at time T1 and by that > states that signature existed at T1. Post-festum validation > should only provide information that nothing really happened > before T1.... OK, but a TAS may archive an invalid signature (or evidence of invalidity). From owner-ietf-ltans Wed Nov 3 05:52:26 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DqQ8F050837; Wed, 3 Nov 2004 05:52:26 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DqQKY050836; Wed, 3 Nov 2004 05:52:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3DqOSs050827 for ; Wed, 3 Nov 2004 05:52:25 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 31830 invoked by uid 48); 3 Nov 2004 13:52:26 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 14:52:26 +0100 Message-ID: <1099489946.4188e29a48b43@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 14:52:26 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031245.iA3Cjcn3014772@host13.websitesource.com> In-Reply-To: <200411031245.iA3Cjcn3014772@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > Why would a CRL be issued so infrequently for someone signing documents? Well, that is a very good question. But, there are no (technical) restrictions defined except for policy... and, well legislation. > Usually that is the case for offline roots and such. In any case, if when > the evidence record is validated the signer's certificate is not expired, > the relying party (or data validation service) should retrieve the current > CRL and see if the certificate has been revoked and if so whether or not > there is a revocation date indication. The revocation date can be compared > to the T1 in the record. > > The TAS could be configured to retrieve the CRLs shortly before and > immediately after the expiration of each signer's certificate (to capture > revocation events during the entire life of the certificate). I am discussing mostly time critical services. I do not know what do you mean exactly here, since the lifetime of a certificate can span for over 5 years and such archival procedure is just not feasible. TAS must provide response in a very short time (I imagine 24 hours is maximum for time critical services). > Alternatively, if CRL publication weren't an unpredictable affair (and in > most cases it isn't), the TAS could simply be configured to retrieve a CRL > after a grace period to support retroactive revocation. I agree and that is one of possible approaches. I wonder what happens, when retroactive action identifies some critical event (revocation of a certificate) and data are already grouped. We may end up with some completely redundant data (if ungrouping is not possible), which in case when several entities (CAs) are taking role, the scenario gets really ugly. > The lta requirements document currently mentions retroactive revocation in > the security considerations section. Support for retroactive revocation > should be added as a requirement in the body of the document. Good and I fully support that this should be mentioned and highlghten at the very beginning. > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of aljosa@e5.ijs.si > > Sent: Wednesday, November 03, 2004 5:53 AM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > Santosh, > > > > I am afraid it is not that simple. Let's say I want a Premium > > service for some very important document which is also time > > critical. There are no rules when CRLs are refreshed and in > > some scenarios CRLs are not issued for another month or so. > > Waiting your document to be formally processed after a > > month... well that is just not the evolving scenario. The > > basic concept of solving this problem should use two time > > evidences at least. First one to attest that a signature > > existed at the time of arrival and the later attestation that > > proves the validity of a signature based on some reference > > information (CRL more precisely). The things get a bit more > > complicated when a document carries several signatures based > > on certificates issued by (unsynchronized) CAs. > > > > However, there are also some conceptual approaches to this > > problem. One is to assure that CRLs carry some time evidences > > (when they were actually issued – the same used as for TAS) > > and that policies clearly declare that CRLs are issued after > > some action and that post action publishing is strictly > > forbidden (e.g. a certificate can't be revoked back in time > > and the revocation is valid only after a CRL is issued). This > > way we could at least shorten the time frame left for > > manipulation (I am not counting the processing time here, > > which is unavoidable). > > > > I think we should agree at least on some basic concepts here > > and define some TAS framework understanding. Also, > > conclusions should be propagated to other areas and WGs to > > achieve some consensus on how to properly manage signed > > documents in time. > > > > aleksej > > > > Quoting Santosh Chokhani : > > > > > > > > Aleksej, > > > > > > The archive package should contain the CRL used to verify > > the transaction. > > > That coupled with other times will show when the transaction was > > > received and processed. > > > > > > When speed is of not essence, the relying party can always > > wait for a > > > CRL issued after the transaction was received to verify. This will > > > ensure that the certificate was not revoked in the interim. > > Relying > > > party can use the later CRL for archiving the transaction. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Monday, November 01, 2004 1:52 PM > > > To: ietf-ltans@imc.org > > > Subject: RE: Discussion of notareqs document > > > > > > > > > > > > Dear all, > > > > > > Following the "e-notary" discussion in the last month I see that > > > requirements have been rapidly shifted and are now reflecting the > > > certification and validation services. Coming to this point I would > > > like to draw your attention to the fundamental problem that > > at least I > > > have when playing around with the scenario of digitally signed > > > documents, which is however the crucial focus of TAS > > services at this > > > point. I also think that real scenarios would help us > > understand the > > > problems more clearly and find appropriate solution(s). > > > > > > Now let's assume that a signed document enters an archive. What > > > happens in the first place is signature validation (since we assume > > > that there is no point to archive a non-valid document, > > although such > > > scenarios are also possible). We also assume that TAS protocols and > > > ERS are in place. So, what we need is some fixation in time that > > > signature (and document) existed at some point in time (archiving > > > time!). Providing evidence for a document is not a problem, > > but for a signature there are some sequence issues. > > > > > > Preserving signatures is based on reference information and > > evidence record. > > > Let's start with T1, when a CRL has been issued and the > > next time the > > > CRL is issued is marked with T5. Now we need to collect > > some reference > > > information (certificates, CRLs, etc.), validate the signature and > > > pack everything together before creating the evidence record > > > (timestamp). At time T2 a timestamp is requested for collected data > > > following by timestamp issued at T3. Until T5 we have > > enough time to > > > revoke the certificate related to digital signature archived, which > > > happens at T4 and we can end up with archived invalid signature, > > > although it was submitted to the archive before revocation happened. > > > > > > The problem with CRLs is that they might not be synchronized with > > > revocation mechanisms and there is no real information whether a > > > signature is valid or not at specific point in time. In theory CRLs > > > should be issued immediately after a certificate is revoked, but in > > > practice things are not the same, since the procedure > > itself already > > > has some timeframe (the ideal solution is to stop the time > > during the validation process). > > > > > > Now, there are options to use more than one evidence record for a > > > single data (signature) but I am afraid such procedures might get > > > overall concept very complicated and bulky, especially when > > performing > > > procedures over groups of data. I think we should pay some more > > > attention to archival data structures and mechanisms supporting TAS > > > operation. I would appreciate if some feedback would reach my inbox > > > concerning the mentioned problem and I also hope such discussion(s) > > > would unveil the black box internal mechanisms, which we > > named TAS or > > > whatever and after all, solve the main problem of LTANS > > requirements on data export. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > > Paul-André PAYS > > > > Sent: Thursday, October 28, 2004 4:18 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > > > > Paul-André, > > > > > > > > (text deleted) > > > > > > > > > > > > > > > > This is another proof of the sound approach of > > LTANS which links > > > > "data certs" and "secure archived". Any "data cert" must > > not only be > > > > signed, but a detailed log entry must be archived in a secure way > > > > (non rewritable medium, hash linking). This mandatory combination > > > > was a major rationale of the openevidence project (the technical > > > > solution by then was a a combination of TSP RFC3061, DVCS RFC3029 > > > > and hash-linking) > > > > > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > > needs to be > > > > signed (and time-stamped) by the archive service, but the > > log is not > > > > intended to be used as an evidence. > > > > > > > > > > > > I am exactly suggesting that it be. > > > > > > > > We are preparing a requirements document and not some "a > > posteriori" > > > > rationale for a given protocol or service. My strong suggestion, > > > > based on several years activities for several customers, > > is indeed > > > > that the "certified archival" of "detailed and signed" > > log is a "must" > > > > for a large majority of actual applications and uses cases. > > > > > > > > What the most "educated" or aware customers do require is > > a complete > > > > set of "evidence management" services. (What they call in France > > > > "Gestion de la Preuve" or "Administration de la Preuve"; > > what they > > > > will be able to exhibit in order to dissuade "others" to > > initiate a > > > > litigation, or whenever unsuccessfull, what they will be able to > > > > exhibit as evidence elements in a court). > > > > > > > > My personal view of the whole justification of LTANS > > context is, as > > > > I am convinced that this type of requirements will be > > generalized, > > > > that the IETF succeeds in proposing and establishing > > standards that > > > > wil enable : > > > > > > > > > > > > 1. technical interop between business partners > > > > 2. technical interop between solution providers > > > > > > > > 3. the judges and their expert to master the e-material > > > > (because it conforms to standard and because there exist tools > > > > enbling to manipulate them) > > > > 4. the possibility of mutual recognition within a business > > > > community > > > > > > > > And I have no longer any doubt that "certified archived > > logs" (more > > > > or less equivalent of the certified archival of requests and > > > > receipts) will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Edelweb > > > > Groupe ON-X Pôle Sécurité > > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-ltans Wed Nov 3 06:05:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3E5MdK053711; Wed, 3 Nov 2004 06:05:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3E5M0d053710; Wed, 3 Nov 2004 06:05:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3E5Kcq053704 for ; Wed, 3 Nov 2004 06:05:21 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 32306 invoked by uid 48); 3 Nov 2004 14:05:22 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 15:05:22 +0100 Message-ID: <1099490722.4188e5a24fc1b@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 15:05:22 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031330.iA3DUfn3022363@host13.websitesource.com> In-Reply-To: <200411031330.iA3DUfn3022363@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > > Well that is the general problem. Legislation states that > > post-festum revocation is not allowed, meaning the time of > > revocation can not be defined before the time when revocation > > was requested. It may take some time before next CRL is > > published, so when this information is published is the main > > issue. If we consider that time stops at the time of > > processing, some attestation could be produced. The practice? > > I am not sure.... > > CRLs do not provide a means of determining "when revocation was requested" > vs. the revocation time included in the CRL. That must be enforced by the > CRL issuer. Sure, CRL only defines exact time when revocation occurred. If we could rely that this happens in the line when CRL is issued (the very same moment) the problem is solved. At least in theory... > > Also, TAS performs its own validation at time T1 and by that > > states that signature existed at T1. Post-festum validation > > should only provide information that nothing really happened > > before T1.... > > OK, but a TAS may archive an invalid signature (or evidence of invalidity). You are absolutely right here and this is another approach, but I guess user of a "premium" service wants to have attestation of successful archiving ASAP (next second??), and this is where my questions are targeted to. From owner-ietf-ltans Wed Nov 3 06:18:11 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EIB5D057480; Wed, 3 Nov 2004 06:18:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EIB4B057479; Wed, 3 Nov 2004 06:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EIAhk057473 for ; Wed, 3 Nov 2004 06:18:10 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3EIAn3004408 for ; Wed, 3 Nov 2004 09:18:11 -0500 Message-Id: <200411031418.iA3EIAn3004408@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 09:18:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099489946.4188e29a48b43@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBrcC3XNHtg6UsRr6NiWRQvBBhgAAAdc8w Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The TAS could be configured to retrieve the CRLs shortly before and > > immediately after the expiration of each signer's certificate (to > > capture revocation events during the entire life of the > certificate). > > I am discussing mostly time critical services. I do not know > what do you mean exactly here, since the lifetime of a > certificate can span for over 5 years and such archival > procedure is just not feasible. TAS must provide response in > a very short time (I imagine 24 hours is maximum for time > critical services). I meant that collecting the CRL at the end of the certificate lifetime is a good indication of revocation at any point in time. Since the focus is long-term verification, this information may be useful. It is an extreme way to deal with synchronization issues across mulitple CAs. Given the repeated reference to legislation and lack of technical mechanisms, this seems to be a significant component of lta policy. From owner-ietf-ltans Wed Nov 3 06:36:58 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EawPR064383; Wed, 3 Nov 2004 06:36:58 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Eawd5064382; Wed, 3 Nov 2004 06:36:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3EauY4064314 for ; Wed, 3 Nov 2004 06:36:57 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 2095 invoked by uid 48); 3 Nov 2004 14:36:50 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 15:36:50 +0100 Message-ID: <1099492610.4188ed0234ea9@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 15:36:50 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031418.iA3EIAn3004408@host13.websitesource.com> In-Reply-To: <200411031418.iA3EIAn3004408@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > > > > The TAS could be configured to retrieve the CRLs shortly before and > > > immediately after the expiration of each signer's certificate (to > > > capture revocation events during the entire life of the > > certificate). > > > > I am discussing mostly time critical services. I do not know > > what do you mean exactly here, since the lifetime of a > > certificate can span for over 5 years and such archival > > procedure is just not feasible. TAS must provide response in > > a very short time (I imagine 24 hours is maximum for time > > critical services). > > I meant that collecting the CRL at the end of the certificate lifetime is a > good indication of revocation at any point in time. Since the focus is > long-term verification, this information may be useful. It is an extreme > way to deal with synchronization issues across mulitple CAs. Given the > repeated reference to legislation and lack of technical mechanisms, this > seems to be a significant component of lta policy. OK, understand and agree on that. But the "premium" service is still a problem. Some (business) scenarios are build around short lifetimes of documents (e.g. tax declaration, valid for one year). This approach fails. I thnik we should expose the problem in some of the documents and at least provide conceptual approaches (or limitations) to solve them. From owner-ietf-ltans Wed Nov 3 06:45:45 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Ejjgj067692; Wed, 3 Nov 2004 06:45:45 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EjjuG067691; Wed, 3 Nov 2004 06:45:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EjhDY067613 for ; Wed, 3 Nov 2004 06:45:44 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3EjVD08909; Wed, 3 Nov 2004 15:45:31 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 15:45:31 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3EjUF27315; Wed, 3 Nov 2004 15:45:30 +0100 (MET) Date: Wed, 3 Nov 2004 15:45:30 +0100 (MET) From: Peter Sylvester Message-Id: <200411031445.iA3EjUF27315@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Carl, > > > Regarding WG focus, the recent shift in requirements focus has been w.r.t. > > to the "notary" requirements. The long-term archive requirements focus on > > the types of concerns you mention. That focus has been relatively stable > > for some time, though the requirements document itself is still evolving. > > II know that, but correct me if I am wrong: e-notaries were shifted to > certification services (and this is not the real point), which should provide > among other things some attestation on validity of digital signatures. How this > validity is delivered is a crucial question. There might be a DVCS-like service > but the service itself should provide enough information by itself to prove > that a signature was valid at T1 and not wait until T4. DVCS does provide some > attestation, but it is not clear (at least to me), how the attestation is > actually generated. Can we take DVCS response as "enough information" to > enclose it to a signature and pack everything? Peter? There are several aspects: - I think it is not a good statement to say taht one has to prove that a signature was good at some time, but rather that one assert having performed a particular validation, and it succeeded. - IMO opinion there is no reason to wait for a CRL for example. If a relying party just waits, and has no interaction with the user, I don't think that the possibility to determine better whether a signature is valid is enhanced. If the 'signer' is never be confronted with the signature, no problem will be detected, and there is no motivation for revoking a cert. - There are context where consumer rights come into action. In this case it is important to determine when certain delays start, I am pretty sure that is is not sufficient for a relying party to timestamp sopmething in privacy, and confront a user after the delay. Within a delay, a user can 'revoke' the document, without revoking his signing certificate. - Technically the DVCS protocol is neutral about what is actually certified. The idea behind a DVCS attestation concerning a 'signed document' is to perform the validity checking at some time and provide *ALL* information that had been used to do this, i.e., CRLs, OCSP responses, SCVP reponses, DVCS responses, etc. and indicate a time. Anyone in possession of such an attestation can perform the same validaton This approach responds to 'keeping track of a validation act' and the provision of all information. One can combine this with a signature in a similar way as the advance signature formats timestamp. The attestation asserts more than a time stamp since the attesting entity has actually seen a document that corresponds. The notarisation action and the attestation can include an reponse from some archiver (I try to avoid the usage of the word "attestation from an archiver") because the degree of security (expressed by an security envelope) of this archiving attestation may vary, the notarisation could just include an unsigned response if archiver and "notariser" are the same entities. - This usage of a DVCS like service is a bit contrary to the needs of notaries where they serve as information reduction entities. But then, it is for example possible that one takes the elements described in the previous point, archive them, and just return a statement, saying 'All is ok, if details are necessary, they have been archived at XXX under reference RRR'. - Now I don't know what you ask with 'how is the attestation actually generated'? At least it seems to be that it can either contain all information or reference them. > > Regarding signature preservation, as discussed so far, an evidence record is > > relative to a single time T1, e.g. the time of submission to the archive. > > Retroactive revocation would need to be considered before committing the > > data to an archive and initiating an evidence record (using the mechanisms > > that have been discussed so far). Even if a CRL were issued immediately > > when a cert was revoked, it's revocation time might be before T1. > > Well that is the general problem. Legislation states that post-festum revocation > is not allowed, meaning the time of revocation can not be defined before the > time when revocation was requested. It may take some time before next CRL is > published, so when this information is published is the main issue. If we > consider that time stops at the time of processing, some attestation could be > produced. The practice? I am not sure.... > > Also, TAS performs its own validation at time T1 and by that states that > signature existed at T1. Post-festum validation should only provide information > that nothing really happened before T1.... > > I don't > > believe I heard anyone discuss using an evidence record to verify a > > signature relative to multiple points in time (that could get ugly). It > > seems unlikely that retroactive revocation applied after several periodic > > refresh operations (which should be relatively infrequent) at time T4 should > > invalidate a signature generated at, or before, time T1. > > Well, I am afraid exactly of that. See my answer to Santosh - I am not stating > that this is the way to go, I just would like to clear up this issue before > some concrete steps forward are made. We have been playing with implementation > of second generation of TAS but this problems causes headaches, not to mention > the fulfillment of LTANS data grouping requirement... The main outcome I would > like to see is at least a common understanding of the problem and some > conclusions on how to manage such data. Such problems occur as a side quark when trying to make a 100% secure signing device and a requirement of impossibility of non-repudiation. I think it is sufficient to determine the validity of a signature *NOW* and then shift to whatever the transaction processing foresees. Later revocation does not automatically invalidate the signature i.e. the associated engagement. And a successful verification does not inhibit a subsequent repudiation .. From owner-ietf-ltans Wed Nov 3 07:09:43 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9hmO074742; Wed, 3 Nov 2004 07:09:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3F9hNi074741; Wed, 3 Nov 2004 07:09:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9fh3074733 for ; Wed, 3 Nov 2004 07:09:42 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3F9gD09164; Wed, 3 Nov 2004 16:09:42 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 16:09:42 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3F9gs27370; Wed, 3 Nov 2004 16:09:42 +0100 (MET) Date: Wed, 3 Nov 2004 16:09:42 +0100 (MET) From: Peter Sylvester Message-Id: <200411031509.iA3F9gs27370@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > OK, understand and agree on that. But the "premium" service is still a problem. > Some (business) scenarios are build around short lifetimes of documents (e.g. > tax declaration, valid for one year). This approach fails. I thnik we should > expose the problem in some of the documents and at least provide conceptual > approaches (or limitations) to solve them. > I agree with the last sentence. But a solution may be different than expected similar as with New York's problem of horse shit a century ago. :-) A signature on a paper based income declaration has almost no meaning concerning security. It is never verified. As soon as you accept to pay taxes according to what you receive as a "receipt" of your tax declaration, you confirm yourself the validity of your "signature" which still is not verified but the fiscal service may only deduce that if they find out that you haven't declared everything you had "two chances to lie". A digital signature on a "income declaration" thus seems totally unnecessary, it is in fact only a means to limit the number of multiple declaration for the same 'customer', which by each occurence is not a problem because it can be resolved, but their is the simple interest to limit the number of such cases. In all short term scenarios you have some more or less immediate reaction with 'the customer' who in one or the other way will confirm the validity of the signature if the transaction is initiated by the customer. For a 'tax declaration', i.e. the statement from the state ... someone else can explain the requirements? From owner-ietf-ltans Wed Nov 3 07:16:09 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FG9Yn077054; Wed, 3 Nov 2004 07:16:09 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FG9Gk077053; Wed, 3 Nov 2004 07:16:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FG7oT077009 for ; Wed, 3 Nov 2004 07:16:07 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3FFxD09335; Wed, 3 Nov 2004 16:15:59 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 16:15:59 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3FFxZ27414; Wed, 3 Nov 2004 16:15:59 +0100 (MET) Date: Wed, 3 Nov 2004 16:15:59 +0100 (MET) From: Peter Sylvester Message-Id: <200411031515.iA3FFxZ27414@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: Re: XAdES questions Cc: PLUGTESTS-SECURITY@LIST.ETSI.ORG X-Sun-Charset: ISO-8859-1 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Since Denis mentioned ltans, I think it is worth to forward it to the ltans list. ----- Begin Included Message ----- Date: Wed, 3 Nov 2004 15:04:33 +0100 To: "PLUGTESTS-SECURITY: Discussion list on security Interoperability matters" From: Denis Pinkas Subject: Re: XAdES questions To: PLUGTESTS-SECURITY@LIST.ETSI.ORG > Szabo, > You are absolutely right about the problem and this is why I think > that XAdES is inconsistent at this time. The problem of archiving > can not be solved using implementation such as XAdES, which delivers > only partial solution to the problem. In theory you could rely > on CA policy, which should issue CRLs immediately after a certificate > is revoked and even in this scenario some timeframe remains open for > manipulation. However, please keep in mind that XAdES does not limit > itself to some particular reference data but rather leaves this part > of the signature open (at least to my understanding), which means > that you can use other reference information such as DVCS or OCSP > response and carry over the liability to third party or use the method > as you have suggested bellow. I state again that electronic records > and digital signatures preservation is suppose to stay in hands of > trusted archival services, where you can play around arbitrary > implementation, using several timestamps to archive a full archival > process. TAS is certainly the solution. I have sent comments on that topic to the LTANS WG from the IETF introducing the concept of a "cryptographic maintenance policy" that comes separate from the "signature policy" (in fact which must take the relay before the signature policy expires, but may also be used before the signature policy expires). Denis > Best regards > > aleksej > > >>-----Original Message----- >>From: PLUGTESTS-SECURITY: Discussion list on security >>Interoperability matters >>[mailto:PLUGTESTS-SECURITY@LIST.ETSI.ORG] On Behalf Of Szabó Ãron >>Sent: Thursday, October 28, 2004 11:32 AM >>To: PLUGTESTS-SECURITY@LIST.ETSI.ORG >>Subject: Re: XAdES questions >> >>Dear Juan Carlos, >> >>thanks for your comments, they were very useful. I would >>react to some of them. >> >>In connection with "grace period"... >> >>At "time 0" a CRL has been issued, the next issue is at "time 4". >>At "time 1" I request timestamp by generating and sending the >>hash (messageImprint). >>At "time 2" I create the electronic signature with the >>requested timestamp (SigningTime). >>At "time 3" I revoke my certificate. >>At "time 4" I get the newly issued CRL which contains the >>serialNumber of my revoked certificate. >> >>Between "time 0" and "time 4" (CRL issues) can elapse several >>hours. If I want to verify the electronic signature between >>"time 2" and "time 4" I cannot decide whether the signature >>is good or wrong. You're right, I have to wait until the next >>issue of the CRL. But this means, that if I want to create a >>XAdES-A archive signature that cannot be good, because that >>will always contain the CRL that just have been issued at >>"time 0" (but the needed one would be the other one - issued >>at "time 4" or later). I could imagine just one solution to >>create correct XAdES-A, but I'm afraid this could hardly work... >> >>step 1: timestamp request for SigningTime step 2: generating >>SignatureValue and the whole structure step 3: waiting until >>next CRL is issued (i.e. 4 hours) step 4: fetching the newly >>issued CRL (after SigningTime) step 5: generating >>ArchiveTimeStamp upon all needed data >> >>In connection with optional attributes of XAdES... >> >>Why are "Id" and "URI" attributes of elements optional? How >>could be referenced i.e. the optional "Id" of the enveloped >>data by the optional "URI" of Reference tag? If I understand >>well, there is an inconsistency in this question. The >>IncludeType of TimeStampType says (i.e. at >>ArchiveTimeStamp) that "URI" is "required" to several >>included (Include) elements identified by "Id" attribute, but >>those "Id" attributes are "optional". It is needed to change >>the "optional" flag to "required" at those included elements, >>isn't it? Or is there any other way to make references to >>those obejcts, tags? >> >>Best regards, >>Aron >> >>---------------------------------------------------- >>Aron Szabo, M. Sc. >>Research Associate, >>Center of Information Technology >>Budapest University of Technology and Economics >> >>Postal code: 1117 >>Budapest, Hungary >>Address: Magyar tudosok krt. 2. >>E-mail: aron@ik.bme.hu >> > > ----- End Included Message ----- From owner-ietf-ltans Wed Nov 3 07:58:32 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FwWiL093002; Wed, 3 Nov 2004 07:58:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FwWdg093000; Wed, 3 Nov 2004 07:58:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3FwUFj092909 for ; Wed, 3 Nov 2004 07:58:31 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 6582 invoked by uid 48); 3 Nov 2004 15:58:24 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 16:58:24 +0100 Message-ID: <1099497504.41890020217c9@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 16:58:24 +0100 From: aljosa@e5.ijs.si To: PLUGTESTS-SECURITY@LIST.ETSI.ORG, Denis Pinkas Cc: ietf-ltans@imc.org Subject: Re: XAdES questions References: <4188E571.4000504@bull.net> In-Reply-To: <4188E571.4000504@bull.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As Denis mentioned, there is an activity going on by IETF trying to define requirments for long term archival services. You may want to have a look at the current progress and outcomes. Information available at: ltans.edelweb.fr. Quoting Denis Pinkas : > > Szabo, > > > You are absolutely right about the problem and this is why I think > > that XAdES is inconsistent at this time. The problem of archiving > > can not be solved using implementation such as XAdES, which delivers > > only partial solution to the problem. In theory you could rely > > on CA policy, which should issue CRLs immediately after a certificate > > is revoked and even in this scenario some timeframe remains open for > > manipulation. However, please keep in mind that XAdES does not limit > > itself to some particular reference data but rather leaves this part > > of the signature open (at least to my understanding), which means > > that you can use other reference information such as DVCS or OCSP > > response and carry over the liability to third party or use the method > > as you have suggested bellow. I state again that electronic records > > and digital signatures preservation is suppose to stay in hands of > > trusted archival services, where you can play around arbitrary > > implementation, using several timestamps to archive a full archival > > process. > > TAS is certainly the solution. I have sent comments on that topic to the > LTANS WG from the IETF introducing the concept of a "cryptographic > maintenance policy" that comes separate from the "signature policy" (in fact > which must take the relay before the signature policy expires, but may also > be used before the signature policy expires). > > Denis > > > > > Best regards > > > > aleksej > > > > > >>-----Original Message----- > >>From: PLUGTESTS-SECURITY: Discussion list on security > >>Interoperability matters > >>[mailto:PLUGTESTS-SECURITY@LIST.ETSI.ORG] On Behalf Of Szabó Ãron > >>Sent: Thursday, October 28, 2004 11:32 AM > >>To: PLUGTESTS-SECURITY@LIST.ETSI.ORG > >>Subject: Re: XAdES questions > >> > >>Dear Juan Carlos, > >> > >>thanks for your comments, they were very useful. I would > >>react to some of them. > >> > >>In connection with "grace period"... > >> > >>At "time 0" a CRL has been issued, the next issue is at "time 4". > >>At "time 1" I request timestamp by generating and sending the > >>hash (messageImprint). > >>At "time 2" I create the electronic signature with the > >>requested timestamp (SigningTime). > >>At "time 3" I revoke my certificate. > >>At "time 4" I get the newly issued CRL which contains the > >>serialNumber of my revoked certificate. > >> > >>Between "time 0" and "time 4" (CRL issues) can elapse several > >>hours. If I want to verify the electronic signature between > >>"time 2" and "time 4" I cannot decide whether the signature > >>is good or wrong. You're right, I have to wait until the next > >>issue of the CRL. But this means, that if I want to create a > >>XAdES-A archive signature that cannot be good, because that > >>will always contain the CRL that just have been issued at > >>"time 0" (but the needed one would be the other one - issued > >>at "time 4" or later). I could imagine just one solution to > >>create correct XAdES-A, but I'm afraid this could hardly work... > >> > >>step 1: timestamp request for SigningTime step 2: generating > >>SignatureValue and the whole structure step 3: waiting until > >>next CRL is issued (i.e. 4 hours) step 4: fetching the newly > >>issued CRL (after SigningTime) step 5: generating > >>ArchiveTimeStamp upon all needed data > >> > >>In connection with optional attributes of XAdES... > >> > >>Why are "Id" and "URI" attributes of elements optional? How > >>could be referenced i.e. the optional "Id" of the enveloped > >>data by the optional "URI" of Reference tag? If I understand > >>well, there is an inconsistency in this question. The > >>IncludeType of TimeStampType says (i.e. at > >>ArchiveTimeStamp) that "URI" is "required" to several > >>included (Include) elements identified by "Id" attribute, but > >>those "Id" attributes are "optional". It is needed to change > >>the "optional" flag to "required" at those included elements, > >>isn't it? Or is there any other way to make references to > >>those obejcts, tags? > >> > >>Best regards, > >>Aron > >> > >>---------------------------------------------------- > >>Aron Szabo, M. Sc. > >>Research Associate, > >>Center of Information Technology > >>Budapest University of Technology and Economics > >> > >>Postal code: 1117 > >>Budapest, Hungary > >>Address: Magyar tudosok krt. 2. > >>E-mail: aron@ik.bme.hu > >> > > > > > From owner-ietf-ltans Wed Nov 3 08:17:20 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GHKrW001669; Wed, 3 Nov 2004 08:17:20 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GHKsd001668; Wed, 3 Nov 2004 08:17:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GHE77001611 for ; Wed, 3 Nov 2004 08:17:15 -0800 (PST) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA65798; Wed, 3 Nov 2004 17:28:52 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110317165397:809 ; Wed, 3 Nov 2004 17:16:53 +0100 Message-ID: <41890496.7070803@bull.net> Date: Wed, 03 Nov 2004 17:17:26 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: cwallace@orionsec.com, ulrich.pordesch@zv.fraunhofer.de, ralf.brandner@intercomponentware.com CC: ietf-ltans@imc.org, tobias@ixos.de, Russ Housley Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt References: <200410252003.QAA29302@ietf.org> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 17:16:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 17:16:56, Serialize complete at 03/11/2004 17:16:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To the co-editors of draft-ietf-ltans-reqs-03.txt, Copy to the chairman of LTANS, Copy to the Security Area Advisor and Director. I observed that none of the comments I posted on the list on October 1, 2004 has been incorporated in the new draft. Would you have some explanations to explain why ? Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. > > Title : Long-Term Archive Service Requirements > Author(s) : C. Wallace, et al. > Filename : draft-ietf-ltans-reqs-03.txt > Pages : 21 > Date : 2004-10-25 > > There are many scenarios in which users must be able to prove the > existence of data at a specific point in time and be able to > demonstrate the integrity of data since that time, even when the > duration from time of existence to time of demonstration spans a > large period of time. Additionally, users must be able to verify > signatures on digitally signed data many years after the generation > of the signature. This document describes a class of long-term > archive services to support such scenarios and the technical > requirements for interacting with such services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ltans-reqs-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-ietf-ltans Wed Nov 3 08:33:03 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GX3Y1009146; Wed, 3 Nov 2004 08:33:03 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GX3j5009145; Wed, 3 Nov 2004 08:33:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GX2B2009139 for ; Wed, 3 Nov 2004 08:33:03 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3GWOn3022491; Wed, 3 Nov 2004 11:32:25 -0500 Message-Id: <200411031632.iA3GWOn3022491@host13.websitesource.com> From: "Carl Wallace" To: "'Denis Pinkas'" , , Cc: , , "'Russ Housley'" Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt Date: Wed, 3 Nov 2004 11:32:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBwI0ygF4bE7UQQMiRQtbzq0J6JgAAPQ+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41890496.7070803@bull.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, Clearly more than "none of the comments" were addressed. As noted when the draft was posted, this version aimed to address all editorial comments and many of the non-editorial comments. There are several bracketed comments included in the new version that highlight particular areas for discussion. Several of these are related directly to your comments. Additionally, a set of email responses were sent on 10/5 (along with several other responses with questions regarding some of the suggestions). A large amount of your comments were focused on mechanisms. I was not prepared to shift the focus of the requirements document in that direction prior to the deadline for publication. None of your comments are off the table. Carl > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Wednesday, November 03, 2004 11:17 AM > To: cwallace@orionsec.com; ulrich.pordesch@zv.fraunhofer.de; > ralf.brandner@intercomponentware.com > Cc: ietf-ltans@imc.org; tobias@ixos.de; Russ Housley > Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt > > To the co-editors of draft-ietf-ltans-reqs-03.txt, Copy to > the chairman of LTANS, Copy to the Security Area Advisor and Director. > > I observed that none of the comments I posted on the list on > October 1, 2004 has been incorporated in the new draft. > > Would you have some explanations to explain why ? > > Denis > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Long-Term Archive and > Notary Services Working Group of the IETF. > > > > Title : Long-Term Archive Service Requirements > > Author(s) : C. Wallace, et al. > > Filename : draft-ietf-ltans-reqs-03.txt > > Pages : 21 > > Date : 2004-10-25 > > > > There are many scenarios in which users must be able to prove the > > existence of data at a specific point in time and be able to > > demonstrate the integrity of data since that time, even when the > > duration from time of existence to time of demonstration spans a > > large period of time. Additionally, users must be able to verify > > signatures on digitally signed data many years after the > generation > > of the signature. This document describes a class of long-term > > archive services to support such scenarios and the technical > > requirements for interacting with such services. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-ltans-reqs-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > From owner-ietf-ltans Wed Nov 3 09:05:22 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3H5M0M023774; Wed, 3 Nov 2004 09:05:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3H5Mi1023773; Wed, 3 Nov 2004 09:05:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3H5Kjn023733 for ; Wed, 3 Nov 2004 09:05:21 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3H5ND11496; Wed, 3 Nov 2004 18:05:23 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 18:05:23 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3H5MW27929; Wed, 3 Nov 2004 18:05:22 +0100 (MET) Date: Wed, 3 Nov 2004 18:05:22 +0100 (MET) From: Peter Sylvester Message-Id: <200411031705.iA3H5MW27929@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, Since I had send a message to the list that we should carefully address the points you mention, and that a last call is not exactly appropriate, I comment: Larry has send a message inviting to clarify. I thought the ball was in your camp? Peter From owner-ietf-ltans Wed Nov 3 10:00:21 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I0KE6047811; Wed, 3 Nov 2004 10:00:20 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3I0Kf6047810; Wed, 3 Nov 2004 10:00:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I0JSk047796 for ; Wed, 3 Nov 2004 10:00:20 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3I0KD12207; Wed, 3 Nov 2004 19:00:20 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:00:20 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3I0KJ28060; Wed, 3 Nov 2004 19:00:20 +0100 (MET) Date: Wed, 3 Nov 2004 19:00:20 +0100 (MET) From: Peter Sylvester Message-Id: <200411031800.iA3I0KJ28060@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > > Aleksej, > > > > The archive package should contain the CRL used to verify the transaction. > > That coupled with other times will show when the transaction was received > > and processed. > > > > When speed is of not essence, the relying party can always wait for a CRL > > issued after the transaction was received to verify. This will ensure that > > the certificate was not revoked in the interim. Relying party can use the > > later CRL for archiving the transaction. IMO opinion it doesn't give additional value waiting for a new CRL without doing anything in the meantime. If the *impact/effect* of the signatures in question are not confronted to the user in some way, a user may not even think about the possibility to revoke a cert. (I am talking about a signature made at distance.) Then there are also consumer rights with delays. The fact that a signature has been validated with this or that CRL probably doesn't influence at all the rights, even if the signature is proven valid, 100% safe or whatever. (Well the latter was the dream of the banks and merchants). The user does not have to revoke a cert, he can 'revoke/repudiate' the action or document. From owner-ietf-ltans Wed Nov 3 10:11:41 2004 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IBfuT050672; Wed, 3 Nov 2004 10:11:41 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3IBfUM050671; Wed, 3 Nov 2004 10:11:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IBdr6050638 for ; Wed, 3 Nov 2004 10:11:40 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3IBgD12422 for ; Wed, 3 Nov 2004 19:11:42 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:11:42 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3IBfl28116 for ietf-ltans@imc.org; Wed, 3 Nov 2004 19:11:41 +0100 (MET) Date: Wed, 3 Nov 2004 19:11:41 +0100 (MET) From: Peter Sylvester Message-Id: <200411031811.iA3IBfl28116@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Denis, > > Clearly more than "none of the comments" were addressed. As noted when the > draft was posted, this version aimed to address all editorial comments and > many of the non-editorial comments. There are several bracketed comments > included in the new version that highlight particular areas for discussion. > Several of these are related directly to your comments. Additionally, a > set of email responses were sent on 10/5 (along with several other responses > with questions regarding some of the suggestions). A large amount of your > comments were focused on mechanisms. I was not prepared to shift the focus > of the requirements document in that direction prior to the deadline for > publication. None of your comments are off the table. > > Carl > I had the impression that some of the points may be shifting to the notarisation part, by splitting a TAS into a backend archive service that mainly provides some reference to data and some front end notarisation that provides some appropriate attestation(s). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IBfuT050672; Wed, 3 Nov 2004 10:11:41 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3IBfUM050671; Wed, 3 Nov 2004 10:11:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3IBdr6050638 for ; Wed, 3 Nov 2004 10:11:40 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3IBgD12422 for ; Wed, 3 Nov 2004 19:11:42 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:11:42 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3IBfl28116 for ietf-ltans@imc.org; Wed, 3 Nov 2004 19:11:41 +0100 (MET) Date: Wed, 3 Nov 2004 19:11:41 +0100 (MET) From: Peter Sylvester Message-Id: <200411031811.iA3IBfl28116@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Denis, > > Clearly more than "none of the comments" were addressed. As noted when the > draft was posted, this version aimed to address all editorial comments and > many of the non-editorial comments. There are several bracketed comments > included in the new version that highlight particular areas for discussion. > Several of these are related directly to your comments. Additionally, a > set of email responses were sent on 10/5 (along with several other responses > with questions regarding some of the suggestions). A large amount of your > comments were focused on mechanisms. I was not prepared to shift the focus > of the requirements document in that direction prior to the deadline for > publication. None of your comments are off the table. > > Carl > I had the impression that some of the points may be shifting to the notarisation part, by splitting a TAS into a backend archive service that mainly provides some reference to data and some front end notarisation that provides some appropriate attestation(s). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I0KE6047811; Wed, 3 Nov 2004 10:00:20 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3I0Kf6047810; Wed, 3 Nov 2004 10:00:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3I0JSk047796 for ; Wed, 3 Nov 2004 10:00:20 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3I0KD12207; Wed, 3 Nov 2004 19:00:20 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 19:00:20 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3I0KJ28060; Wed, 3 Nov 2004 19:00:20 +0100 (MET) Date: Wed, 3 Nov 2004 19:00:20 +0100 (MET) From: Peter Sylvester Message-Id: <200411031800.iA3I0KJ28060@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > > > > Aleksej, > > > > The archive package should contain the CRL used to verify the transaction. > > That coupled with other times will show when the transaction was received > > and processed. > > > > When speed is of not essence, the relying party can always wait for a CRL > > issued after the transaction was received to verify. This will ensure that > > the certificate was not revoked in the interim. Relying party can use the > > later CRL for archiving the transaction. IMO opinion it doesn't give additional value waiting for a new CRL without doing anything in the meantime. If the *impact/effect* of the signatures in question are not confronted to the user in some way, a user may not even think about the possibility to revoke a cert. (I am talking about a signature made at distance.) Then there are also consumer rights with delays. The fact that a signature has been validated with this or that CRL probably doesn't influence at all the rights, even if the signature is proven valid, 100% safe or whatever. (Well the latter was the dream of the banks and merchants). The user does not have to revoke a cert, he can 'revoke/repudiate' the action or document. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3H5M0M023774; Wed, 3 Nov 2004 09:05:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3H5Mi1023773; Wed, 3 Nov 2004 09:05:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3H5Kjn023733 for ; Wed, 3 Nov 2004 09:05:21 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3H5ND11496; Wed, 3 Nov 2004 18:05:23 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 18:05:23 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3H5MW27929; Wed, 3 Nov 2004 18:05:22 +0100 (MET) Date: Wed, 3 Nov 2004 18:05:22 +0100 (MET) From: Peter Sylvester Message-Id: <200411031705.iA3H5MW27929@chandon.edelweb.fr> To: Denis.Pinkas@bull.net Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt Cc: ietf-ltans@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, Since I had send a message to the list that we should carefully address the points you mention, and that a last call is not exactly appropriate, I comment: Larry has send a message inviting to clarify. I thought the ball was in your camp? Peter Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GX3Y1009146; Wed, 3 Nov 2004 08:33:03 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GX3j5009145; Wed, 3 Nov 2004 08:33:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GX2B2009139 for ; Wed, 3 Nov 2004 08:33:03 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3GWOn3022491; Wed, 3 Nov 2004 11:32:25 -0500 Message-Id: <200411031632.iA3GWOn3022491@host13.websitesource.com> From: "Carl Wallace" To: "'Denis Pinkas'" , , Cc: , , "'Russ Housley'" Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt Date: Wed, 3 Nov 2004 11:32:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTBwI0ygF4bE7UQQMiRQtbzq0J6JgAAPQ+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41890496.7070803@bull.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Denis, Clearly more than "none of the comments" were addressed. As noted when the draft was posted, this version aimed to address all editorial comments and many of the non-editorial comments. There are several bracketed comments included in the new version that highlight particular areas for discussion. Several of these are related directly to your comments. Additionally, a set of email responses were sent on 10/5 (along with several other responses with questions regarding some of the suggestions). A large amount of your comments were focused on mechanisms. I was not prepared to shift the focus of the requirements document in that direction prior to the deadline for publication. None of your comments are off the table. Carl > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Wednesday, November 03, 2004 11:17 AM > To: cwallace@orionsec.com; ulrich.pordesch@zv.fraunhofer.de; > ralf.brandner@intercomponentware.com > Cc: ietf-ltans@imc.org; tobias@ixos.de; Russ Housley > Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt > > To the co-editors of draft-ietf-ltans-reqs-03.txt, Copy to > the chairman of LTANS, Copy to the Security Area Advisor and Director. > > I observed that none of the comments I posted on the list on > October 1, 2004 has been incorporated in the new draft. > > Would you have some explanations to explain why ? > > Denis > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the Long-Term Archive and > Notary Services Working Group of the IETF. > > > > Title : Long-Term Archive Service Requirements > > Author(s) : C. Wallace, et al. > > Filename : draft-ietf-ltans-reqs-03.txt > > Pages : 21 > > Date : 2004-10-25 > > > > There are many scenarios in which users must be able to prove the > > existence of data at a specific point in time and be able to > > demonstrate the integrity of data since that time, even when the > > duration from time of existence to time of demonstration spans a > > large period of time. Additionally, users must be able to verify > > signatures on digitally signed data many years after the > generation > > of the signature. This document describes a class of long-term > > archive services to support such scenarios and the technical > > requirements for interacting with such services. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt > > > > To remove yourself from the I-D Announcement list, send a > message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-ltans-reqs-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GHKrW001669; Wed, 3 Nov 2004 08:17:20 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3GHKsd001668; Wed, 3 Nov 2004 08:17:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3GHE77001611 for ; Wed, 3 Nov 2004 08:17:15 -0800 (PST) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA65798; Wed, 3 Nov 2004 17:28:52 +0100 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2004110317165397:809 ; Wed, 3 Nov 2004 17:16:53 +0100 Message-ID: <41890496.7070803@bull.net> Date: Wed, 03 Nov 2004 17:17:26 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: cwallace@orionsec.com, ulrich.pordesch@zv.fraunhofer.de, ralf.brandner@intercomponentware.com CC: ietf-ltans@imc.org, tobias@ixos.de, Russ Housley Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt References: <200410252003.QAA29302@ietf.org> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 17:16:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 03/11/2004 17:16:56, Serialize complete at 03/11/2004 17:16:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To the co-editors of draft-ietf-ltans-reqs-03.txt, Copy to the chairman of LTANS, Copy to the Security Area Advisor and Director. I observed that none of the comments I posted on the list on October 1, 2004 has been incorporated in the new draft. Would you have some explanations to explain why ? Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. > > Title : Long-Term Archive Service Requirements > Author(s) : C. Wallace, et al. > Filename : draft-ietf-ltans-reqs-03.txt > Pages : 21 > Date : 2004-10-25 > > There are many scenarios in which users must be able to prove the > existence of data at a specific point in time and be able to > demonstrate the integrity of data since that time, even when the > duration from time of existence to time of demonstration spans a > large period of time. Additionally, users must be able to verify > signatures on digitally signed data many years after the generation > of the signature. This document describes a class of long-term > archive services to support such scenarios and the technical > requirements for interacting with such services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ltans-reqs-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FwWiL093002; Wed, 3 Nov 2004 07:58:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FwWdg093000; Wed, 3 Nov 2004 07:58:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3FwUFj092909 for ; Wed, 3 Nov 2004 07:58:31 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 6582 invoked by uid 48); 3 Nov 2004 15:58:24 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 16:58:24 +0100 Message-ID: <1099497504.41890020217c9@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 16:58:24 +0100 From: aljosa@e5.ijs.si To: PLUGTESTS-SECURITY@LIST.ETSI.ORG, Denis Pinkas Cc: ietf-ltans@imc.org Subject: Re: XAdES questions References: <4188E571.4000504@bull.net> In-Reply-To: <4188E571.4000504@bull.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As Denis mentioned, there is an activity going on by IETF trying to define requirments for long term archival services. You may want to have a look at the current progress and outcomes. Information available at: ltans.edelweb.fr. Quoting Denis Pinkas : > > Szabo, > > > You are absolutely right about the problem and this is why I think > > that XAdES is inconsistent at this time. The problem of archiving > > can not be solved using implementation such as XAdES, which delivers > > only partial solution to the problem. In theory you could rely > > on CA policy, which should issue CRLs immediately after a certificate > > is revoked and even in this scenario some timeframe remains open for > > manipulation. However, please keep in mind that XAdES does not limit > > itself to some particular reference data but rather leaves this part > > of the signature open (at least to my understanding), which means > > that you can use other reference information such as DVCS or OCSP > > response and carry over the liability to third party or use the method > > as you have suggested bellow. I state again that electronic records > > and digital signatures preservation is suppose to stay in hands of > > trusted archival services, where you can play around arbitrary > > implementation, using several timestamps to archive a full archival > > process. > > TAS is certainly the solution. I have sent comments on that topic to the > LTANS WG from the IETF introducing the concept of a "cryptographic > maintenance policy" that comes separate from the "signature policy" (in fact > which must take the relay before the signature policy expires, but may also > be used before the signature policy expires). > > Denis > > > > > Best regards > > > > aleksej > > > > > >>-----Original Message----- > >>From: PLUGTESTS-SECURITY: Discussion list on security > >>Interoperability matters > >>[mailto:PLUGTESTS-SECURITY@LIST.ETSI.ORG] On Behalf Of Szabó Ãron > >>Sent: Thursday, October 28, 2004 11:32 AM > >>To: PLUGTESTS-SECURITY@LIST.ETSI.ORG > >>Subject: Re: XAdES questions > >> > >>Dear Juan Carlos, > >> > >>thanks for your comments, they were very useful. I would > >>react to some of them. > >> > >>In connection with "grace period"... > >> > >>At "time 0" a CRL has been issued, the next issue is at "time 4". > >>At "time 1" I request timestamp by generating and sending the > >>hash (messageImprint). > >>At "time 2" I create the electronic signature with the > >>requested timestamp (SigningTime). > >>At "time 3" I revoke my certificate. > >>At "time 4" I get the newly issued CRL which contains the > >>serialNumber of my revoked certificate. > >> > >>Between "time 0" and "time 4" (CRL issues) can elapse several > >>hours. If I want to verify the electronic signature between > >>"time 2" and "time 4" I cannot decide whether the signature > >>is good or wrong. You're right, I have to wait until the next > >>issue of the CRL. But this means, that if I want to create a > >>XAdES-A archive signature that cannot be good, because that > >>will always contain the CRL that just have been issued at > >>"time 0" (but the needed one would be the other one - issued > >>at "time 4" or later). I could imagine just one solution to > >>create correct XAdES-A, but I'm afraid this could hardly work... > >> > >>step 1: timestamp request for SigningTime step 2: generating > >>SignatureValue and the whole structure step 3: waiting until > >>next CRL is issued (i.e. 4 hours) step 4: fetching the newly > >>issued CRL (after SigningTime) step 5: generating > >>ArchiveTimeStamp upon all needed data > >> > >>In connection with optional attributes of XAdES... > >> > >>Why are "Id" and "URI" attributes of elements optional? How > >>could be referenced i.e. the optional "Id" of the enveloped > >>data by the optional "URI" of Reference tag? If I understand > >>well, there is an inconsistency in this question. The > >>IncludeType of TimeStampType says (i.e. at > >>ArchiveTimeStamp) that "URI" is "required" to several > >>included (Include) elements identified by "Id" attribute, but > >>those "Id" attributes are "optional". It is needed to change > >>the "optional" flag to "required" at those included elements, > >>isn't it? Or is there any other way to make references to > >>those obejcts, tags? > >> > >>Best regards, > >>Aron > >> > >>---------------------------------------------------- > >>Aron Szabo, M. Sc. > >>Research Associate, > >>Center of Information Technology > >>Budapest University of Technology and Economics > >> > >>Postal code: 1117 > >>Budapest, Hungary > >>Address: Magyar tudosok krt. 2. > >>E-mail: aron@ik.bme.hu > >> > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FG9Yn077054; Wed, 3 Nov 2004 07:16:09 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3FG9Gk077053; Wed, 3 Nov 2004 07:16:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3FG7oT077009 for ; Wed, 3 Nov 2004 07:16:07 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3FFxD09335; Wed, 3 Nov 2004 16:15:59 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 16:15:59 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3FFxZ27414; Wed, 3 Nov 2004 16:15:59 +0100 (MET) Date: Wed, 3 Nov 2004 16:15:59 +0100 (MET) From: Peter Sylvester Message-Id: <200411031515.iA3FFxZ27414@chandon.edelweb.fr> To: ietf-ltans@imc.org Subject: Re: XAdES questions Cc: PLUGTESTS-SECURITY@LIST.ETSI.ORG X-Sun-Charset: ISO-8859-1 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Since Denis mentioned ltans, I think it is worth to forward it to the ltans list. ----- Begin Included Message ----- Date: Wed, 3 Nov 2004 15:04:33 +0100 To: "PLUGTESTS-SECURITY: Discussion list on security Interoperability matters" From: Denis Pinkas Subject: Re: XAdES questions To: PLUGTESTS-SECURITY@LIST.ETSI.ORG > Szabo, > You are absolutely right about the problem and this is why I think > that XAdES is inconsistent at this time. The problem of archiving > can not be solved using implementation such as XAdES, which delivers > only partial solution to the problem. In theory you could rely > on CA policy, which should issue CRLs immediately after a certificate > is revoked and even in this scenario some timeframe remains open for > manipulation. However, please keep in mind that XAdES does not limit > itself to some particular reference data but rather leaves this part > of the signature open (at least to my understanding), which means > that you can use other reference information such as DVCS or OCSP > response and carry over the liability to third party or use the method > as you have suggested bellow. I state again that electronic records > and digital signatures preservation is suppose to stay in hands of > trusted archival services, where you can play around arbitrary > implementation, using several timestamps to archive a full archival > process. TAS is certainly the solution. I have sent comments on that topic to the LTANS WG from the IETF introducing the concept of a "cryptographic maintenance policy" that comes separate from the "signature policy" (in fact which must take the relay before the signature policy expires, but may also be used before the signature policy expires). Denis > Best regards > > aleksej > > >>-----Original Message----- >>From: PLUGTESTS-SECURITY: Discussion list on security >>Interoperability matters >>[mailto:PLUGTESTS-SECURITY@LIST.ETSI.ORG] On Behalf Of Szabó Ãron >>Sent: Thursday, October 28, 2004 11:32 AM >>To: PLUGTESTS-SECURITY@LIST.ETSI.ORG >>Subject: Re: XAdES questions >> >>Dear Juan Carlos, >> >>thanks for your comments, they were very useful. I would >>react to some of them. >> >>In connection with "grace period"... >> >>At "time 0" a CRL has been issued, the next issue is at "time 4". >>At "time 1" I request timestamp by generating and sending the >>hash (messageImprint). >>At "time 2" I create the electronic signature with the >>requested timestamp (SigningTime). >>At "time 3" I revoke my certificate. >>At "time 4" I get the newly issued CRL which contains the >>serialNumber of my revoked certificate. >> >>Between "time 0" and "time 4" (CRL issues) can elapse several >>hours. If I want to verify the electronic signature between >>"time 2" and "time 4" I cannot decide whether the signature >>is good or wrong. You're right, I have to wait until the next >>issue of the CRL. But this means, that if I want to create a >>XAdES-A archive signature that cannot be good, because that >>will always contain the CRL that just have been issued at >>"time 0" (but the needed one would be the other one - issued >>at "time 4" or later). I could imagine just one solution to >>create correct XAdES-A, but I'm afraid this could hardly work... >> >>step 1: timestamp request for SigningTime step 2: generating >>SignatureValue and the whole structure step 3: waiting until >>next CRL is issued (i.e. 4 hours) step 4: fetching the newly >>issued CRL (after SigningTime) step 5: generating >>ArchiveTimeStamp upon all needed data >> >>In connection with optional attributes of XAdES... >> >>Why are "Id" and "URI" attributes of elements optional? How >>could be referenced i.e. the optional "Id" of the enveloped >>data by the optional "URI" of Reference tag? If I understand >>well, there is an inconsistency in this question. The >>IncludeType of TimeStampType says (i.e. at >>ArchiveTimeStamp) that "URI" is "required" to several >>included (Include) elements identified by "Id" attribute, but >>those "Id" attributes are "optional". It is needed to change >>the "optional" flag to "required" at those included elements, >>isn't it? Or is there any other way to make references to >>those obejcts, tags? >> >>Best regards, >>Aron >> >>---------------------------------------------------- >>Aron Szabo, M. Sc. >>Research Associate, >>Center of Information Technology >>Budapest University of Technology and Economics >> >>Postal code: 1117 >>Budapest, Hungary >>Address: Magyar tudosok krt. 2. >>E-mail: aron@ik.bme.hu >> > > ----- End Included Message ----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9hmO074742; Wed, 3 Nov 2004 07:09:43 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3F9hNi074741; Wed, 3 Nov 2004 07:09:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3F9fh3074733 for ; Wed, 3 Nov 2004 07:09:42 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3F9gD09164; Wed, 3 Nov 2004 16:09:42 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 16:09:42 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3F9gs27370; Wed, 3 Nov 2004 16:09:42 +0100 (MET) Date: Wed, 3 Nov 2004 16:09:42 +0100 (MET) From: Peter Sylvester Message-Id: <200411031509.iA3F9gs27370@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > OK, understand and agree on that. But the "premium" service is still a problem. > Some (business) scenarios are build around short lifetimes of documents (e.g. > tax declaration, valid for one year). This approach fails. I thnik we should > expose the problem in some of the documents and at least provide conceptual > approaches (or limitations) to solve them. > I agree with the last sentence. But a solution may be different than expected similar as with New York's problem of horse shit a century ago. :-) A signature on a paper based income declaration has almost no meaning concerning security. It is never verified. As soon as you accept to pay taxes according to what you receive as a "receipt" of your tax declaration, you confirm yourself the validity of your "signature" which still is not verified but the fiscal service may only deduce that if they find out that you haven't declared everything you had "two chances to lie". A digital signature on a "income declaration" thus seems totally unnecessary, it is in fact only a means to limit the number of multiple declaration for the same 'customer', which by each occurence is not a problem because it can be resolved, but their is the simple interest to limit the number of such cases. In all short term scenarios you have some more or less immediate reaction with 'the customer' who in one or the other way will confirm the validity of the signature if the transaction is initiated by the customer. For a 'tax declaration', i.e. the statement from the state ... someone else can explain the requirements? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Ejjgj067692; Wed, 3 Nov 2004 06:45:45 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EjjuG067691; Wed, 3 Nov 2004 06:45:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EjhDY067613 for ; Wed, 3 Nov 2004 06:45:44 -0800 (PST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id iA3EjVD08909; Wed, 3 Nov 2004 15:45:31 +0100 (MET) Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 3 Nov 2004 15:45:31 +0100 (MET) Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id iA3EjUF27315; Wed, 3 Nov 2004 15:45:30 +0100 (MET) Date: Wed, 3 Nov 2004 15:45:30 +0100 (MET) From: Peter Sylvester Message-Id: <200411031445.iA3EjUF27315@chandon.edelweb.fr> To: ietf-ltans@imc.org, aljosa@e5.ijs.si Subject: RE: Discussion of notareqs document X-Sun-Charset: US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Carl, > > > Regarding WG focus, the recent shift in requirements focus has been w.r.t. > > to the "notary" requirements. The long-term archive requirements focus on > > the types of concerns you mention. That focus has been relatively stable > > for some time, though the requirements document itself is still evolving. > > II know that, but correct me if I am wrong: e-notaries were shifted to > certification services (and this is not the real point), which should provide > among other things some attestation on validity of digital signatures. How this > validity is delivered is a crucial question. There might be a DVCS-like service > but the service itself should provide enough information by itself to prove > that a signature was valid at T1 and not wait until T4. DVCS does provide some > attestation, but it is not clear (at least to me), how the attestation is > actually generated. Can we take DVCS response as "enough information" to > enclose it to a signature and pack everything? Peter? There are several aspects: - I think it is not a good statement to say taht one has to prove that a signature was good at some time, but rather that one assert having performed a particular validation, and it succeeded. - IMO opinion there is no reason to wait for a CRL for example. If a relying party just waits, and has no interaction with the user, I don't think that the possibility to determine better whether a signature is valid is enhanced. If the 'signer' is never be confronted with the signature, no problem will be detected, and there is no motivation for revoking a cert. - There are context where consumer rights come into action. In this case it is important to determine when certain delays start, I am pretty sure that is is not sufficient for a relying party to timestamp sopmething in privacy, and confront a user after the delay. Within a delay, a user can 'revoke' the document, without revoking his signing certificate. - Technically the DVCS protocol is neutral about what is actually certified. The idea behind a DVCS attestation concerning a 'signed document' is to perform the validity checking at some time and provide *ALL* information that had been used to do this, i.e., CRLs, OCSP responses, SCVP reponses, DVCS responses, etc. and indicate a time. Anyone in possession of such an attestation can perform the same validaton This approach responds to 'keeping track of a validation act' and the provision of all information. One can combine this with a signature in a similar way as the advance signature formats timestamp. The attestation asserts more than a time stamp since the attesting entity has actually seen a document that corresponds. The notarisation action and the attestation can include an reponse from some archiver (I try to avoid the usage of the word "attestation from an archiver") because the degree of security (expressed by an security envelope) of this archiving attestation may vary, the notarisation could just include an unsigned response if archiver and "notariser" are the same entities. - This usage of a DVCS like service is a bit contrary to the needs of notaries where they serve as information reduction entities. But then, it is for example possible that one takes the elements described in the previous point, archive them, and just return a statement, saying 'All is ok, if details are necessary, they have been archived at XXX under reference RRR'. - Now I don't know what you ask with 'how is the attestation actually generated'? At least it seems to be that it can either contain all information or reference them. > > Regarding signature preservation, as discussed so far, an evidence record is > > relative to a single time T1, e.g. the time of submission to the archive. > > Retroactive revocation would need to be considered before committing the > > data to an archive and initiating an evidence record (using the mechanisms > > that have been discussed so far). Even if a CRL were issued immediately > > when a cert was revoked, it's revocation time might be before T1. > > Well that is the general problem. Legislation states that post-festum revocation > is not allowed, meaning the time of revocation can not be defined before the > time when revocation was requested. It may take some time before next CRL is > published, so when this information is published is the main issue. If we > consider that time stops at the time of processing, some attestation could be > produced. The practice? I am not sure.... > > Also, TAS performs its own validation at time T1 and by that states that > signature existed at T1. Post-festum validation should only provide information > that nothing really happened before T1.... > > I don't > > believe I heard anyone discuss using an evidence record to verify a > > signature relative to multiple points in time (that could get ugly). It > > seems unlikely that retroactive revocation applied after several periodic > > refresh operations (which should be relatively infrequent) at time T4 should > > invalidate a signature generated at, or before, time T1. > > Well, I am afraid exactly of that. See my answer to Santosh - I am not stating > that this is the way to go, I just would like to clear up this issue before > some concrete steps forward are made. We have been playing with implementation > of second generation of TAS but this problems causes headaches, not to mention > the fulfillment of LTANS data grouping requirement... The main outcome I would > like to see is at least a common understanding of the problem and some > conclusions on how to manage such data. Such problems occur as a side quark when trying to make a 100% secure signing device and a requirement of impossibility of non-repudiation. I think it is sufficient to determine the validity of a signature *NOW* and then shift to whatever the transaction processing foresees. Later revocation does not automatically invalidate the signature i.e. the associated engagement. And a successful verification does not inhibit a subsequent repudiation .. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EawPR064383; Wed, 3 Nov 2004 06:36:58 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Eawd5064382; Wed, 3 Nov 2004 06:36:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3EauY4064314 for ; Wed, 3 Nov 2004 06:36:57 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 2095 invoked by uid 48); 3 Nov 2004 14:36:50 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 15:36:50 +0100 Message-ID: <1099492610.4188ed0234ea9@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 15:36:50 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031418.iA3EIAn3004408@host13.websitesource.com> In-Reply-To: <200411031418.iA3EIAn3004408@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > > > > The TAS could be configured to retrieve the CRLs shortly before and > > > immediately after the expiration of each signer's certificate (to > > > capture revocation events during the entire life of the > > certificate). > > > > I am discussing mostly time critical services. I do not know > > what do you mean exactly here, since the lifetime of a > > certificate can span for over 5 years and such archival > > procedure is just not feasible. TAS must provide response in > > a very short time (I imagine 24 hours is maximum for time > > critical services). > > I meant that collecting the CRL at the end of the certificate lifetime is a > good indication of revocation at any point in time. Since the focus is > long-term verification, this information may be useful. It is an extreme > way to deal with synchronization issues across mulitple CAs. Given the > repeated reference to legislation and lack of technical mechanisms, this > seems to be a significant component of lta policy. OK, understand and agree on that. But the "premium" service is still a problem. Some (business) scenarios are build around short lifetimes of documents (e.g. tax declaration, valid for one year). This approach fails. I thnik we should expose the problem in some of the documents and at least provide conceptual approaches (or limitations) to solve them. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EIB5D057480; Wed, 3 Nov 2004 06:18:11 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3EIB4B057479; Wed, 3 Nov 2004 06:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3EIAhk057473 for ; Wed, 3 Nov 2004 06:18:10 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3EIAn3004408 for ; Wed, 3 Nov 2004 09:18:11 -0500 Message-Id: <200411031418.iA3EIAn3004408@host13.websitesource.com> From: "Carl Wallace" To: Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 09:18:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099489946.4188e29a48b43@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBrcC3XNHtg6UsRr6NiWRQvBBhgAAAdc8w Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > The TAS could be configured to retrieve the CRLs shortly before and > > immediately after the expiration of each signer's certificate (to > > capture revocation events during the entire life of the > certificate). > > I am discussing mostly time critical services. I do not know > what do you mean exactly here, since the lifetime of a > certificate can span for over 5 years and such archival > procedure is just not feasible. TAS must provide response in > a very short time (I imagine 24 hours is maximum for time > critical services). I meant that collecting the CRL at the end of the certificate lifetime is a good indication of revocation at any point in time. Since the focus is long-term verification, this information may be useful. It is an extreme way to deal with synchronization issues across mulitple CAs. Given the repeated reference to legislation and lack of technical mechanisms, this seems to be a significant component of lta policy. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3E5MdK053711; Wed, 3 Nov 2004 06:05:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3E5M0d053710; Wed, 3 Nov 2004 06:05:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3E5Kcq053704 for ; Wed, 3 Nov 2004 06:05:21 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 32306 invoked by uid 48); 3 Nov 2004 14:05:22 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 15:05:22 +0100 Message-ID: <1099490722.4188e5a24fc1b@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 15:05:22 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031330.iA3DUfn3022363@host13.websitesource.com> In-Reply-To: <200411031330.iA3DUfn3022363@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > > Well that is the general problem. Legislation states that > > post-festum revocation is not allowed, meaning the time of > > revocation can not be defined before the time when revocation > > was requested. It may take some time before next CRL is > > published, so when this information is published is the main > > issue. If we consider that time stops at the time of > > processing, some attestation could be produced. The practice? > > I am not sure.... > > CRLs do not provide a means of determining "when revocation was requested" > vs. the revocation time included in the CRL. That must be enforced by the > CRL issuer. Sure, CRL only defines exact time when revocation occurred. If we could rely that this happens in the line when CRL is issued (the very same moment) the problem is solved. At least in theory... > > Also, TAS performs its own validation at time T1 and by that > > states that signature existed at T1. Post-festum validation > > should only provide information that nothing really happened > > before T1.... > > OK, but a TAS may archive an invalid signature (or evidence of invalidity). You are absolutely right here and this is another approach, but I guess user of a "premium" service wants to have attestation of successful archiving ASAP (next second??), and this is where my questions are targeted to. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DqQ8F050837; Wed, 3 Nov 2004 05:52:26 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DqQKY050836; Wed, 3 Nov 2004 05:52:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3DqOSs050827 for ; Wed, 3 Nov 2004 05:52:25 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 31830 invoked by uid 48); 3 Nov 2004 13:52:26 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 14:52:26 +0100 Message-ID: <1099489946.4188e29a48b43@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 14:52:26 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411031245.iA3Cjcn3014772@host13.websitesource.com> In-Reply-To: <200411031245.iA3Cjcn3014772@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Quoting Carl Wallace : > Why would a CRL be issued so infrequently for someone signing documents? Well, that is a very good question. But, there are no (technical) restrictions defined except for policy... and, well legislation. > Usually that is the case for offline roots and such. In any case, if when > the evidence record is validated the signer's certificate is not expired, > the relying party (or data validation service) should retrieve the current > CRL and see if the certificate has been revoked and if so whether or not > there is a revocation date indication. The revocation date can be compared > to the T1 in the record. > > The TAS could be configured to retrieve the CRLs shortly before and > immediately after the expiration of each signer's certificate (to capture > revocation events during the entire life of the certificate). I am discussing mostly time critical services. I do not know what do you mean exactly here, since the lifetime of a certificate can span for over 5 years and such archival procedure is just not feasible. TAS must provide response in a very short time (I imagine 24 hours is maximum for time critical services). > Alternatively, if CRL publication weren't an unpredictable affair (and in > most cases it isn't), the TAS could simply be configured to retrieve a CRL > after a grace period to support retroactive revocation. I agree and that is one of possible approaches. I wonder what happens, when retroactive action identifies some critical event (revocation of a certificate) and data are already grouped. We may end up with some completely redundant data (if ungrouping is not possible), which in case when several entities (CAs) are taking role, the scenario gets really ugly. > The lta requirements document currently mentions retroactive revocation in > the security considerations section. Support for retroactive revocation > should be added as a requirement in the body of the document. Good and I fully support that this should be mentioned and highlghten at the very beginning. > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of aljosa@e5.ijs.si > > Sent: Wednesday, November 03, 2004 5:53 AM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > Santosh, > > > > I am afraid it is not that simple. Let's say I want a Premium > > service for some very important document which is also time > > critical. There are no rules when CRLs are refreshed and in > > some scenarios CRLs are not issued for another month or so. > > Waiting your document to be formally processed after a > > month... well that is just not the evolving scenario. The > > basic concept of solving this problem should use two time > > evidences at least. First one to attest that a signature > > existed at the time of arrival and the later attestation that > > proves the validity of a signature based on some reference > > information (CRL more precisely). The things get a bit more > > complicated when a document carries several signatures based > > on certificates issued by (unsynchronized) CAs. > > > > However, there are also some conceptual approaches to this > > problem. One is to assure that CRLs carry some time evidences > > (when they were actually issued – the same used as for TAS) > > and that policies clearly declare that CRLs are issued after > > some action and that post action publishing is strictly > > forbidden (e.g. a certificate can't be revoked back in time > > and the revocation is valid only after a CRL is issued). This > > way we could at least shorten the time frame left for > > manipulation (I am not counting the processing time here, > > which is unavoidable). > > > > I think we should agree at least on some basic concepts here > > and define some TAS framework understanding. Also, > > conclusions should be propagated to other areas and WGs to > > achieve some consensus on how to properly manage signed > > documents in time. > > > > aleksej > > > > Quoting Santosh Chokhani : > > > > > > > > Aleksej, > > > > > > The archive package should contain the CRL used to verify > > the transaction. > > > That coupled with other times will show when the transaction was > > > received and processed. > > > > > > When speed is of not essence, the relying party can always > > wait for a > > > CRL issued after the transaction was received to verify. This will > > > ensure that the certificate was not revoked in the interim. > > Relying > > > party can use the later CRL for archiving the transaction. > > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] > > > On Behalf Of A. Jerman Blazic > > > Sent: Monday, November 01, 2004 1:52 PM > > > To: ietf-ltans@imc.org > > > Subject: RE: Discussion of notareqs document > > > > > > > > > > > > Dear all, > > > > > > Following the "e-notary" discussion in the last month I see that > > > requirements have been rapidly shifted and are now reflecting the > > > certification and validation services. Coming to this point I would > > > like to draw your attention to the fundamental problem that > > at least I > > > have when playing around with the scenario of digitally signed > > > documents, which is however the crucial focus of TAS > > services at this > > > point. I also think that real scenarios would help us > > understand the > > > problems more clearly and find appropriate solution(s). > > > > > > Now let's assume that a signed document enters an archive. What > > > happens in the first place is signature validation (since we assume > > > that there is no point to archive a non-valid document, > > although such > > > scenarios are also possible). We also assume that TAS protocols and > > > ERS are in place. So, what we need is some fixation in time that > > > signature (and document) existed at some point in time (archiving > > > time!). Providing evidence for a document is not a problem, > > but for a signature there are some sequence issues. > > > > > > Preserving signatures is based on reference information and > > evidence record. > > > Let's start with T1, when a CRL has been issued and the > > next time the > > > CRL is issued is marked with T5. Now we need to collect > > some reference > > > information (certificates, CRLs, etc.), validate the signature and > > > pack everything together before creating the evidence record > > > (timestamp). At time T2 a timestamp is requested for collected data > > > following by timestamp issued at T3. Until T5 we have > > enough time to > > > revoke the certificate related to digital signature archived, which > > > happens at T4 and we can end up with archived invalid signature, > > > although it was submitted to the archive before revocation happened. > > > > > > The problem with CRLs is that they might not be synchronized with > > > revocation mechanisms and there is no real information whether a > > > signature is valid or not at specific point in time. In theory CRLs > > > should be issued immediately after a certificate is revoked, but in > > > practice things are not the same, since the procedure > > itself already > > > has some timeframe (the ideal solution is to stop the time > > during the validation process). > > > > > > Now, there are options to use more than one evidence record for a > > > single data (signature) but I am afraid such procedures might get > > > overall concept very complicated and bulky, especially when > > performing > > > procedures over groups of data. I think we should pay some more > > > attention to archival data structures and mechanisms supporting TAS > > > operation. I would appreciate if some feedback would reach my inbox > > > concerning the mentioned problem and I also hope such discussion(s) > > > would unveil the black box internal mechanisms, which we > > named TAS or > > > whatever and after all, solve the main problem of LTANS > > requirements on data export. > > > > > > Regards > > > > > > aleksej > > > > > > > -----Original Message----- > > > > From: owner-ietf-ltans@mail.imc.org > > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > > Paul-André PAYS > > > > Sent: Thursday, October 28, 2004 4:18 PM > > > > To: ietf-ltans@imc.org > > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > > > > Paul-André, > > > > > > > > (text deleted) > > > > > > > > > > > > > > > > This is another proof of the sound approach of > > LTANS which links > > > > "data certs" and "secure archived". Any "data cert" must > > not only be > > > > signed, but a detailed log entry must be archived in a secure way > > > > (non rewritable medium, hash linking). This mandatory combination > > > > was a major rationale of the openevidence project (the technical > > > > solution by then was a a combination of TSP RFC3061, DVCS RFC3029 > > > > and hash-linking) > > > > > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > > needs to be > > > > signed (and time-stamped) by the archive service, but the > > log is not > > > > intended to be used as an evidence. > > > > > > > > > > > > I am exactly suggesting that it be. > > > > > > > > We are preparing a requirements document and not some "a > > posteriori" > > > > rationale for a given protocol or service. My strong suggestion, > > > > based on several years activities for several customers, > > is indeed > > > > that the "certified archival" of "detailed and signed" > > log is a "must" > > > > for a large majority of actual applications and uses cases. > > > > > > > > What the most "educated" or aware customers do require is > > a complete > > > > set of "evidence management" services. (What they call in France > > > > "Gestion de la Preuve" or "Administration de la Preuve"; > > what they > > > > will be able to exhibit in order to dissuade "others" to > > initiate a > > > > litigation, or whenever unsuccessfull, what they will be able to > > > > exhibit as evidence elements in a court). > > > > > > > > My personal view of the whole justification of LTANS > > context is, as > > > > I am convinced that this type of requirements will be > > generalized, > > > > that the IETF succeeds in proposing and establishing > > standards that > > > > wil enable : > > > > > > > > > > > > 1. technical interop between business partners > > > > 2. technical interop between solution providers > > > > > > > > 3. the judges and their expert to master the e-material > > > > (because it conforms to standard and because there exist tools > > > > enbling to manipulate them) > > > > 4. the possibility of mutual recognition within a business > > > > community > > > > > > > > And I have no longer any doubt that "certified archived > > logs" (more > > > > or less equivalent of the certified archival of requests and > > > > receipts) will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Edelweb > > > > Groupe ON-X Pôle Sécurité > > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DUg9R038900; Wed, 3 Nov 2004 05:30:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DUg8O038899; Wed, 3 Nov 2004 05:30:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DUgYS038892 for ; Wed, 3 Nov 2004 05:30:42 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3DUfn3022363; Wed, 3 Nov 2004 08:30:42 -0500 Message-Id: <200411031330.iA3DUfn3022363@host13.websitesource.com> From: "Carl Wallace" To: , Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 08:30:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099487404.4188d8ac64d37@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBqBvmS56mK/nlT0aRI7UUcobEegAAG4Hw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Well that is the general problem. Legislation states that > post-festum revocation is not allowed, meaning the time of > revocation can not be defined before the time when revocation > was requested. It may take some time before next CRL is > published, so when this information is published is the main > issue. If we consider that time stops at the time of > processing, some attestation could be produced. The practice? > I am not sure.... CRLs do not provide a means of determining "when revocation was requested" vs. the revocation time included in the CRL. That must be enforced by the CRL issuer. > Also, TAS performs its own validation at time T1 and by that > states that signature existed at T1. Post-festum validation > should only provide information that nothing really happened > before T1.... OK, but a TAS may archive an invalid signature (or evidence of invalidity). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DCxmM030820; Wed, 3 Nov 2004 05:12:59 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DCx2T030819; Wed, 3 Nov 2004 05:12:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DCwsO030813 for ; Wed, 3 Nov 2004 05:12:59 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (104.sub-70-212-175.myvzw.com [70.212.175.104]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA3Cjcn3014772; Wed, 3 Nov 2004 07:45:40 -0500 Message-Id: <200411031245.iA3Cjcn3014772@host13.websitesource.com> From: "Carl Wallace" To: , Subject: RE: Discussion of notareqs document Date: Wed, 3 Nov 2004 07:45:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1099479150.4188b86e846b6@kekec.e5.ijs.si> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTBlbL2qLxODQzyQH+DnphOUo1cmgAChFFw Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA3DCxsO030814 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Why would a CRL be issued so infrequently for someone signing documents? Usually that is the case for offline roots and such. In any case, if when the evidence record is validated the signer's certificate is not expired, the relying party (or data validation service) should retrieve the current CRL and see if the certificate has been revoked and if so whether or not there is a revocation date indication. The revocation date can be compared to the T1 in the record. The TAS could be configured to retrieve the CRLs shortly before and immediately after the expiration of each signer's certificate (to capture revocation events during the entire life of the certificate). Alternatively, if CRL publication weren't an unpredictable affair (and in most cases it isn't), the TAS could simply be configured to retrieve a CRL after a grace period to support retroactive revocation. The lta requirements document currently mentions retroactive revocation in the security considerations section. Support for retroactive revocation should be added as a requirement in the body of the document. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of aljosa@e5.ijs.si > Sent: Wednesday, November 03, 2004 5:53 AM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > Santosh, > > I am afraid it is not that simple. Let's say I want a Premium > service for some very important document which is also time > critical. There are no rules when CRLs are refreshed and in > some scenarios CRLs are not issued for another month or so. > Waiting your document to be formally processed after a > month... well that is just not the evolving scenario. The > basic concept of solving this problem should use two time > evidences at least. First one to attest that a signature > existed at the time of arrival and the later attestation that > proves the validity of a signature based on some reference > information (CRL more precisely). The things get a bit more > complicated when a document carries several signatures based > on certificates issued by (unsynchronized) CAs. > > However, there are also some conceptual approaches to this > problem. One is to assure that CRLs carry some time evidences > (when they were actually issued – the same used as for TAS) > and that policies clearly declare that CRLs are issued after > some action and that post action publishing is strictly > forbidden (e.g. a certificate can't be revoked back in time > and the revocation is valid only after a CRL is issued). This > way we could at least shorten the time frame left for > manipulation (I am not counting the processing time here, > which is unavoidable). > > I think we should agree at least on some basic concepts here > and define some TAS framework understanding. Also, > conclusions should be propagated to other areas and WGs to > achieve some consensus on how to properly manage signed > documents in time. > > aleksej > > Quoting Santosh Chokhani : > > > > > Aleksej, > > > > The archive package should contain the CRL used to verify > the transaction. > > That coupled with other times will show when the transaction was > > received and processed. > > > > When speed is of not essence, the relying party can always > wait for a > > CRL issued after the transaction was received to verify. This will > > ensure that the certificate was not revoked in the interim. > Relying > > party can use the later CRL for archiving the transaction. > > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] > > On Behalf Of A. Jerman Blazic > > Sent: Monday, November 01, 2004 1:52 PM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > > > Dear all, > > > > Following the "e-notary" discussion in the last month I see that > > requirements have been rapidly shifted and are now reflecting the > > certification and validation services. Coming to this point I would > > like to draw your attention to the fundamental problem that > at least I > > have when playing around with the scenario of digitally signed > > documents, which is however the crucial focus of TAS > services at this > > point. I also think that real scenarios would help us > understand the > > problems more clearly and find appropriate solution(s). > > > > Now let's assume that a signed document enters an archive. What > > happens in the first place is signature validation (since we assume > > that there is no point to archive a non-valid document, > although such > > scenarios are also possible). We also assume that TAS protocols and > > ERS are in place. So, what we need is some fixation in time that > > signature (and document) existed at some point in time (archiving > > time!). Providing evidence for a document is not a problem, > but for a signature there are some sequence issues. > > > > Preserving signatures is based on reference information and > evidence record. > > Let's start with T1, when a CRL has been issued and the > next time the > > CRL is issued is marked with T5. Now we need to collect > some reference > > information (certificates, CRLs, etc.), validate the signature and > > pack everything together before creating the evidence record > > (timestamp). At time T2 a timestamp is requested for collected data > > following by timestamp issued at T3. Until T5 we have > enough time to > > revoke the certificate related to digital signature archived, which > > happens at T4 and we can end up with archived invalid signature, > > although it was submitted to the archive before revocation happened. > > > > The problem with CRLs is that they might not be synchronized with > > revocation mechanisms and there is no real information whether a > > signature is valid or not at specific point in time. In theory CRLs > > should be issued immediately after a certificate is revoked, but in > > practice things are not the same, since the procedure > itself already > > has some timeframe (the ideal solution is to stop the time > during the validation process). > > > > Now, there are options to use more than one evidence record for a > > single data (signature) but I am afraid such procedures might get > > overall concept very complicated and bulky, especially when > performing > > procedures over groups of data. I think we should pay some more > > attention to archival data structures and mechanisms supporting TAS > > operation. I would appreciate if some feedback would reach my inbox > > concerning the mentioned problem and I also hope such discussion(s) > > would unveil the black box internal mechanisms, which we > named TAS or > > whatever and after all, solve the main problem of LTANS > requirements on data export. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of > Paul-André PAYS > > > Sent: Thursday, October 28, 2004 4:18 PM > > > To: ietf-ltans@imc.org > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > Paul-André, > > > > > > (text deleted) > > > > > > > > > > > > This is another proof of the sound approach of > LTANS which links > > > "data certs" and "secure archived". Any "data cert" must > not only be > > > signed, but a detailed log entry must be archived in a secure way > > > (non rewritable medium, hash linking). This mandatory combination > > > was a major rationale of the openevidence project (the technical > > > solution by then was a a combination of TSP RFC3061, DVCS RFC3029 > > > and hash-linking) > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > needs to be > > > signed (and time-stamped) by the archive service, but the > log is not > > > intended to be used as an evidence. > > > > > > > > > I am exactly suggesting that it be. > > > > > > We are preparing a requirements document and not some "a > posteriori" > > > rationale for a given protocol or service. My strong suggestion, > > > based on several years activities for several customers, > is indeed > > > that the "certified archival" of "detailed and signed" > log is a "must" > > > for a large majority of actual applications and uses cases. > > > > > > What the most "educated" or aware customers do require is > a complete > > > set of "evidence management" services. (What they call in France > > > "Gestion de la Preuve" or "Administration de la Preuve"; > what they > > > will be able to exhibit in order to dissuade "others" to > initiate a > > > litigation, or whenever unsuccessfull, what they will be able to > > > exhibit as evidence elements in a court). > > > > > > My personal view of the whole justification of LTANS > context is, as > > > I am convinced that this type of requirements will be > generalized, > > > that the IETF succeeds in proposing and establishing > standards that > > > wil enable : > > > > > > > > > 1. technical interop between business partners > > > 2. technical interop between solution providers > > > > > > 3. the judges and their expert to master the e-material > > > (because it conforms to standard and because there exist tools > > > enbling to manipulate them) > > > 4. the possibility of mutual recognition within a business > > > community > > > > > > And I have no longer any doubt that "certified archived > logs" (more > > > or less equivalent of the certified archival of requests and > > > receipts) will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Edelweb > > > Groupe ON-X Pôle Sécurité > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3DADwU029636; Wed, 3 Nov 2004 05:10:13 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3DADwc029635; Wed, 3 Nov 2004 05:10:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3DABtt029559 for ; Wed, 3 Nov 2004 05:10:12 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 29430 invoked by uid 48); 3 Nov 2004 13:10:04 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 14:10:04 +0100 Message-ID: <1099487404.4188d8ac64d37@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 14:10:04 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <200411021338.iA2DcTAU027628@host13.websitesource.com> In-Reply-To: <200411021338.iA2DcTAU027628@host13.websitesource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Carl, > Regarding WG focus, the recent shift in requirements focus has been w.r.t. > to the "notary" requirements. The long-term archive requirements focus on > the types of concerns you mention. That focus has been relatively stable > for some time, though the requirements document itself is still evolving. II know that, but correct me if I am wrong: e-notaries were shifted to certification services (and this is not the real point), which should provide among other things some attestation on validity of digital signatures. How this validity is delivered is a crucial question. There might be a DVCS-like service but the service itself should provide enough information by itself to prove that a signature was valid at T1 and not wait until T4. DVCS does provide some attestation, but it is not clear (at least to me), how the attestation is actually generated. Can we take DVCS response as "enough information" to enclose it to a signature and pack everything? Peter? > Regarding signature preservation, as discussed so far, an evidence record is > relative to a single time T1, e.g. the time of submission to the archive. > Retroactive revocation would need to be considered before committing the > data to an archive and initiating an evidence record (using the mechanisms > that have been discussed so far). Even if a CRL were issued immediately > when a cert was revoked, it's revocation time might be before T1. Well that is the general problem. Legislation states that post-festum revocation is not allowed, meaning the time of revocation can not be defined before the time when revocation was requested. It may take some time before next CRL is published, so when this information is published is the main issue. If we consider that time stops at the time of processing, some attestation could be produced. The practice? I am not sure.... Also, TAS performs its own validation at time T1 and by that states that signature existed at T1. Post-festum validation should only provide information that nothing really happened before T1.... I don't > believe I heard anyone discuss using an evidence record to verify a > signature relative to multiple points in time (that could get ugly). It > seems unlikely that retroactive revocation applied after several periodic > refresh operations (which should be relatively infrequent) at time T4 should > invalidate a signature generated at, or before, time T1. Well, I am afraid exactly of that. See my answer to Santosh - I am not stating that this is the way to go, I just would like to clear up this issue before some concrete steps forward are made. We have been playing with implementation of second generation of TAS but this problems causes headaches, not to mention the fulfillment of LTANS data grouping requirement... The main outcome I would like to see is at least a common understanding of the problem and some conclusions on how to manage such data. > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > > Sent: Monday, November 01, 2004 1:52 PM > > To: ietf-ltans@imc.org > > Subject: RE: Discussion of notareqs document > > > > > > Dear all, > > > > Following the "e-notary" discussion in the last month I see > > that requirements have been rapidly shifted and are now > > reflecting the certification and validation services. Coming > > to this point I would like to draw your attention to the > > fundamental problem that at least I have when playing around > > with the scenario of digitally signed documents, which is > > however the crucial focus of TAS services at this point. I > > also think that real scenarios would help us understand the > > problems more clearly and find appropriate solution(s). > > > > Now let's assume that a signed document enters an archive. > > What happens in the first place is signature validation > > (since we assume that there is no point to archive a > > non-valid document, although such scenarios are also > > possible). We also assume that TAS protocols and ERS are in > > place. So, what we need is some fixation in time that > > signature (and document) existed at some point in time > > (archiving time!). Providing evidence for a document is not a > > problem, but for a signature there are some sequence issues. > > > > Preserving signatures is based on reference information and > > evidence record. > > Let's start with T1, when a CRL has been issued and the next > > time the CRL is issued is marked with T5. Now we need to > > collect some reference information (certificates, CRLs, > > etc.), validate the signature and pack everything together > > before creating the evidence record (timestamp). At time T2 a > > timestamp is requested for collected data following by > > timestamp issued at T3. Until T5 we have enough time to > > revoke the certificate related to digital signature archived, > > which happens at T4 and we can end up with archived invalid > > signature, although it was submitted to the archive before > > revocation happened. > > > > The problem with CRLs is that they might not be synchronized > > with revocation mechanisms and there is no real information > > whether a signature is valid or not at specific point in > > time. In theory CRLs should be issued immediately after a > > certificate is revoked, but in practice things are not the > > same, since the procedure itself already has some timeframe > > (the ideal solution is to stop the time during the validation > > process). > > > > Now, there are options to use more than one evidence record > > for a single data (signature) but I am afraid such procedures > > might get overall concept very complicated and bulky, > > especially when performing procedures over groups of data. I > > think we should pay some more attention to archival data > > structures and mechanisms supporting TAS operation. I would > > appreciate if some feedback would reach my inbox concerning > > the mentioned problem and I also hope such discussion(s) > > would unveil the black box internal mechanisms, which we > > named TAS or whatever and after all, solve the main problem > > of LTANS requirements on data export. > > > > Regards > > > > aleksej > > > > > -----Original Message----- > > > From: owner-ietf-ltans@mail.imc.org > > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > > Sent: Thursday, October 28, 2004 4:18 PM > > > To: ietf-ltans@imc.org > > > Subject: Re: Discussion of notareqs document > > > > > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > > > > Paul-André, > > > > > > (text deleted) > > > > > > > > > > > > This is another proof of the sound approach of > > LTANS which links > > > "data certs" and "secure archived". Any "data cert" must > > not only be > > > signed, but a detailed log entry must be archived in a > > secure way (non > > > rewritable medium, hash linking). This mandatory combination was a > > > major rationale of the openevidence project (the technical > > solution by > > > then was a a combination of TSP RFC3061, DVCS RFC3029 and > > > hash-linking) > > > > > > > > > > > > There is no such mandatory comnbination for LTANS: data > > needs to be > > > signed (and time-stamped) by the archive service, but the > > log is not > > > intended to be used as an evidence. > > > > > > > > > I am exactly suggesting that it be. > > > > > > We are preparing a requirements document and not some "a > > posteriori" > > > rationale for a given protocol or service. My strong suggestion, > > > based on several years activities for several customers, is indeed > > > that the "certified archival" of "detailed and signed" log > > is a "must" > > > for a large majority of actual applications and uses cases. > > > > > > What the most "educated" or aware customers do require is a > > complete > > > set of "evidence management" services. (What they call in France > > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > > will be able to exhibit in order to dissuade "others" to initiate a > > > litigation, or whenever unsuccessfull, what they will be able to > > > exhibit as evidence elements in a court). > > > > > > My personal view of the whole justification of LTANS > > context is, as I > > > am convinced that this type of requirements will be > > generalized, that > > > the IETF succeeds in proposing and establishing standards that wil > > > enable : > > > > > > > > > 1. technical interop between business partners > > > 2. technical interop between solution providers > > > > > > 3. the judges and their expert to master the e-material > > > (because it conforms to standard and because there exist > > tools enbling > > > to manipulate them) > > > 4. the possibility of mutual recognition within a business > > > community > > > > > > And I have no longer any doubt that "certified archived > > logs" (more > > > or less equivalent of the certified archival of requests > > and receipts) > > > will be one of, if not, the most usefull component. > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Edelweb > > > Groupe ON-X Pôle Sécurité > > > paul-andre.pays@edelweb.fr papays@on-x.com > > > http://www.edelweb.fr/ http://www.on-x.com/ > > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3AqgKO036586; Wed, 3 Nov 2004 02:52:42 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA3Aqgo4036585; Wed, 3 Nov 2004 02:52:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA3AqeS4036436 for ; Wed, 3 Nov 2004 02:52:41 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Received: (qmail 24432 invoked by uid 48); 3 Nov 2004 10:52:30 -0000 Received: from pc082.wireless.ntua.gr (pc082.wireless.ntua.gr [147.102.232.82]) by kekec.e5.ijs.si (IMP) with HTTP for ; Wed, 3 Nov 2004 11:52:30 +0100 Message-ID: <1099479150.4188b86e846b6@kekec.e5.ijs.si> Date: Wed, 3 Nov 2004 11:52:30 +0100 From: aljosa@e5.ijs.si To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document References: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> In-Reply-To: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 147.102.232.82 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Santosh, I am afraid it is not that simple. Let's say I want a Premium service for some very important document which is also time critical. There are no rules when CRLs are refreshed and in some scenarios CRLs are not issued for another month or so. Waiting your document to be formally processed after a month... well that is just not the evolving scenario. The basic concept of solving this problem should use two time evidences at least. First one to attest that a signature existed at the time of arrival and the later attestation that proves the validity of a signature based on some reference information (CRL more precisely). The things get a bit more complicated when a document carries several signatures based on certificates issued by (unsynchronized) CAs. However, there are also some conceptual approaches to this problem. One is to assure that CRLs carry some time evidences (when they were actually issued – the same used as for TAS) and that policies clearly declare that CRLs are issued after some action and that post action publishing is strictly forbidden (e.g. a certificate can't be revoked back in time and the revocation is valid only after a CRL is issued). This way we could at least shorten the time frame left for manipulation (I am not counting the processing time here, which is unavoidable). I think we should agree at least on some basic concepts here and define some TAS framework understanding. Also, conclusions should be propagated to other areas and WGs to achieve some consensus on how to properly manage signed documents in time. aleksej Quoting Santosh Chokhani : > > Aleksej, > > The archive package should contain the CRL used to verify the transaction. > That coupled with other times will show when the transaction was received > and processed. > > When speed is of not essence, the relying party can always wait for a CRL > issued after the transaction was received to verify. This will ensure that > the certificate was not revoked in the interim. Relying party can use the > later CRL for archiving the transaction. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of A. Jerman Blazic > Sent: Monday, November 01, 2004 1:52 PM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > > Dear all, > > Following the "e-notary" discussion in the last month I see that > requirements have been rapidly shifted and are now reflecting the > certification and validation services. Coming to this point I would like to > draw your attention to the fundamental problem that at least I have when > playing around with the scenario of digitally signed documents, which is > however the crucial focus of TAS services at this point. I also think that > real scenarios would help us understand the problems more clearly and find > appropriate solution(s). > > Now let's assume that a signed document enters an archive. What happens in > the first place is signature validation (since we assume that there is no > point to archive a non-valid document, although such scenarios are also > possible). We also assume that TAS protocols and ERS are in place. So, what > we need is some fixation in time that signature (and document) existed at > some point in time (archiving time!). Providing evidence for a document is > not a problem, but for a signature there are some sequence issues. > > Preserving signatures is based on reference information and evidence record. > Let's start with T1, when a CRL has been issued and the next time the CRL is > issued is marked with T5. Now we need to collect some reference information > (certificates, CRLs, etc.), validate the signature and pack everything > together before creating the evidence record (timestamp). At time T2 a > timestamp is requested for collected data following by timestamp issued at > T3. Until T5 we have enough time to revoke the certificate related to > digital signature archived, which happens at T4 and we can end up with > archived invalid signature, although it was submitted to the archive before > revocation happened. > > The problem with CRLs is that they might not be synchronized with revocation > mechanisms and there is no real information whether a signature is valid or > not at specific point in time. In theory CRLs should be issued immediately > after a certificate is revoked, but in practice things are not the same, > since the procedure itself already has some timeframe (the ideal solution is > to stop the time during the validation process). > > Now, there are options to use more than one evidence record for a single > data (signature) but I am afraid such procedures might get overall concept > very complicated and bulky, especially when performing procedures over > groups of data. I think we should pay some more attention to archival data > structures and mechanisms supporting TAS operation. I would appreciate if > some feedback would reach my inbox concerning the mentioned problem and I > also hope such discussion(s) would unveil the black box internal mechanisms, > which we named TAS or whatever and after all, solve the main problem of > LTANS requirements on data export. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > Sent: Thursday, October 28, 2004 4:18 PM > > To: ietf-ltans@imc.org > > Subject: Re: Discussion of notareqs document > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > Paul-André, > > > > (text deleted) > > > > > > > > This is another proof of the sound approach of > > LTANS which links "data certs" and "secure archived". Any > > "data cert" must not only be signed, but a detailed log entry > > must be archived in a secure way (non rewritable medium, hash > > linking). This mandatory combination was a major rationale of > > the openevidence project (the technical solution by then was > > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > > > > > There is no such mandatory comnbination for LTANS: data needs to be > > signed (and time-stamped) by the archive service, but the log is not > > intended to be used as an evidence. > > > > > > I am exactly suggesting that it be. > > > > We are preparing a requirements document and not some "a posteriori" > > rationale for a given protocol or service. My strong suggestion, > > based on several years activities for several customers, is indeed > > that the "certified archival" of "detailed and signed" log is a "must" > > for a large majority of actual applications and uses cases. > > > > What the most "educated" or aware customers do require is a complete > > set of "evidence management" services. (What they call in France > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > will be able to exhibit in order to dissuade "others" to initiate a > > litigation, or whenever unsuccessfull, what they will be able to > > exhibit as evidence elements in a court). > > > > My personal view of the whole justification of LTANS context is, as I > > am convinced that this type of requirements will be generalized, that > > the IETF succeeds in proposing and establishing standards that wil > > enable : > > > > > > 1. technical interop between business partners > > 2. technical interop between solution providers > > > > 3. the judges and their expert to master the e-material > > (because it conforms to standard and because there exist tools enbling > > to manipulate them) > > 4. the possibility of mutual recognition within a business > > community > > > > And I have no longer any doubt that "certified archived logs" (more > > or less equivalent of the certified archival of requests and receipts) > > will be one of, if not, the most usefull component. > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > -- > > > > Edelweb > > Groupe ON-X Pôle Sécurité > > paul-andre.pays@edelweb.fr papays@on-x.com > > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > > la signature électronique, http://edelpki.edelweb.fr/ vous > > permet d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DcWN9030474; Tue, 2 Nov 2004 05:38:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA2DcW6T030473; Tue, 2 Nov 2004 05:38:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2DcVda030467 for ; Tue, 2 Nov 2004 05:38:31 -0800 (PST) (envelope-from cwallace@orionsec.com) Received: from wcwallace (48.sub-166-180-48.myvzw.com [166.180.48.48]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA2DcTAU027628; Tue, 2 Nov 2004 08:38:29 -0500 Message-Id: <200411021338.iA2DcTAU027628@host13.websitesource.com> From: "Carl Wallace" To: "'A. Jerman Blazic'" , Subject: RE: Discussion of notareqs document Date: Tue, 2 Nov 2004 08:38:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200411011751.iA1HphKV015014@above.proper.com> Thread-Index: AcTAQ+Q013UmD6euRw29pdJ8sbk9CAAmNbSA Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA2DcVda030468 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Regarding WG focus, the recent shift in requirements focus has been w.r.t. to the "notary" requirements. The long-term archive requirements focus on the types of concerns you mention. That focus has been relatively stable for some time, though the requirements document itself is still evolving. Regarding signature preservation, as discussed so far, an evidence record is relative to a single time T1, e.g. the time of submission to the archive. Retroactive revocation would need to be considered before committing the data to an archive and initiating an evidence record (using the mechanisms that have been discussed so far). Even if a CRL were issued immediately when a cert was revoked, it's revocation time might be before T1. I don't believe I heard anyone discuss using an evidence record to verify a signature relative to multiple points in time (that could get ugly). It seems unlikely that retroactive revocation applied after several periodic refresh operations (which should be relatively infrequent) at time T4 should invalidate a signature generated at, or before, time T1. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic > Sent: Monday, November 01, 2004 1:52 PM > To: ietf-ltans@imc.org > Subject: RE: Discussion of notareqs document > > > Dear all, > > Following the "e-notary" discussion in the last month I see > that requirements have been rapidly shifted and are now > reflecting the certification and validation services. Coming > to this point I would like to draw your attention to the > fundamental problem that at least I have when playing around > with the scenario of digitally signed documents, which is > however the crucial focus of TAS services at this point. I > also think that real scenarios would help us understand the > problems more clearly and find appropriate solution(s). > > Now let's assume that a signed document enters an archive. > What happens in the first place is signature validation > (since we assume that there is no point to archive a > non-valid document, although such scenarios are also > possible). We also assume that TAS protocols and ERS are in > place. So, what we need is some fixation in time that > signature (and document) existed at some point in time > (archiving time!). Providing evidence for a document is not a > problem, but for a signature there are some sequence issues. > > Preserving signatures is based on reference information and > evidence record. > Let's start with T1, when a CRL has been issued and the next > time the CRL is issued is marked with T5. Now we need to > collect some reference information (certificates, CRLs, > etc.), validate the signature and pack everything together > before creating the evidence record (timestamp). At time T2 a > timestamp is requested for collected data following by > timestamp issued at T3. Until T5 we have enough time to > revoke the certificate related to digital signature archived, > which happens at T4 and we can end up with archived invalid > signature, although it was submitted to the archive before > revocation happened. > > The problem with CRLs is that they might not be synchronized > with revocation mechanisms and there is no real information > whether a signature is valid or not at specific point in > time. In theory CRLs should be issued immediately after a > certificate is revoked, but in practice things are not the > same, since the procedure itself already has some timeframe > (the ideal solution is to stop the time during the validation > process). > > Now, there are options to use more than one evidence record > for a single data (signature) but I am afraid such procedures > might get overall concept very complicated and bulky, > especially when performing procedures over groups of data. I > think we should pay some more attention to archival data > structures and mechanisms supporting TAS operation. I would > appreciate if some feedback would reach my inbox concerning > the mentioned problem and I also hope such discussion(s) > would unveil the black box internal mechanisms, which we > named TAS or whatever and after all, solve the main problem > of LTANS requirements on data export. > > Regards > > aleksej > > > -----Original Message----- > > From: owner-ietf-ltans@mail.imc.org > > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > > Sent: Thursday, October 28, 2004 4:18 PM > > To: ietf-ltans@imc.org > > Subject: Re: Discussion of notareqs document > > > > > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > > > > Paul-André, > > > > (text deleted) > > > > > > > > This is another proof of the sound approach of > LTANS which links > > "data certs" and "secure archived". Any "data cert" must > not only be > > signed, but a detailed log entry must be archived in a > secure way (non > > rewritable medium, hash linking). This mandatory combination was a > > major rationale of the openevidence project (the technical > solution by > > then was a a combination of TSP RFC3061, DVCS RFC3029 and > > hash-linking) > > > > > > > > There is no such mandatory comnbination for LTANS: data > needs to be > > signed (and time-stamped) by the archive service, but the > log is not > > intended to be used as an evidence. > > > > > > I am exactly suggesting that it be. > > > > We are preparing a requirements document and not some "a > posteriori" > > rationale for a given protocol or service. My strong suggestion, > > based on several years activities for several customers, is indeed > > that the "certified archival" of "detailed and signed" log > is a "must" > > for a large majority of actual applications and uses cases. > > > > What the most "educated" or aware customers do require is a > complete > > set of "evidence management" services. (What they call in France > > "Gestion de la Preuve" or "Administration de la Preuve"; what they > > will be able to exhibit in order to dissuade "others" to initiate a > > litigation, or whenever unsuccessfull, what they will be able to > > exhibit as evidence elements in a court). > > > > My personal view of the whole justification of LTANS > context is, as I > > am convinced that this type of requirements will be > generalized, that > > the IETF succeeds in proposing and establishing standards that wil > > enable : > > > > > > 1. technical interop between business partners > > 2. technical interop between solution providers > > > > 3. the judges and their expert to master the e-material > > (because it conforms to standard and because there exist > tools enbling > > to manipulate them) > > 4. the possibility of mutual recognition within a business > > community > > > > And I have no longer any doubt that "certified archived > logs" (more > > or less equivalent of the certified archival of requests > and receipts) > > will be one of, if not, the most usefull component. > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > -- > > > > Edelweb > > Groupe ON-X Pôle Sécurité > > paul-andre.pays@edelweb.fr papays@on-x.com > > http://www.edelweb.fr/ http://www.on-x.com/ > > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier la > > signature électronique, http://edelpki.edelweb.fr/ vous permet > > d'obtenir le certificat de l'autorité et la LCR. > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1JCZDx057490; Mon, 1 Nov 2004 11:12:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1JCZcl057484; Mon, 1 Nov 2004 11:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1JCYQG057473 for ; Mon, 1 Nov 2004 11:12:34 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id iA1JCbph012024 for ; Mon, 1 Nov 2004 14:12:37 -0500 From: "Santosh Chokhani" To: Subject: RE: Discussion of notareqs document Date: Mon, 1 Nov 2004 14:12:37 -0500 Message-ID: <003601c4c046$c06191c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <200411011751.iA1HphKV015014@above.proper.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1JCZQG057479 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Aleksej, The archive package should contain the CRL used to verify the transaction. That coupled with other times will show when the transaction was received and processed. When speed is of not essence, the relying party can always wait for a CRL issued after the transaction was received to verify. This will ensure that the certificate was not revoked in the interim. Relying party can use the later CRL for archiving the transaction. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of A. Jerman Blazic Sent: Monday, November 01, 2004 1:52 PM To: ietf-ltans@imc.org Subject: RE: Discussion of notareqs document Dear all, Following the "e-notary" discussion in the last month I see that requirements have been rapidly shifted and are now reflecting the certification and validation services. Coming to this point I would like to draw your attention to the fundamental problem that at least I have when playing around with the scenario of digitally signed documents, which is however the crucial focus of TAS services at this point. I also think that real scenarios would help us understand the problems more clearly and find appropriate solution(s). Now let's assume that a signed document enters an archive. What happens in the first place is signature validation (since we assume that there is no point to archive a non-valid document, although such scenarios are also possible). We also assume that TAS protocols and ERS are in place. So, what we need is some fixation in time that signature (and document) existed at some point in time (archiving time!). Providing evidence for a document is not a problem, but for a signature there are some sequence issues. Preserving signatures is based on reference information and evidence record. Let's start with T1, when a CRL has been issued and the next time the CRL is issued is marked with T5. Now we need to collect some reference information (certificates, CRLs, etc.), validate the signature and pack everything together before creating the evidence record (timestamp). At time T2 a timestamp is requested for collected data following by timestamp issued at T3. Until T5 we have enough time to revoke the certificate related to digital signature archived, which happens at T4 and we can end up with archived invalid signature, although it was submitted to the archive before revocation happened. The problem with CRLs is that they might not be synchronized with revocation mechanisms and there is no real information whether a signature is valid or not at specific point in time. In theory CRLs should be issued immediately after a certificate is revoked, but in practice things are not the same, since the procedure itself already has some timeframe (the ideal solution is to stop the time during the validation process). Now, there are options to use more than one evidence record for a single data (signature) but I am afraid such procedures might get overall concept very complicated and bulky, especially when performing procedures over groups of data. I think we should pay some more attention to archival data structures and mechanisms supporting TAS operation. I would appreciate if some feedback would reach my inbox concerning the mentioned problem and I also hope such discussion(s) would unveil the black box internal mechanisms, which we named TAS or whatever and after all, solve the main problem of LTANS requirements on data export. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > Sent: Thursday, October 28, 2004 4:18 PM > To: ietf-ltans@imc.org > Subject: Re: Discussion of notareqs document > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > Paul-André, > > (text deleted) > > > > This is another proof of the sound approach of > LTANS which links "data certs" and "secure archived". Any > "data cert" must not only be signed, but a detailed log entry > must be archived in a secure way (non rewritable medium, hash > linking). This mandatory combination was a major rationale of > the openevidence project (the technical solution by then was > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > There is no such mandatory comnbination for LTANS: data needs to be > signed (and time-stamped) by the archive service, but the log is not > intended to be used as an evidence. > > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a posteriori" > rationale for a given protocol or service. My strong suggestion, > based on several years activities for several customers, is indeed > that the "certified archival" of "detailed and signed" log is a "must" > for a large majority of actual applications and uses cases. > > What the most "educated" or aware customers do require is a complete > set of "evidence management" services. (What they call in France > "Gestion de la Preuve" or "Administration de la Preuve"; what they > will be able to exhibit in order to dissuade "others" to initiate a > litigation, or whenever unsuccessfull, what they will be able to > exhibit as evidence elements in a court). > > My personal view of the whole justification of LTANS context is, as I > am convinced that this type of requirements will be generalized, that > the IETF succeeds in proposing and establishing standards that wil > enable : > > > 1. technical interop between business partners > 2. technical interop between solution providers > > 3. the judges and their expert to master the e-material > (because it conforms to standard and because there exist tools enbling > to manipulate them) > 4. the possibility of mutual recognition within a business > community > > And I have no longer any doubt that "certified archived logs" (more > or less equivalent of the certified archival of requests and receipts) > will be one of, if not, the most usefull component. > > > > > Denis > > > > > > > > > -- > > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id iA1HpnQl015115; Mon, 1 Nov 2004 09:51:49 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id iA1HpnEW015114; Mon, 1 Nov 2004 09:51:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by above.proper.com (8.12.11/8.12.9) with SMTP id iA1HphKV015014 for ; Mon, 1 Nov 2004 09:51:48 -0800 (PST) (envelope-from aljosa@e5.ijs.si) Message-Id: <200411011751.iA1HphKV015014@above.proper.com> Received: (qmail 7195 invoked from network); 1 Nov 2004 17:51:39 -0000 Received: from localhost (127.0.0.1) by e5.ijs.si with SMTP; 1 Nov 2004 17:51:39 -0000 Received: from e5.ijs.si ([127.0.0.1]) by localhost (kekec.e5.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07077-03 for ; Mon, 1 Nov 2004 18:51:39 +0100 (CET) Received: (qmail 7190 invoked from network); 1 Nov 2004 17:51:39 -0000 Received: from arthur.e5.ijs.si (HELO Arthur) (193.138.1.27) by e5.ijs.si with SMTP; 1 Nov 2004 17:51:39 -0000 From: "A. Jerman Blazic" To: Subject: RE: Discussion of notareqs document Date: Mon, 1 Nov 2004 19:52:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTAQ+Q013UmD6euRw29pdJ8sbk9CA== In-Reply-To: <41810D94.60202@edelweb.fr> X-Virus-Scanned: by amavisd-new at e5.ijs.si Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA1HpnKV015108 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear all, Following the "e-notary" discussion in the last month I see that requirements have been rapidly shifted and are now reflecting the certification and validation services. Coming to this point I would like to draw your attention to the fundamental problem that at least I have when playing around with the scenario of digitally signed documents, which is however the crucial focus of TAS services at this point. I also think that real scenarios would help us understand the problems more clearly and find appropriate solution(s). Now let's assume that a signed document enters an archive. What happens in the first place is signature validation (since we assume that there is no point to archive a non-valid document, although such scenarios are also possible). We also assume that TAS protocols and ERS are in place. So, what we need is some fixation in time that signature (and document) existed at some point in time (archiving time!). Providing evidence for a document is not a problem, but for a signature there are some sequence issues. Preserving signatures is based on reference information and evidence record. Let's start with T1, when a CRL has been issued and the next time the CRL is issued is marked with T5. Now we need to collect some reference information (certificates, CRLs, etc.), validate the signature and pack everything together before creating the evidence record (timestamp). At time T2 a timestamp is requested for collected data following by timestamp issued at T3. Until T5 we have enough time to revoke the certificate related to digital signature archived, which happens at T4 and we can end up with archived invalid signature, although it was submitted to the archive before revocation happened. The problem with CRLs is that they might not be synchronized with revocation mechanisms and there is no real information whether a signature is valid or not at specific point in time. In theory CRLs should be issued immediately after a certificate is revoked, but in practice things are not the same, since the procedure itself already has some timeframe (the ideal solution is to stop the time during the validation process). Now, there are options to use more than one evidence record for a single data (signature) but I am afraid such procedures might get overall concept very complicated and bulky, especially when performing procedures over groups of data. I think we should pay some more attention to archival data structures and mechanisms supporting TAS operation. I would appreciate if some feedback would reach my inbox concerning the mentioned problem and I also hope such discussion(s) would unveil the black box internal mechanisms, which we named TAS or whatever and after all, solve the main problem of LTANS requirements on data export. Regards aleksej > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Paul-André PAYS > Sent: Thursday, October 28, 2004 4:18 PM > To: ietf-ltans@imc.org > Subject: Re: Discussion of notareqs document > > > > -- Denis Pinkas -- a dit, - le 28/10/2004 15:39: > > > Paul-André, > > (text deleted) > > > > This is another proof of the sound approach of > LTANS which links "data certs" and "secure archived". Any > "data cert" must not only be signed, but a detailed log entry > must be archived in a secure way (non rewritable medium, hash > linking). This mandatory combination was a major rationale of > the openevidence project (the technical solution by then was > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking) > > > > There is no such mandatory comnbination for LTANS: data > needs to be signed (and time-stamped) by the archive service, > but the log is not intended to be used as an evidence. > > > I am exactly suggesting that it be. > > We are preparing a requirements document and not some "a > posteriori" rationale for a given protocol or service. My > strong suggestion, based on several years activities for > several customers, is indeed that the "certified archival" of > "detailed and signed" log is a "must" for a large majority of > actual applications and uses cases. > > What the most "educated" or aware customers do require is a > complete set of "evidence management" services. (What they > call in France "Gestion de la Preuve" or "Administration de > la Preuve"; what they will be able to exhibit in order to > dissuade "others" to initiate a litigation, or whenever > unsuccessfull, what they will be able to exhibit as evidence > elements in a court). > > My personal view of the whole justification of LTANS context > is, as I am convinced that this type of requirements will be > generalized, that the IETF succeeds in proposing and > establishing standards that wil enable : > > > 1. technical interop between business partners > 2. technical interop between solution providers > > 3. the judges and their expert to master the e-material > (because it conforms to standard and because there exist > tools enbling to manipulate them) > 4. the possibility of mutual recognition within a business > community > > And I have no longer any doubt that "certified archived > logs" (more or less equivalent of the certified archival of > requests and receipts) will be one of, if not, the most > usefull component. > > > > > Denis > > > > > > > > > -- > > Edelweb > Groupe ON-X Pôle Sécurité > paul-andre.pays@edelweb.fr papays@on-x.com > http://www.edelweb.fr/ http://www.on-x.com/ > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : > 15, quai de Dion Bouton - 92816 Puteaux cedex Pour vérifier > la signature électronique, http://edelpki.edelweb.fr/ vous > permet d'obtenir le certificat de l'autorité et la LCR. > > >