From CWallace@cygnacom.com Fri Oct 8 08:52:11 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10C2D3A6887 for ; Fri, 8 Oct 2010 08:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDqyt2gX5HsF for ; Fri, 8 Oct 2010 08:52:08 -0700 (PDT) Received: from mail95.messagelabs.com (mail95.messagelabs.com [216.82.242.147]) by core3.amsl.com (Postfix) with SMTP id 653CD3A686B for ; Fri, 8 Oct 2010 08:52:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-14.tower-95.messagelabs.com!1286553187!97697846!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 10208 invoked from network); 8 Oct 2010 15:53:07 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-14.tower-95.messagelabs.com with SMTP; 8 Oct 2010 15:53:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Oct 2010 11:52:10 -0400 Message-ID: In-Reply-To: <4C9E3ECA.1000203@gondrom.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt Thread-Index: Actc302mgpfndv5aTQOY1ix2H/JzhwKIVwYQ References: <4C8E6186.10909@gondrom.org> <4C9E3ECA.1000203@gondrom.org> From: "Carl Wallace" To: "Tobias Gondrom" , Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 15:52:11 -0000 It appears that the issues have been satisfactorily addressed. We'll = proceed with sending this draft to the AD early next week.=20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of Tobias Gondrom > Sent: Saturday, September 25, 2010 2:26 PM > To: ltans@ietf.org > Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt >=20 > I basically agree with Aljosa. More detailed answers in line > - Tobias >=20 >=20 > On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote: > > Denis, Tobias > > > > It took me a while to get back to XMLERS and my answers are in line. > > > >> -----Original Message----- > >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On > Behalf > >> Of Denis Pinkas > >> Sent: September 14, 2010 12:34 > >> To: ltans > >> Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Tobias, > >> > >> See responses in line. > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-09-13, 19:38:14 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Hi Denis, > >> yes the response is a bit late, but as we still have IETF LC > >> ahead, not too late. > >> Based on Carl's decision we may discuss and resolve this here > >> while the draft proceeds to IESG and IETF LC. > >> Answers inline. > >> > >> Kind regards, Tobias > >> > >> > >> On 09/13/2010 04:48 PM, Denis Pinkas wrote: > >> > >> This is a late response. > >> > >> Comments on draft-ietf-ltans-xmlers-07 > >> > >> 1) The abstract from this draft states: > >> > >> In many scenarios, users must be able to demonstrate the > >> (time) > >> existence, integrity and validity of data including > >> signed data for > >> long or undetermined period of time. This document > >> specifies XML > >> syntax and processing rules for creating evidence for > >> long-term non- > >> repudiation of existence of data. > >> > >> The abstract from RFC 4998, which is very similar, states: > >> > >> In many scenarios, users must be able prove the > >> existence and > >> integrity of data, including digitally signed data, in a > >> common and > >> reproducible way over a long and possibly undetermined > >> period of > >> time. This document specifies the syntax and processing > >> of an > >> Evidence Record, a structure designed to support long- > >> term non- > >> repudiation of existence of data. > >> > >> Then an additional sentence in the draft states: > >> > >> ERS-XML incorporates alternative syntax and processing > >> rules to ASN.1 ERS syntax > >> by using XML language. > >> > >> The basic question is why an addendum has not been added to > >> RFC 4998 to include > >> an XML syntax, equivalent to the ASN.1. > >> > >> Some explanations are given on page 7 are not convincing: > >> > >> Due to the differences in XML processing rules and other > >> characteristics of XML language, XMLERS does not present > >> a direct > >> transformation of ERS in ASN.1 syntax. The XMLERS syntax > >> is based on > >> different processing rules as defined in [RFC4998] and > >> it does not > >> support for example import of ASN.1 values in XML tags. > >> Creating > >> Evidence Records in XML syntax must follow the steps as > >> defined in > >> this draft. XMLERS is a standalone draft and is based on > >> [RFC4998] > >> conceptually only. > >> > >> The text omits to highlight what the differences are. > >> > >> For example, ERS states: > >> > >> The data (e.g. certificates, Certificate Revocation > >> Lists (CRLs), or > >> Online Certificate Status Protocol (OCSP) responses) > >> needed to verify > >> the timestamp MUST be preserved, and SHOULD be stored in > >> the > >> timestamp itself unless this causes unnecessary > >> duplication. > >> > >> While the draft states: > >> > >> An ATS contains a Time-Stamp Token and optionally other > >> useful > >> data for Time-Stamp validation, e.g. certificates, CRLs > >> or OCSP > >> responses > >> > >> In one case CRLs should be part of the TST, while in the > >> other case it should be > >> external to the TST. > >> > >> Section 1.1 should be revised to mention the differences > >> with a rational about them. > >> > >> > >> > >> In theory we could have added XMLERS to ERS, but XML puts > >> different processing issues to the document, > >> for example the ordering problem of the XML elements (to always > >> produce identical hash values > >> for the same data structure). XMLERS required further explanation > >> regarding these processing rules and > >> a well-thought XML structure, plus identifiers to be assigned by > >> IANA for certain types. All these items are not > >> related to ERS or its ASN.1 structure and would have made the RFC > >> unnecessarily complex to read while > >> bringing not much benefit. > >> > >> So a lot of reasons to put this in a separate draft, and not much > >> harm from doing so. > > I support Tobias comments as the benefit of expanding ASN.1 > recommendation with additional XML based structure and processing = rules > would make the whole RFC unreadable. The intention of separate > specifications is to have one's decision on implementation type, i.e. > ASN.1 vs XML. Section 1.1. can be further revised to support these > facts. > >> [Denis] I am requesting to add further information to section 1.1. > so > >> that people may understand better why there has been no translation > of > >> the ASN.1 into XML. > [Tobias]: I find section 1.1 as it is totally satisfactory regarding > reasons and explanations. Adding further reasons is redundant. However > as opinions can obviously deviate on this matter, maybe you could > provide reasons for why you feel this additional paragraph is needed = to > understand the RFC better and maybe give some indication on how much > information you think would be needed (as I would like to keep it as > concise as possible)? Would a short three-line paragraph based on my > initial answer to your comment satisfy your request to further > information? >=20 > >> 2) Page 43 states: > >> > >> A generic solution for automatic interpretation of > >> security suitability > >> policies in electronic form is not the subject of this > >> specification. > >> > >> It is a copy and paste of the same text which existed in > >> RFC 4998. > >> > >> However, this document omits to take into consideration RFC > >> 5698 which has been issued > >> in November 2009 (Data Structure for the Security > >> Suitability of Cryptographic Algorithms > >> - DSSC) and which respond to the problem raised. > >> > >> While it is normal that the concept was not supported in > >> August 2007 when ERS was published, > >> it is abnormal that the problems highlighted in RFC 5698 > >> are not covered by this draft. In order to > >> demonstrate that an algorithm was not weak, it is useful to > >> include a data structure that lists the > >> weak algorithms at a given point of time. This is what RFC > >> 5698 allows. > >> > >> In any case, the text from section 7 (page 43) needs to be > >> updated. > >> > >> > >> > >> Thank you, I missed that. I agree. We definitely should refer to > >> RFC5698 as a method that may be used and add it to the informative > >> references. > >> > >> > >> [Denis] In fact , I am asking more that simply making a reference = to > >> RFC 5698, but to be able to include some structures defined in RFC > 5698 > >> into XMLERS. RFC 5698 should then be in the normative references. > Hm, I can not see the value of adding used dssc policy data to the > Evidence Records beyond anecdotal interest. > DSSC was intended to support the operation of a LTA (i.e. help decide > when to do which renewal processes) and verification clients to > automatically process policies (about which algorithms were valid for > which time spans). > All evidence in an evidence record is based on the used algorithms and > the external TSA as a trust anchor. > So, although it may be interesting to see which policies the archive > did > use during its operation, this must not influence the future > verification of the signatures and evidence records. > (Consider the following case: a verification client in 2020 operates > based on a dssc policy that declares that e.g. SHA-1 was valid until > 2012 and that all hashes thereafter must be done by SHA-256 or higher. > What difference would it make if the LTA would include into the > Evidence > Record its own policies stating that it believed SHA-1 was valid until > 2015? The verification client would still have to follow its own dssc > policy data for the verification and must ignore this data provided by > the LTA. Remember: a LTA is not trusted by itself, but relies on the > TSA > as a trust anchor for its evidence records.) >=20 > Thus, I can not see the value of DSSCs data provided with Evidence > Records. >=20 > If you could provide a scenario where this data is valuable, the best > way to integrate dssc data it into the structure would be in the form > of > a "Cryptographic Information Type" with its own identifier (in which > case you would be right and we would have to move the reference to the > normative section). >=20 > >> 3) The most important concern is the following one : there > >> is no rule in the document to explain > >> how to really verify a given ERS-XML structure. Which root > >> keys need to be used to verify one structure ? > >> Which rules to apply to verify an ERS-XML data structure > >> that is 30 years old ? The notion of multiple > >> validation policies should be supported, since validation > >> policies that will exist 30 years from now are still unknown. > >> > >> Having a data structure is fine, but it is insufficient to > >> allow interoperability. > >> > >> The data structure should be able to reference the > >> validation policy used at each TST addition. > >> The current data structure is unable to support the > >> verification of an ERS-XML data structure that is 30 years old. > >> > >> Unless verification rules are explained in detail, this > >> document will not achieve its goal and will not be practically > usable. > >> > >> > >> > >> Verification rules may be different for different legislation and > >> countries and as you pointed out may even evolve over time. > >> A problem true for all signatures (be it certs, timestamps, etc.) > >> and not for XMLERS alone required to determine. > >> The draft (as with ERS) is based on the fact that all reasonable > >> validation data is stored and preserved > >> (e.g. by also using XMLERS/ERS or integrating into the timestamp > >> structures) and is validated based on the policy > >> at the time of the validation in the future. So a different > >> validation policy at each TST addition is not significant for the > >> future validation. > >> > >> [Denis] We are in strong disagreement here. > >> > >> Let us use a example. A TST is renewed every 10 years. > >> > >> After ten years, I apply what a would call an "algorithm = maintenance > >> policy" and I reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > the > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> Ten years later, I choose another "algorithm maintenance policy" = and > I > >> reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > >> inner "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. Then I look at the OID/URN from > outer > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> There is not a global verification, but a verification that is > >> different at each step. > >> > >> The implication is to add to the current structure a new field to > >> indicate the OID/URN of the "algorithm maintenance policy" > >> that has been used for that step. > Yes we are in disagreement, though am not sure about the root of it. > Our > disagreement may result from a number things: > First, verification of all individual timestamps inside an evidence > record (i.e. in the Archive time stamps) follow the same verification > rules as if you would use to verify them seen atomic (one by one) > (based > on the time of the following renewal). > Second, there may be misunderstanding of the role of a LTA: as > specified > in 4810 and 4998, the security of the provided evidence records relies > on the cryptographic algorithms and a TSA as a trust anchor (there is > not need to e.g. certify a LTA itself as a trusted entity as well, at > least not for the validity of evidence records). > Therefore the applied policies must be appropriate for future > verifications to succeed, but this depends on the legal requirements = of > what verification data is required for the used timestamps (which may > vary based on what type of TSA is used (e.g. how long it is guaranteed > to provide certificates and other verification data) and other means. > Third, the example I outlined at #2 may also help to understand why a > field "field to indicate the OID/URN of the "algorithm maintenance > policy"" does not add value. >=20 > > If I understand your comments correctly, what you are referring to = is > audit trail on the decision making process of time stamp renewal. > Policy/policies inclusion reminds me on the AESs and their references > to singing policies and I am not really sure whether the basic ERs > structure (ASN.1 or XML) is to support that. However I do agree this = is > a very important issue but it brings us to a crossroad of policies = that > may be part of the ERS structure. For example, the ERS system might > operate per different policies, also the organizational perspective of > the evidence system may have implication on generation and maintenance > of preservation evidences (which again might be a sub-element of much > broader electronic data preservation policies). > > > >> Note: if we add this information to XMLERS, it would make sense to > do > >> the same for ERS. > >> > >> So a different validation policy at each TST addition is not > >> significant for the future validation. Even if it might be > interesting, > >> the key decision making unit will be the validation at the future > >> point (e.g. in 30 years) and not what policies the system > >> might have found appropriate at the time of timestamp renewals. > >> > >> On a personal note: I started an individual draft > >> https://datatracker.ietf.org/doc/draft-ietf-ltans-validate/ about > >> validation > >> and necessary data. It is still very early stage work in progress > >> (as I wanted to wait for XMLERS to finish first) > >> and I find the procedures to be probably quite controversial. So > >> the draft will not be continued in the LTANS WG > >> but submitted only as an individual informational ID. (If you > >> don't mind, I'd actually like to come back to you on that > >> and ask you for your input on it once I have refined it in a few > >> weeks time) > >> > >> [Denis] Thank you for the information. Until we solve the previous > >> point, it is likely that we will be in disagreement. > >> > >> However, this illustrates the fact that without addtional > information > >> on how to use and verify the data structure, > >> the current XMLERS draft is not usable in practice (i.e. there is = no > >> interoperability). > No. XMLERS follows ERS in this regard and ERS is absolutely usable in > practice (best proof for that is that it is effectively used by a > number > of systems today). > To provide further explanation a bit more: Today, LTA operators = usually > get some operational or legal advice to which verification data is > required and based on that integrate this into the structures (based > e.g. on the retention time of the data and the times of guaranteed > availability of verification data). E.g. a LTA operator may store data > that is kept only for 10 years, while the TSA (and even CAs for > signatures in stored documents) it uses has a government certification > (guarantee) to keep verification data available for 30 years. (In = which > case he may not be legally bound to store that data.) >=20 >=20 > > Then this implies to ERS also. >=20 > >> 4) The text omits to consider how to deal with the risk of > >> TSU key compromission and what to do if a given > >> TSU key has been compromised. > >> > >> As I understand it, TSU key compromission would lead to > >> revocation of its certificate and loss of validity. > >> The draft talks about that, i.e. a Time-stamp renewal. > >> > >> However note, as such timestamp renewal would have to be done > >> timely (and actually before TS looses its validity, > >> there can be problems with cases of late discoveries of such TSU > >> compromissions. With this possibility in mind > >> it is recommended to use two redundant XMLERS with timestamps > >> from different timestamp authorities. > >> (see section 7 Security Considerations) > >> > >> As the detailed valuation of such events and legal requirements > >> may vary by country, it seemed prudent to describe things > >> up to the current level but not further. > >> > >> [Denis] As the document does not sufficiently deal with the > >> verification of the data structure, the case of TSU compromission > >> is not sufficiently addressed. > >> > >> In short, if when applying a new TST, the TSU certificate is marked > as > >> revoked, this is not a problem if the revocation reason > >> is anything else than "compromise". > >> > >> If the revocation reason is "compromise", then the text should say > what > >> to do (or what should have been done earlier). > > I can't agree here. Consequences of revocation event (whatever the > reason) might vary according to policies (even legislation) and > therefore I see no reason to go into details. As Tobias explained, the > draft addresses the problem of loosing validity of TST in general (or > TSU for whatever reason) and proposes general measures to avoid that. > TSA redundancy is one of the solutions which, however, only reduces = the > risk of evidences decomposition in the future. One can consider other > countermeasures, but the draft is not there to address all of them. >=20 > I fully agree with Aljosa's argument (and disagree with you Denis). >=20 > Tobias >=20 >=20 >=20 > > Aljosa > > > >> Once again the data structure is described, but there is > unsufficient > >> guidance on how to use it and check it. > >> > >> Denis > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-08-23, 21:08:54 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > >> Working group last call for this draft will begin > >> today and end on > >> September 7th. Shortly after this draft completes > >> IESG processing the > >> working group will close, as noted during the meeting > >> last month. > >> > >> > -----Original Message----- > >> > From: ltans-bounces@ietf.org >> bounces@ietf.org> [mailto:ltans-bounces@ietf.org >> bounces@ietf.org> ] On Behalf > >> > Of Internet-Drafts@ietf.org >> Drafts@ietf.org> > >> > Sent: Monday, August 23, 2010 2:00 PM > >> > To: i-d-announce@ietf.org >> announce@ietf.org> > >> > Cc: ltans@ietf.org > >> > Subject: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > > >> > A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> > directories. > >> > This draft is a work item of the Long-Term Archive > >> and Notary Services > >> > Working Group of the IETF. > >> > > >> > Title : Extensible Markup Language Evidence Record > >> Syntax > >> > Author(s) : A. Blazic, S. Saljic, T. Gondrom > >> > Filename : draft-ietf-ltans-xmlers-07.txt > >> > Pages : 53 > >> > Date : 2010-8-23 > >> > > >> > In many scenarios, users must be able to > >> demonstrate the (time) > >> > existence, integrity and validity of data including > >> signed data for > >> > long or undetermined period of time. This document > >> specifies XML > >> > syntax and processing rules for creating evidence > >> for long-term > >> non- > >> > repudiation of existence of data. ERS-XML > >> incorporates alternative > >> > syntax and processing rules to ASN.1 ERS syntax by > >> using XML > >> > language. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf- > >> ltans-xmlers-07.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP > >> at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME > >> compliant mail reader > >> > implementation to automatically retrieve the ASCII > >> version of the > >> > Internet-Draft. > >> > > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs > >> Email Security System. > >> > For more information please visit > >> http://www.messagelabs.com/email > >> > > >> > ______________________________________________________________________ > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > >> > >> > >> > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > > _______________________________________________ > > ltans mailing list > > ltans@ietf.org > > https://www.ietf.org/mailman/listinfo/ltans >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans From denis.pinkas@bull.net Tue Oct 12 06:19:03 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7263A696B for ; Tue, 12 Oct 2010 06:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.466 X-Spam-Level: ** X-Spam-Status: No, score=2.466 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g941h0wlX89V for ; Tue, 12 Oct 2010 06:18:59 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id B8ABB3A6961 for ; Tue, 12 Oct 2010 06:18:57 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 8494E18080; Tue, 12 Oct 2010 15:26:19 +0200 (CEST) Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010101215201007:10655 ; Tue, 12 Oct 2010 15:20:10 +0200 From: "Denis Pinkas" To: "tobias.gondrom", "ltans" Date: Tue, 12 Oct 2010 15:20:05 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/10/2010 15:20:10, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/10/2010 15:20:10, Serialize complete at 12/10/2010 15:20:10 Content-Type: multipart/alternative; boundary="----=_NextPart_10101215200505168803405_002" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:19:03 -0000 ------=_NextPart_10101215200505168803405_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable I wonder in which phase we are: still in the resolution of the comment ra= ised in the WG last call ? Anyway, I don't believe that the issues I raised have been satisfactorily= addressed. [Tobias] Hm, I can not see the value of adding used dssc policy data to=20 the Evidence Records beyond anecdotal interest. DSSC was intended to support the operation of a LTA (i.e. help decide whe= n to do=20 which renewal processes) and verification clients to automatically proces= s policies=20 (about which algorithms were valid for which time spans). All evidence in= an evidence record=20 is based on the used algorithms and the external TSA as a trust anchor. S= o, although=20 it may be interesting to see which policies the archive did use during it= s operation,=20 this must not influence the future verification of the signatures and evi= dence records.=20 [Denis] You said: =93it MAY be interesting to see which policies the arch= ive did use during its operation=94.=20 I would rather say: =93it is MANDATORY to know which [maintenance] polici= es have been applied=20 to the archive even time a new TST has been added. The problem is that, at the minimum, there should be an identifier of the= maintenance policy=20 that has been used (which is not the case in the present document). This = will of course influence=20 the future verification of the TST since the maintenance policy used for = each step (if found acceptable)=20 will have to be used.=20 [Tobias] Consider the following case: a verification client in 2020 operates based= on a dssc policy that=20 declares that e.g. SHA-1 was valid until 2012 and that all hashes thereaf= ter must be done by SHA-256=20 or higher. What difference would it make if the LTA would include into th= e Evidence Record its own policies=20 stating that it believed SHA-1 was valid until 2015? The verification cli= ent would still have to follow its own=20 dssc policy data for the verification and must ignore this data provided = by the LTA. Thus, I can not see the value of DSSCs data provided with Evidence Record= s. If you could provide a scenario=20 where this data is valuable, the best way to integrate dssc data it into = the structure would be in the form=20 of a "Cryptographic Information Type" with its own identifier (in which c= ase you would be right and we=20 would have to move the reference to the normative section). [Denis] Here is the scenario: for each step, the dssc policy (which is pa= rt of the maintenance policy) MUST be=20 indicated. The verification process is a two steps process which may be p= erformed in any order: 1) evaluate the maintenance policy,=20 2) apply the maintenance policy. Evaluating the maintenance policy, is to make sure that the dssc policy i= s acceptable or is correct.=20 Applying the maintenance policy is taking into consideration the dssc pol= icy as indicated. There is however a point where we are in agreement, since you said: =93 Policy/policies inclusion reminds me on the AESs and their references= to singing policies and=20 I am not really sure whether the basic ERs structure (ASN.1 or XML) is to= support that.=20 However I do agree this is a very important issue but it brings us to a c= rossroad of policies=20 that may be part of the ERS structure. For example, the ERS system might = operate per different policies,=94 The basic question is whether the maintenance policies should or should n= ot be part of the structure.=20 However, at this time this element cannot be included. A compromise would= be to consider the maintenance=20 policy as an optional element.=20 [Denis]=20 I said earlier: As the document does not sufficiently deal with the verification of the d= ata structure, the case of TSU compromise=20 is not sufficiently addressed. In short, if when applying a new TST, the= TSU certificate is marked as revoked,=20 this is not a problem if the revocation reason is anything else than "com= promise". If the revocation reason=20 is "compromise", then the text should say what to do (or what should have= been done earlier).=20 You replied: I can't agree here. Consequences of revocation event (whatever the reason= ) might vary according to policies=20 (even legislation) and therefore I see no reason to go into details. As T= obias explained, the draft addresses=20 the problem of loosing validity of TST in general (or TSU for whatever re= ason) and proposes general measures to avoid that. TSA redundancy is one of the solutions which, however, on= ly reduces the risk of evidences=20 decomposition in the future. One can consider other countermeasures, but = the draft is not there to address all of them. Maybe my explanations were not sufficient. Let me state again why there i= s a security hole in the current description. When a new TST is applied, it MUST be proven that at the time the new TST= is applied the certificate of the TSU=20 was not revoked due to a key compromise. If the revocation is for =93cess= ation of activity=94 this is not a problem,=20 since in that case the private key of the TSU has been previously destroy= ed and thus cannot be used nor compromised=20 anymore.=20 The document is lacking to address this major issue. This is also due to = the fact that the document is providing=20 a static description of the data structure and does not sufficiently addr= ess the use of the data structure. This aspect should be addressed both in the main body of the document and= in the security considerations section.=20 If not, my position is the following: the document, as it is, should not = be published as an RFC on the Standards Track. Denis ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : Tobias Gondrom,ltans=20 Date : 2010-10-08, 17:52:10 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt It appears that the issues have been satisfactorily addressed. We'll proc= eed with sending this draft to the AD early next week.=20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of Tobias Gondrom > Sent: Saturday, September 25, 2010 2:26 PM > To: ltans@ietf.org > Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt >=20 > I basically agree with Aljosa. More detailed answers in line > - Tobias >=20 >=20 > On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote: > > Denis, Tobias > > > > It took me a while to get back to XMLERS and my answers are in line. > > > >> -----Original Message----- > >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On > Behalf > >> Of Denis Pinkas > >> Sent: September 14, 2010 12:34 > >> To: ltans > >> Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Tobias, > >> > >> See responses in line. > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-09-13, 19:38:14 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Hi Denis, > >> yes the response is a bit late, but as we still have IETF LC > >> ahead, not too late. > >> Based on Carl's decision we may discuss and resolve this here > >> while the draft proceeds to IESG and IETF LC. > >> Answers inline. > >> > >> Kind regards, Tobias > >> > >> > >> On 09/13/2010 04:48 PM, Denis Pinkas wrote: > >> > >> This is a late response. > >> > >> Comments on draft-ietf-ltans-xmlers-07 > >> > >> 1) The abstract from this draft states: > >> > >> In many scenarios, users must be able to demonstrate the > >> (time) > >> existence, integrity and validity of data including > >> signed data for > >> long or undetermined period of time. This document > >> specifies XML > >> syntax and processing rules for creating evidence for > >> long-term non- > >> repudiation of existence of data. > >> > >> The abstract from RFC 4998, which is very similar, states: > >> > >> In many scenarios, users must be able prove the > >> existence and > >> integrity of data, including digitally signed data, in a > >> common and > >> reproducible way over a long and possibly undetermined > >> period of > >> time. This document specifies the syntax and processing > >> of an > >> Evidence Record, a structure designed to support long- > >> term non- > >> repudiation of existence of data. > >> > >> Then an additional sentence in the draft states: > >> > >> ERS-XML incorporates alternative syntax and processing > >> rules to ASN.1 ERS syntax > >> by using XML language. > >> > >> The basic question is why an addendum has not been added to > >> RFC 4998 to include > >> an XML syntax, equivalent to the ASN.1. > >> > >> Some explanations are given on page 7 are not convincing: > >> > >> Due to the differences in XML processing rules and other > >> characteristics of XML language, XMLERS does not present > >> a direct > >> transformation of ERS in ASN.1 syntax. The XMLERS syntax > >> is based on > >> different processing rules as defined in [RFC4998] and > >> it does not > >> support for example import of ASN.1 values in XML tags. > >> Creating > >> Evidence Records in XML syntax must follow the steps as > >> defined in > >> this draft. XMLERS is a standalone draft and is based on > >> [RFC4998] > >> conceptually only. > >> > >> The text omits to highlight what the differences are. > >> > >> For example, ERS states: > >> > >> The data (e.g. certificates, Certificate Revocation > >> Lists (CRLs), or > >> Online Certificate Status Protocol (OCSP) responses) > >> needed to verify > >> the timestamp MUST be preserved, and SHOULD be stored in > >> the > >> timestamp itself unless this causes unnecessary > >> duplication. > >> > >> While the draft states: > >> > >> An ATS contains a Time-Stamp Token and optionally other > >> useful > >> data for Time-Stamp validation, e.g. certificates, CRLs > >> or OCSP > >> responses > >> > >> In one case CRLs should be part of the TST, while in the > >> other case it should be > >> external to the TST. > >> > >> Section 1.1 should be revised to mention the differences > >> with a rational about them. > >> > >> > >> > >> In theory we could have added XMLERS to ERS, but XML puts > >> different processing issues to the document, > >> for example the ordering problem of the XML elements (to always > >> produce identical hash values > >> for the same data structure). XMLERS required further explanation > >> regarding these processing rules and > >> a well-thought XML structure, plus identifiers to be assigned by > >> IANA for certain types. All these items are not > >> related to ERS or its ASN.1 structure and would have made the RFC > >> unnecessarily complex to read while > >> bringing not much benefit. > >> > >> So a lot of reasons to put this in a separate draft, and not much > >> harm from doing so. > > I support Tobias comments as the benefit of expanding ASN.1 > recommendation with additional XML based structure and processing rules > would make the whole RFC unreadable. The intention of separate > specifications is to have one's decision on implementation type, i.e. > ASN.1 vs XML. Section 1.1. can be further revised to support these > facts. > >> [Denis] I am requesting to add further information to section 1.1. > so > >> that people may understand better why there has been no translation > of > >> the ASN.1 into XML. > [Tobias]: I find section 1.1 as it is totally satisfactory regarding > reasons and explanations. Adding further reasons is redundant. However > as opinions can obviously deviate on this matter, maybe you could > provide reasons for why you feel this additional paragraph is needed to > understand the RFC better and maybe give some indication on how much > information you think would be needed (as I would like to keep it as > concise as possible)? Would a short three-line paragraph based on my > initial answer to your comment satisfy your request to further > information? >=20 > >> 2) Page 43 states: > >> > >> A generic solution for automatic interpretation of > >> security suitability > >> policies in electronic form is not the subject of this > >> specification. > >> > >> It is a copy and paste of the same text which existed in > >> RFC 4998. > >> > >> However, this document omits to take into consideration RFC > >> 5698 which has been issued > >> in November 2009 (Data Structure for the Security > >> Suitability of Cryptographic Algorithms > >> - DSSC) and which respond to the problem raised. > >> > >> While it is normal that the concept was not supported in > >> August 2007 when ERS was published, > >> it is abnormal that the problems highlighted in RFC 5698 > >> are not covered by this draft. In order to > >> demonstrate that an algorithm was not weak, it is useful to > >> include a data structure that lists the > >> weak algorithms at a given point of time. This is what RFC > >> 5698 allows. > >> > >> In any case, the text from section 7 (page 43) needs to be > >> updated. > >> > >> > >> > >> Thank you, I missed that. I agree. We definitely should refer to > >> RFC5698 as a method that may be used and add it to the informative > >> references. > >> > >> > >> [Denis] In fact , I am asking more that simply making a reference to > >> RFC 5698, but to be able to include some structures defined in RFC > 5698 > >> into XMLERS. RFC 5698 should then be in the normative references. > Hm, I can not see the value of adding used dssc policy data to the > Evidence Records beyond anecdotal interest. > DSSC was intended to support the operation of a LTA (i.e. help decide > when to do which renewal processes) and verification clients to > automatically process policies (about which algorithms were valid for > which time spans). > All evidence in an evidence record is based on the used algorithms and > the external TSA as a trust anchor. > So, although it may be interesting to see which policies the archive > did > use during its operation, this must not influence the future > verification of the signatures and evidence records. > (Consider the following case: a verification client in 2020 operates > based on a dssc policy that declares that e.g. SHA-1 was valid until > 2012 and that all hashes thereafter must be done by SHA-256 or higher. > What difference would it make if the LTA would include into the > Evidence > Record its own policies stating that it believed SHA-1 was valid until > 2015? The verification client would still have to follow its own dssc > policy data for the verification and must ignore this data provided by > the LTA. Remember: a LTA is not trusted by itself, but relies on the > TSA > as a trust anchor for its evidence records.) >=20 > Thus, I can not see the value of DSSCs data provided with Evidence > Records. >=20 > If you could provide a scenario where this data is valuable, the best > way to integrate dssc data it into the structure would be in the form > of > a "Cryptographic Information Type" with its own identifier (in which > case you would be right and we would have to move the reference to the > normative section). >=20 > >> 3) The most important concern is the following one : there > >> is no rule in the document to explain > >> how to really verify a given ERS-XML structure. Which root > >> keys need to be used to verify one structure ? > >> Which rules to apply to verify an ERS-XML data structure > >> that is 30 years old ? The notion of multiple > >> validation policies should be supported, since validation > >> policies that will exist 30 years from now are still unknown. > >> > >> Having a data structure is fine, but it is insufficient to > >> allow interoperability. > >> > >> The data structure should be able to reference the > >> validation policy used at each TST addition. > >> The current data structure is unable to support the > >> verification of an ERS-XML data structure that is 30 years old. > >> > >> Unless verification rules are explained in detail, this > >> document will not achieve its goal and will not be practically > usable. > >> > >> > >> > >> Verification rules may be different for different legislation and > >> countries and as you pointed out may even evolve over time. > >> A problem true for all signatures (be it certs, timestamps, etc.) > >> and not for XMLERS alone required to determine. > >> The draft (as with ERS) is based on the fact that all reasonable > >> validation data is stored and preserved > >> (e.g. by also using XMLERS/ERS or integrating into the timestamp > >> structures) and is validated based on the policy > >> at the time of the validation in the future. So a different > >> validation policy at each TST addition is not significant for the > >> future validation. > >> > >> [Denis] We are in strong disagreement here. > >> > >> Let us use a example. A TST is renewed every 10 years. > >> > >> After ten years, I apply what a would call an "algorithm maintenance > >> policy" and I reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > the > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> Ten years later, I choose another "algorithm maintenance policy" and > I > >> reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > >> inner "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. Then I look at the OID/URN from > outer > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> There is not a global verification, but a verification that is > >> different at each step. > >> > >> The implication is to add to the current structure a new field to > >> indicate the OID/URN of the "algorithm maintenance policy" > >> that has been used for that step. > Yes we are in disagreement, though am not sure about the root of it. > Our > disagreement may result from a number things: > First, verification of all individual timestamps inside an evidence > record (i.e. in the Archive time stamps) follow the same verification > rules as if you would use to verify them seen atomic (one by one) > (based > on the time of the following renewal). > Second, there may be misunderstanding of the role of a LTA: as > specified > in 4810 and 4998, the security of the provided evidence records relies > on the cryptographic algorithms and a TSA as a trust anchor (there is > not need to e.g. certify a LTA itself as a trusted entity as well, at > least not for the validity of evidence records). > Therefore the applied policies must be appropriate for future > verifications to succeed, but this depends on the legal requirements of > what verification data is required for the used timestamps (which may > vary based on what type of TSA is used (e.g. how long it is guaranteed > to provide certificates and other verification data) and other means. > Third, the example I outlined at #2 may also help to understand why a > field "field to indicate the OID/URN of the "algorithm maintenance > policy"" does not add value. >=20 > > If I understand your comments correctly, what you are referring to is > audit trail on the decision making process of time stamp renewal. > Policy/policies inclusion reminds me on the AESs and their references > to singing policies and I am not really sure whether the basic ERs > structure (ASN.1 or XML) is to support that. However I do agree this is > a very important issue but it brings us to a crossroad of policies that > may be part of the ERS structure. For example, the ERS system might > operate per different policies, also the organizational perspective of > the evidence system may have implication on generation and maintenance > of preservation evidences (which again might be a sub-element of much > broader electronic data preservation policies). > > > >> Note: if we add this information to XMLERS, it would make sense to > do > >> the same for ERS. > >> > >> So a different validation policy at each TST addition is not > >> significant for the future validation. Even if it might be > interesting, > >> the key decision making unit will be the validation at the future > >> point (e.g. in 30 years) and not what policies the system > >> might have found appropriate at the time of timestamp renewals. > >> > >> On a personal note: I started an individual draft > >> https://datatracker.ietf.org/doc/draft-ietf-ltans-validate/ about > >> validation > >> and necessary data. It is still very early stage work in progress > >> (as I wanted to wait for XMLERS to finish first) > >> and I find the procedures to be probably quite controversial. So > >> the draft will not be continued in the LTANS WG > >> but submitted only as an individual informational ID. (If you > >> don't mind, I'd actually like to come back to you on that > >> and ask you for your input on it once I have refined it in a few > >> weeks time) > >> > >> [Denis] Thank you for the information. Until we solve the previous > >> point, it is likely that we will be in disagreement. > >> > >> However, this illustrates the fact that without addtional > information > >> on how to use and verify the data structure, > >> the current XMLERS draft is not usable in practice (i.e. there is no > >> interoperability). > No. XMLERS follows ERS in this regard and ERS is absolutely usable in > practice (best proof for that is that it is effectively used by a > number > of systems today). > To provide further explanation a bit more: Today, LTA operators usually > get some operational or legal advice to which verification data is > required and based on that integrate this into the structures (based > e.g. on the retention time of the data and the times of guaranteed > availability of verification data). E.g. a LTA operator may store data > that is kept only for 10 years, while the TSA (and even CAs for > signatures in stored documents) it uses has a government certification > (guarantee) to keep verification data available for 30 years. (In which > case he may not be legally bound to store that data.) >=20 >=20 > > Then this implies to ERS also. >=20 > >> 4) The text omits to consider how to deal with the risk of > >> TSU key compromission and what to do if a given > >> TSU key has been compromised. > >> > >> As I understand it, TSU key compromission would lead to > >> revocation of its certificate and loss of validity. > >> The draft talks about that, i.e. a Time-stamp renewal. > >> > >> However note, as such timestamp renewal would have to be done > >> timely (and actually before TS looses its validity, > >> there can be problems with cases of late discoveries of such TSU > >> compromissions. With this possibility in mind > >> it is recommended to use two redundant XMLERS with timestamps > >> from different timestamp authorities. > >> (see section 7 Security Considerations) > >> > >> As the detailed valuation of such events and legal requirements > >> may vary by country, it seemed prudent to describe things > >> up to the current level but not further. > >> > >> [Denis] As the document does not sufficiently deal with the > >> verification of the data structure, the case of TSU compromission > >> is not sufficiently addressed. > >> > >> In short, if when applying a new TST, the TSU certificate is marked > as > >> revoked, this is not a problem if the revocation reason > >> is anything else than "compromise". > >> > >> If the revocation reason is "compromise", then the text should say > what > >> to do (or what should have been done earlier). > > I can't agree here. Consequences of revocation event (whatever the > reason) might vary according to policies (even legislation) and > therefore I see no reason to go into details. As Tobias explained, the > draft addresses the problem of loosing validity of TST in general (or > TSU for whatever reason) and proposes general measures to avoid that. > TSA redundancy is one of the solutions which, however, only reduces the > risk of evidences decomposition in the future. One can consider other > countermeasures, but the draft is not there to address all of them. >=20 > I fully agree with Aljosa's argument (and disagree with you Denis). >=20 > Tobias >=20 >=20 >=20 > > Aljosa > > > >> Once again the data structure is described, but there is > unsufficient > >> guidance on how to use it and check it. > >> > >> Denis > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-08-23, 21:08:54 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > >> Working group last call for this draft will begin > >> today and end on > >> September 7th. Shortly after this draft completes > >> IESG processing the > >> working group will close, as noted during the meeting > >> last month. > >> > >> > -----Original Message----- > >> > From: ltans-bounces@ietf.org >> bounces@ietf.org> [mailto:ltans-bounces@ietf.org >> bounces@ietf.org> ] On Behalf > >> > Of Internet-Drafts@ietf.org >> Drafts@ietf.org> > >> > Sent: Monday, August 23, 2010 2:00 PM > >> > To: i-d-announce@ietf.org >> announce@ietf.org> > >> > Cc: ltans@ietf.org > >> > Subject: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > > >> > A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> > directories. > >> > This draft is a work item of the Long-Term Archive > >> and Notary Services > >> > Working Group of the IETF. > >> > > >> > Title : Extensible Markup Language Evidence Record > >> Syntax > >> > Author(s) : A. Blazic, S. Saljic, T. Gondrom > >> > Filename : draft-ietf-ltans-xmlers-07.txt > >> > Pages : 53 > >> > Date : 2010-8-23 > >> > > >> > In many scenarios, users must be able to > >> demonstrate the (time) > >> > existence, integrity and validity of data including > >> signed data for > >> > long or undetermined period of time. This document > >> specifies XML > >> > syntax and processing rules for creating evidence > >> for long-term > >> non- > >> > repudiation of existence of data. ERS-XML > >> incorporates alternative > >> > syntax and processing rules to ASN.1 ERS syntax by > >> using XML > >> > language. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf- > >> ltans-xmlers-07.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP > >> at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME > >> compliant mail reader > >> > implementation to automatically retrieve the ASCII > >> version of the > >> > Internet-Draft. > >> > > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs > >> Email Security System. > >> > For more information please visit > >> http://www.messagelabs.com/email > >> > > >> > ______________________________________________________________________ > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > >> > >> > >> > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > > _______________________________________________ > > ltans mailing list > > ltans@ietf.org > > https://www.ietf.org/mailman/listinfo/ltans >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans ------=_NextPart_10101215200505168803405_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I wonder in which phase we are: still in the resolution of the = comment=20 raised in the WG last call ?
Anyway, I don't believe that the issues I raised have been satisfact= orily=20 addressed.

[Tobias]=20 Hm, I can not see the value of adding used dssc policy data to
the Ev= idence=20 Records beyond anecdotal interest.

DSSC=20 was intended to support the operation of a LTA (i.e. help decide when to = do=20
which renewal processes) and verification clients to automatically pr= ocess=20 policies
(about which algorithms were valid for which time spans). Al= l=20 evidence in an evidence record
is based on the used algorithms and th= e=20 external TSA as a trust anchor. So, although
it may be interesting to= see=20 which policies the archive did use during its operation,
this must no= t=20 influence the future verification of the signatures and evidence records.= =20

[Denis]=20 You said: =93it MAY be interesting to see which policies the archive did = use=20 during its operation=94.

I=20 would rather say: =93it is MANDATORY to know which [maintenance] policies= have=20 been applied
to the archive even time a new TST has been=20 added.

The=20 problem is that, at the minimum, there should be an identifier of the=20 maintenance policy
that has been used (which is not the case in the p= resent=20 document). This will of course influence
the future verification of t= he TST=20 since the maintenance policy used for each step (if found acceptable) will=20 have to be used.

[Tobias]

Consider=20 the following case: a verification client in 2020 operates based on a dss= c=20 policy that
declares that e.g. SHA-1 was valid until 2012 and that al= l=20 hashes thereafter must be done by SHA-256
or higher. What difference = would=20 it make if the LTA would include into the Evidence Record its own policie= s=20
stating that it believed SHA-1 was valid until 2015? The verification= client=20 would still have to follow its own
dssc policy data for the verificat= ion and=20 must ignore this data provided by the LTA.

Thus,=20 I can not see the value of DSSCs data provided with Evidence Records.  If you could provide a scenario =
where=20 this data is valuable, the best way to integrate dssc data it into the st= ructure=20 would be in the form
of a "Cryptographic Information Type" with its o= wn=20 identifier (in which case you would be right and we
would have to mov= e the=20 reference to the normative section).

[Denis]=20 Here is the scenario: for each step, the dssc policy (which is part of th= e=20 maintenance policy) MUST be
indicated. The verification process is a = two=20 steps process which may be performed in any order:

1)=20 evaluate the maintenance policy,

2)=20 apply the maintenance policy.

Evaluating=20 the maintenance policy, is to make sure that the dssc policy is acceptabl= e or is=20 correct.

Applying=20 the maintenance policy is taking into consideration the dssc policy as=20 indicated.

There=20 is however a point where we are in agreement, since you=20 said:

=93=20 Policy/policies inclusion reminds me on the AESs and their references to = singing=20 policies and
I am not really sure whether the basic ERs structure (AS= N.1 or=20 XML) is to support that.

However=20 I do agree this is a very important issue but it brings us to a crossroad= of=20 policies
that may be part of the ERS structure. For example, the ERS = system=20 might operate per different policies,=94

The=20 basic question is whether the maintenance policies should or should not b= e part=20 of the structure.
However, at this time this element cannot be includ= ed. A=20 compromise would be to consider the maintenance
policy as an optional= =20 element.

[Denis]=20

I=20 said earlier:

As=20 the document does not sufficiently deal with the verification of the data= =20 structure, the case of TSU compromise
is not sufficiently addressed. =  In short, if when applying a new= TST, the=20 TSU certificate is marked as revoked,
this is not a problem if the=20 revocation reason is anything else than "compromise".  If the revocation reason
is=20 "compromise", then the text should say what to do (or what should have be= en done=20 earlier).

You=20 replied:

I=20 can't agree here. Consequences of revocation event (whatever the reason) = might=20 vary according to policies
(even legislation) and therefore I see no = reason=20 to go into details. As Tobias explained, the draft addresses
the prob= lem of=20 loosing validity of TST in general (or TSU for whatever reason) and propo= ses=20 general measures
to avoid that. TSA redundancy is one of the solution= s=20 which, however, only reduces the risk of evidences
decomposition in t= he=20 future. One can consider other countermeasures, but the draft is not ther= e to=20 address all of them.

Maybe=20 my explanations were not sufficient. Let me state again why there is a se= curity=20 hole in the current description.

When=20 a new TST is applied, it MUST be proven that at the time the new TST is a= pplied=20 the certificate of the TSU
was not revoked due to a key compromise. I= f the=20 revocation is for =93cessation of activity=94 this is not a problem,
= since in=20 that case the private key of the TSU has been previously destroyed and th= us=20 cannot be used nor compromised
anymore.

The=20 document is lacking to address this major issue. This is also due to the = fact=20 that the document is providing
a static description of the data struc= ture=20 and does not sufficiently address the use of the data=20 structure.

This=20 aspect should be addressed both in the main body of the document and in t= he=20 security considerations section.
If not, my position is the following= : the=20 document, as it is, should not be published as an RFC on the Standards=20 Track.

Denis

-----=20 Message re=E7u ----- De=20 : ltans-bounces =C0=20 : Tob= ias=20 Gondrom,ltans Date=20 : 2010-10-08, 17:52:10 Sujet=20 : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

It appears that the issues have been satisfactorily addressed. We'= ll=20 proceed with sending this draft to the AD early next week.

>= =20 -----Original Message-----
> From: ltans-bounces@ietf.org [mai= lto:ltans-bounces@ietf.org] On=20 Behalf
> Of Tobias Gondrom
> Sent: Saturday, September 25, = 2010=20 2:26 PM
> To: ltans@ietf.org
> Subject: Re:= [ltans]=20 I-D ACTION:draft-ietf-ltans-xmlers-07.txt
>
> I basically = agree=20 with Aljosa. More detailed answers in line
> - Tobias
> >=20
> On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote:
> &g= t;=20 Denis, Tobias
> >
> > It took me a while to get back = to=20 XMLERS and my answers are in line.
> >
> >> -----O= riginal=20 Message-----
> >> From: ltans-bounces@ietf.org [mai= lto:ltans-bounces@ietf.org] On<= BR>>=20 Behalf
> >> Of Denis Pinkas
> >> Sent: Septembe= r 14,=20 2010 12:34
> >> To: ltans
> >> Subject: Re: [lt= ans]=20 I-D ACTION:draft-ietf-ltans-xmlers-07.txt
> >>
> >= >=20 Tobias,
> >>
> >> See responses in line.
>= ;=20 >>
> >> Denis
> >>
> >> -----= =20 Message re=E7u -----
> >> De : ltans-bounces
> >&g= t; =C0 :=20 ltans
> >> Date : 2010-09-13, 19:38:14
> >> Suj= et :=20 Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
> >><= BR>>=20 >> Hi Denis,
> >> yes the response is a bit late, but= as we=20 still have IETF LC
> >> ahead, not too late.
> >&g= t;=20 Based on Carl's decision we may discuss and resolve this here
> &= gt;>=20 while the draft proceeds to IESG and IETF LC.
> >> Answers=20 inline.
> >>
> >> Kind regards, Tobias
>=20 >>
> >>
> >> On 09/13/2010 04:48 PM, Deni= s=20 Pinkas wrote:
> >>
> >> This is a late=20 response.
> >>
> >> Comments on=20 draft-ietf-ltans-xmlers-07
> >>
> >> 1) The abs= tract=20 from this draft states:
> >>
> >> In many scena= rios,=20 users must be able to demonstrate the
> >> (time)
> &= gt;>=20 existence, integrity and validity of data including
> >> si= gned=20 data for
> >> long or undetermined period of time. This=20 document
> >> specifies XML
> >> syntax and pro= cessing=20 rules for creating evidence for
> >> long-term non-
>= =20 >> repudiation of existence of data.
> >>
> >= ;>=20 The abstract from RFC 4998, which is very similar, states:
>=20 >>
> >> In many scenarios, users must be able prove=20 the
> >> existence and
> >> integrity of data,=20 including digitally signed data, in a
> >> common and
&g= t;=20 >> reproducible way over a long and possibly undetermined
>= =20 >> period of
> >> time. This document specifies the s= yntax=20 and processing
> >> of an
> >> Evidence Record,= a=20 structure designed to support long-
> >> term non-
>=20 >> repudiation of existence of data.
> >>
> >= ;>=20 Then an additional sentence in the draft states:
> >>
&g= t;=20 >> ERS-XML incorporates alternative syntax and processing
>= =20 >> rules to ASN.1 ERS syntax
> >> by using XML=20 language.
> >>
> >> The basic question is why a= n=20 addendum has not been added to
> >> RFC 4998 to include
= >=20 >> an XML syntax, equivalent to the ASN.1.
> >>
&g= t;=20 >> Some explanations are given on page 7 are not convincing:
&= gt;=20 >>
> >> Due to the differences in XML processing rule= s and=20 other
> >> characteristics of XML language, XMLERS does not= =20 present
> >> a direct
> >> transformation of ER= S in=20 ASN.1 syntax. The XMLERS syntax
> >> is based on
> &g= t;>=20 different processing rules as defined in [RFC4998] and
> >>= it=20 does not
> >> support for example import of ASN.1 values in= XML=20 tags.
> >> Creating
> >> Evidence Records in XM= L=20 syntax must follow the steps as
> >> defined in
> >= ;>=20 this draft. XMLERS is a standalone draft and is based on
> >&g= t;=20 [RFC4998]
> >> conceptually only.
> >>
>=20 >> The text omits to highlight what the differences are.
>=20 >>
> >> For example, ERS states:
> >>
= >=20 >> The data (e.g. certificates, Certificate Revocation
> &g= t;>=20 Lists (CRLs), or
> >> Online Certificate Status Protocol (O= CSP)=20 responses)
> >> needed to verify
> >> the times= tamp=20 MUST be preserved, and SHOULD be stored in
> >> the
>= =20 >> timestamp itself unless this causes unnecessary
> >&g= t;=20 duplication.
> >>
> >> While the draft states:<= BR>>=20 >>
> >> An ATS contains a Time-Stamp Token and option= ally=20 other
> >> useful
> >> data for Time-Stamp vali= dation,=20 e.g. certificates, CRLs
> >> or OCSP
> >>=20 responses
> >>
> >> In one case CRLs should be = part of=20 the TST, while in the
> >> other case it should be
>=20 >> external to the TST.
> >>
> >> Section= 1.1=20 should be revised to mention the differences
> >> with a ra= tional=20 about them.
> >>
> >>
> >>
>=20 >> In theory we could have added XMLERS to ERS, but XML puts
&= gt;=20 >> different processing issues to the document,
> >> = for=20 example the ordering problem of the XML elements (to always
> >= ;>=20 produce identical hash values
> >> for the same data struct= ure).=20 XMLERS required further explanation
> >> regarding these=20 processing rules and
> >> a well-thought XML structure, plu= s=20 identifiers to be assigned by
> >> IANA for certain types. = All=20 these items are not
> >> related to ERS or its ASN.1 struct= ure and=20 would have made the RFC
> >> unnecessarily complex to read=20 while
> >> bringing not much benefit.
> >>
&= gt;=20 >> So a lot of reasons to put this in a separate draft, and not=20 much
> >> harm from doing so.
> > I support Tobias= =20 comments as the benefit of expanding ASN.1
> recommendation with=20 additional XML based structure and processing rules
> would make = the=20 whole RFC unreadable. The intention of separate
> specifications = is to=20 have one's decision on implementation type, i.e.
> ASN.1 vs XML. = Section=20 1.1. can be further revised to support these
> facts.
> >= ;>=20 [Denis] I am requesting to add further information to section 1.1.
&= gt;=20 so
> >> that people may understand better why there has bee= n no=20 translation
> of
> >> the ASN.1 into XML.
> [To= bias]:=20 I find section 1.1 as it is totally satisfactory regarding
> reas= ons and=20 explanations. Adding further reasons is redundant. However
> as o= pinions=20 can obviously deviate on this matter, maybe you could
> provide r= easons=20 for why you feel this additional paragraph is needed to
> underst= and the=20 RFC better and maybe give some indication on how much
> informati= on you=20 think would be needed (as I would like to keep it as
> concise as= =20 possible)? Would a short three-line paragraph based on my
> initi= al=20 answer to your comment satisfy your request to further
>=20 information?
>
> >> 2) Page 43 states:
>=20 >>
> >> A generic solution for automatic interpretati= on=20 of
> >> security suitability
> >> policies in=20 electronic form is not the subject of this
> >>=20 specification.
> >>
> >> It is a copy and paste= of the=20 same text which existed in
> >> RFC 4998.
> >><= BR>>=20 >> However, this document omits to take into consideration RFC>=20 >> 5698 which has been issued
> >> in November 2009 (= Data=20 Structure for the Security
> >> Suitability of Cryptographi= c=20 Algorithms
> >> - DSSC) and which respond to the problem=20 raised.
> >>
> >> While it is normal that the c= oncept=20 was not supported in
> >> August 2007 when ERS was=20 published,
> >> it is abnormal that the problems highlighte= d in=20 RFC 5698
> >> are not covered by this draft. In order to>=20 >> demonstrate that an algorithm was not weak, it is useful to>=20 >> include a data structure that lists the
> >> weak=20 algorithms at a given point of time. This is what RFC
> >> = 5698=20 allows.
> >>
> >> In any case, the text from se= ction 7=20 (page 43) needs to be
> >> updated.
> >>
>= ;=20 >>
> >>
> >> Thank you, I missed that. I = agree.=20 We definitely should refer to
> >> RFC5698 as a method that= may be=20 used and add it to the informative
> >> references.
>= =20 >>
> >>
> >> [Denis] In fact , I am askin= g more=20 that simply making a reference to
> >> RFC 5698, but to be = able to=20 include some structures defined in RFC
> 5698
> >> in= to=20 XMLERS. RFC 5698 should then be in the normative references.
> Hm= , I can=20 not see the value of adding used dssc policy data to the
> Eviden= ce=20 Records beyond anecdotal interest.
> DSSC was intended to support= the=20 operation of a LTA (i.e. help decide
> when to do which renewal=20 processes) and verification clients to
> automatically process po= licies=20 (about which algorithms were valid for
> which time spans).
&g= t; All=20 evidence in an evidence record is based on the used algorithms and
&= gt; the=20 external TSA as a trust anchor.
> So, although it may be interest= ing to=20 see which policies the archive
> did
> use during its opera= tion,=20 this must not influence the future
> verification of the signatur= es and=20 evidence records.
> (Consider the following case: a verification = client=20 in 2020 operates
> based on a dssc policy that declares that e.g.= SHA-1=20 was valid until
> 2012 and that all hashes thereafter must be don= e by=20 SHA-256 or higher.
> What difference would it make if the LTA wou= ld=20 include into the
> Evidence
> Record its own policies stati= ng that=20 it believed SHA-1 was valid until
> 2015? The verification client= would=20 still have to follow its own dssc
> policy data for the verificat= ion and=20 must ignore this data provided by
> the LTA. Remember: a LTA is n= ot=20 trusted by itself, but relies on the
> TSA
> as a trust anc= hor for=20 its evidence records.)
>
> Thus, I can not see the value o= f DSSCs=20 data provided with Evidence
> Records.
>
> If you co= uld=20 provide a scenario where this data is valuable, the best
> way to= =20 integrate dssc data it into the structure would be in the form
>=20 of
> a "Cryptographic Information Type" with its own identifier (= in=20 which
> case you would be right and we would have to move the ref= erence=20 to the
> normative section).
>
> >> 3) The mos= t=20 important concern is the following one : there
> >> is no r= ule in=20 the document to explain
> >> how to really verify a given E= RS-XML=20 structure. Which root
> >> keys need to be used to verify o= ne=20 structure ?
> >> Which rules to apply to verify an ERS-XML = data=20 structure
> >> that is 30 years old ? The notion of=20 multiple
> >> validation policies should be supported, sinc= e=20 validation
> >> policies that will exist 30 years from now = are=20 still unknown.
> >>
> >> Having a data structur= e is=20 fine, but it is insufficient to
> >> allow=20 interoperability.
> >>
> >> The data structure = should=20 be able to reference the
> >> validation policy used at eac= h TST=20 addition.
> >> The current data structure is unable to supp= ort=20 the
> >> verification of an ERS-XML data structure that is = 30=20 years old.
> >>
> >> Unless verification rules = are=20 explained in detail, this
> >> document will not achieve it= s goal=20 and will not be practically
> usable.
> >>
>=20 >>
> >>
> >> Verification rules may be di= fferent=20 for different legislation and
> >> countries and as you poi= nted=20 out may even evolve over time.
> >> A problem true for all=20 signatures (be it certs, timestamps, etc.)
> >> and not for= XMLERS=20 alone required to determine.
> >> The draft (as with ERS) i= s based=20 on the fact that all reasonable
> >> validation data is sto= red and=20 preserved
> >> (e.g. by also using XMLERS/ERS or integratin= g into=20 the timestamp
> >> structures) and is validated based on th= e=20 policy
> >> at the time of the validation in the future. So= a=20 different
> >> validation policy at each TST addition is no= t=20 significant for the
> >> future validation.
>=20 >>
> >> [Denis] We are in strong disagreement here.>=20 >>
> >> Let us use a example. A TST is renewed every = 10=20 years.
> >>
> >> After ten years, I apply what = a would=20 call an "algorithm maintenance
> >> policy" and I reference= the=20 OID/URN
> >> from that policy before applying new TST, a=20 certification path and
> CRLs
> >> captured at that t= ime=20 which demonstrate
> >> that the TSU certificate from the ea= rlier=20 TST has not been revoked.
> >>
> >> In order to= verify=20 the structure, I first look at the OID/URN from
> the
> >= ;>=20 "algorithm maintenance policy" and if I find it acceptable,
> >= ;> I=20 apply the rules of the policy.
> >>
> >> Ten ye= ars=20 later, I choose another "algorithm maintenance policy" and
> I>=20 >> reference the OID/URN
> >> from that policy before= =20 applying new TST, a certification path and
> CRLs
> >>= ;=20 captured at that time which demonstrate
> >> that the TSU=20 certificate from the earlier TST has not been revoked.
>=20 >>
> >> In order to verify the structure, I first loo= k at=20 the OID/URN from
> >> inner "algorithm maintenance policy" = and if=20 I find it acceptable,
> >> I apply the rules of the policy.= Then I=20 look at the OID/URN from
> outer
> >> "algorithm main= tenance=20 policy" and if I find it acceptable,
> >> I apply the rules= of the=20 policy.
> >>
> >> There is not a global verific= ation,=20 but a verification that is
> >> different at each step.
= >=20 >>
> >> The implication is to add to the current stru= cture a=20 new field to
> >> indicate the OID/URN of the "algorithm=20 maintenance policy"
> >> that has been used for that step.<= BR>>=20 Yes we are in disagreement, though am not sure about the root of it.>=20 Our
> disagreement may result from a number things:
> First= ,=20 verification of all individual timestamps inside an evidence
> re= cord=20 (i.e. in the Archive time stamps) follow the same verification
> = rules=20 as if you would use to verify them seen atomic (one by one)
>=20 (based
> on the time of the following renewal).
> Second, t= here=20 may be misunderstanding of the role of a LTA: as
> specified
&= gt; in=20 4810 and 4998, the security of the provided evidence records relies
= > on=20 the cryptographic algorithms and a TSA as a trust anchor (there is
&= gt; not=20 need to e.g. certify a LTA itself as a trusted entity as well, at
&g= t;=20 least not for the validity of evidence records).
> Therefore the = applied=20 policies must be appropriate for future
> verifications to succee= d, but=20 this depends on the legal requirements of
> what verification dat= a is=20 required for the used timestamps (which may
> vary based on what = type of=20 TSA is used (e.g. how long it is guaranteed
> to provide certific= ates=20 and other verification data) and other means.
> Third, the exampl= e I=20 outlined at #2 may also help to understand why a
> field "field t= o=20 indicate the OID/URN of the "algorithm maintenance
> policy"" doe= s not=20 add value.
>
> > If I understand your comments correctl= y, what=20 you are referring to is
> audit trail on the decision making proc= ess of=20 time stamp renewal.
> Policy/policies inclusion reminds me on the= AESs=20 and their references
> to singing policies and I am not really su= re=20 whether the basic ERs
> structure (ASN.1 or XML) is to support th= at.=20 However I do agree this is
> a very important issue but it brings= us to=20 a crossroad of policies that
> may be part of the ERS structure. = For=20 example, the ERS system might
> operate per different policies, a= lso the=20 organizational perspective of
> the evidence system may have impl= ication=20 on generation and maintenance
> of preservation evidences (which = again=20 might be a sub-element of much
> broader electronic data preserva= tion=20 policies).
> >
> >> Note: if we add this informati= on to=20 XMLERS, it would make sense to
> do
> >> the same for= =20 ERS.
> >>
> >> So a different validation policy= at=20 each TST addition is not
> >> significant for the future=20 validation. Even if it might be
> interesting,
> >> t= he key=20 decision making unit will be the validation at the future
> >&= gt;=20 point (e.g. in 30 years) and not what policies the system
> >&= gt;=20 might have found appropriate at the time of timestamp renewals.
>= =20 >>
> >> On a personal note: I started an individual=20 draft
> >> ht= tps://datatracker.ietf.org/doc/draft-ietf-ltans-validate/=20 about
> >> validation
> >> and necessary data. = It is=20 still very early stage work in progress
> >> (as I wanted t= o wait=20 for XMLERS to finish first)
> >> and I find the procedures = to be=20 probably quite controversial. So
> >> the draft will not be= =20 continued in the LTANS WG
> >> but submitted only as an ind= ividual=20 informational ID. (If you
> >> don't mind, I'd actually lik= e to=20 come back to you on that
> >> and ask you for your input on= it=20 once I have refined it in a few
> >> weeks time)
>=20 >>
> >> [Denis] Thank you for the information. Until = we=20 solve the previous
> >> point, it is likely that we will be= in=20 disagreement.
> >>
> >> However, this illustrat= es the=20 fact that without addtional
> information
> >> on how= to use=20 and verify the data structure,
> >> the current XMLERS draf= t is=20 not usable in practice (i.e. there is no
> >>=20 interoperability).
> No. XMLERS follows ERS in this regard and ER= S is=20 absolutely usable in
> practice (best proof for that is that it i= s=20 effectively used by a
> number
> of systems today).
>= To=20 provide further explanation a bit more: Today, LTA operators usually>=20 get some operational or legal advice to which verification data is
&= gt;=20 required and based on that integrate this into the structures (based>=20 e.g. on the retention time of the data and the times of guaranteed
&= gt;=20 availability of verification data). E.g. a LTA operator may store data<= BR>>=20 that is kept only for 10 years, while the TSA (and even CAs for
>= =20 signatures in stored documents) it uses has a government certification<= BR>>=20 (guarantee) to keep verification data available for 30 years. (In=20 which
> case he may not be legally bound to store that data.)
= >=20
>
> > Then this implies to ERS also.
>
>=20 >> 4) The text omits to consider how to deal with the risk of
= >=20 >> TSU key compromission and what to do if a given
> >&g= t; TSU=20 key has been compromised.
> >>
> >> As I unders= tand=20 it, TSU key compromission would lead to
> >> revocation of = its=20 certificate and loss of validity.
> >> The draft talks abou= t that,=20 i.e. a Time-stamp renewal.
> >>
> >> However no= te, as=20 such timestamp renewal would have to be done
> >> timely (a= nd=20 actually before TS looses its validity,
> >> there can be p= roblems=20 with cases of late discoveries of such TSU
> >> compromissi= ons.=20 With this possibility in mind
> >> it is recommended to use= two=20 redundant XMLERS with timestamps
> >> from different timest= amp=20 authorities.
> >> (see section 7 Security Considerations)>=20 >>
> >> As the detailed valuation of such events and = legal=20 requirements
> >> may vary by country, it seemed prudent to= =20 describe things
> >> up to the current level but not=20 further.
> >>
> >> [Denis] As the document does= not=20 sufficiently deal with the
> >> verification of the data=20 structure, the case of TSU compromission
> >> is not suffic= iently=20 addressed.
> >>
> >> In short, if when applying= a new=20 TST, the TSU certificate is marked
> as
> >> revoked,= this=20 is not a problem if the revocation reason
> >> is anything = else=20 than "compromise".
> >>
> >> If the revocation = reason=20 is "compromise", then the text should say
> what
> >>= to do=20 (or what should have been done earlier).
> > I can't agree her= e.=20 Consequences of revocation event (whatever the
> reason) might va= ry=20 according to policies (even legislation) and
> therefore I see no= reason=20 to go into details. As Tobias explained, the
> draft addresses th= e=20 problem of loosing validity of TST in general (or
> TSU for whate= ver=20 reason) and proposes general measures to avoid that.
> TSA redund= ancy is=20 one of the solutions which, however, only reduces the
> risk of=20 evidences decomposition in the future. One can consider other
>=20 countermeasures, but the draft is not there to address all of them.
= >=20
> I fully agree with Aljosa's argument (and disagree with you=20 Denis).
>
> Tobias
>
>
>
> >= =20 Aljosa
> >
> >> Once again the data structure is=20 described, but there is
> unsufficient
> >> guidance = on how=20 to use it and check it.
> >>
> >> Denis
>= =20 >>
> >> Denis
> >>
> >> -----= =20 Message re=E7u -----
> >> De : ltans-bounces
> >&g= t; =C0 :=20 ltans
> >> Date : 2010-08-23, 21:08:54
> >> Suj= et :=20 Re: [ltans] I-D ACTION:draft-ietf-ltans-
> >>=20 xmlers-07.txt
> >>
> >> Working group last call= for=20 this draft will begin
> >> today and end on
> >>= ;=20 September 7th. Shortly after this draft completes
> >> IESG= =20 processing the
> >> working group will close, as noted duri= ng the=20 meeting
> >> last month.
> >>
> >> = >=20 -----Original Message-----
> >> > From: ltans-bounces@ietf.org=20 <mailto:%20ltans-
> >> bounces@ietf.org> [mailto:ltans-bounces@ietf.org=20 <mailto:%20ltans-
> >> bounces@ietf.org> ] On Behalf<= BR>>=20 >> > Of Internet-Drafts@ietf.org=20 <mailto:%20Internet-
> >> Drafts@ietf.org>
> >&g= t; >=20 Sent: Monday, August 23, 2010 2:00 PM
> >> > To: i-d-announce@ietf.org=20 <mailto:%20i-d-
> >> announce@ietf.org>
> &g= t;>=20 > Cc: ltans@ietf.org <mail= to:%20ltans@ietf.org>
> >= > >=20 Subject: [ltans] I-D ACTION:draft-ietf-ltans-
> >>=20 xmlers-07.txt
> >> >
> >> > A New Interne= t-Draft=20 is available from the on-line
> >> Internet-Drafts
>=20 >> > directories.
> >> > This draft is a work i= tem of=20 the Long-Term Archive
> >> and Notary Services
> >= >=20 > Working Group of the IETF.
> >> >
> >> = >=20 Title : Extensible Markup Language Evidence Record
> >>=20 Syntax
> >> > Author(s) : A. Blazic, S. Saljic, T.=20 Gondrom
> >> > Filename :=20 draft-ietf-ltans-xmlers-07.txt
> >> > Pages : 53
>= =20 >> > Date : 2010-8-23
> >> >
> >> &= gt; In=20 many scenarios, users must be able to
> >> demonstrate the=20 (time)
> >> > existence, integrity and validity of data=20 including
> >> signed data for
> >> > long o= r=20 undetermined period of time. This document
> >> specifies=20 XML
> >> > syntax and processing rules for creating=20 evidence
> >> for long-term
> >> non-
> &= gt;>=20 > repudiation of existence of data. ERS-XML
> >> incorpo= rates=20 alternative
> >> > syntax and processing rules to ASN.1 = ERS=20 syntax by
> >> using XML
> >> > language.>=20 >> >
> >> > A URL for this Internet-Draft is:>=20 >> > http://www.iet= f.org/internet-drafts/draft-ietf-
>=20 >> ltans-xmlers-07.txt
> >> >
> >> >= ;=20 Internet-Drafts are also available by anonymous FTP
> >>=20 at:
> >> > ftp://ftp.ietf.org/internet-drafts/
> &= gt;>=20 >
> >> > Below is the data which will enable a MIME>=20 >> compliant mail reader
> >> > implementation to=20 automatically retrieve the ASCII
> >> version of the
>= ;=20 >> > Internet-Draft.
> >> >
> >>=20 >
> >> >
> >>
>=20 ______________________________________________________________________<= BR>>=20 >> > This email has been scanned by the MessageLabs
> &g= t;>=20 Email Security System.
> >> > For more information pleas= e=20 visit
> >> http://www.messagelabs.com/em= ail
>=20 >> >
> >>
>=20 ______________________________________________________________________<= BR>>=20 >> _______________________________________________
> >&g= t;=20 ltans mailing list
> >> ltans@ietf.org <mailto:%20ltans@ietf.org>
> >= > https://www.ietf.o= rg/mailman/listinfo/ltans
>=20 >>
> >>
> >>
> >>
> >= ;>=20 _______________________________________________
> >> ltans = mailing=20 list
> >> ltans@ietf.org
> >> https://www.ietf.o= rg/mailman/listinfo/ltans
>=20 >>
> > _______________________________________________>=20 > ltans mailing list
> > ltans@ietf.org
> > https://www.ietf.o= rg/mailman/listinfo/ltans
>=20
> _______________________________________________
> ltans = mailing=20 list
> ltans@ietf.org
&= gt; https://www.ietf.o= rg/mailman/listinfo/ltans
________________________________________= _______
ltans=20 mailing list
ltans@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/ltans
------=_NextPart_10101215200505168803405_002-- From CWallace@cygnacom.com Wed Oct 13 04:45:55 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D923A69DC for ; Wed, 13 Oct 2010 04:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATzj4r3QIUkx for ; Wed, 13 Oct 2010 04:45:22 -0700 (PDT) Received: from mail151.messagelabs.com (mail151.messagelabs.com [216.82.253.3]) by core3.amsl.com (Postfix) with SMTP id 785893A6A02 for ; Wed, 13 Oct 2010 04:45:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-6.tower-151.messagelabs.com!1286970389!38954632!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.8] Received: (qmail 28734 invoked from network); 13 Oct 2010 11:46:30 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-6.tower-151.messagelabs.com with SMTP; 13 Oct 2010 11:46:30 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6ACC.461E4041" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 Oct 2010 07:46:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt Thread-Index: ActqEDu8mXRy3YOXQqK9mjx6f32sSwAufIdg References: From: "Carl Wallace" To: , "tobias.gondrom" , "ltans" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 11:45:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6ACC.461E4041 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Responses inline (as best I can given strange likely inconsistent = tagging of who said what)... =20 From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf = Of Denis Pinkas Sent: Tuesday, October 12, 2010 9:20 AM To: tobias.gondrom; ltans Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt =20 I wonder in which phase we are: still in the resolution of the comment = raised in the WG last call ? Anyway, I don't believe that the issues I raised have been = satisfactorily addressed. [Tobias] Hm, I can not see the value of adding used dssc policy data to=20 the Evidence Records beyond anecdotal interest. DSSC was intended to support the operation of a LTA (i.e. help decide = when to do=20 which renewal processes) and verification clients to automatically = process policies=20 (about which algorithms were valid for which time spans). All evidence = in an evidence record=20 is based on the used algorithms and the external TSA as a trust anchor. = So, although=20 it may be interesting to see which policies the archive did use during = its operation,=20 this must not influence the future verification of the signatures and = evidence records.=20 [Denis] You said: "it MAY be interesting to see which policies the = archive did use during its operation".=20 I would rather say: "it is MANDATORY to know which [maintenance] = policies have been applied=20 to the archive even time a new TST has been added. The problem is that, at the minimum, there should be an identifier of = the maintenance policy=20 that has been used (which is not the case in the present document). This = will of course influence=20 the future verification of the TST since the maintenance policy used for = each step (if found acceptable)=20 will have to be used.=20 [Carl] DSSC applies at validation time. I agree with Tobias that while = one could package the policy with a data item it is not necessary. It = doesn't really matter what policy the LTA had in mind. What matters is = that the evidence record passes the policy used by the relying party. I = see no reason to make a change to include DSSC policy in the XMLERS = format. [Tobias] Consider the following case: a verification client in 2020 operates = based on a dssc policy that=20 declares that e.g. SHA-1 was valid until 2012 and that all hashes = thereafter must be done by SHA-256=20 or higher. What difference would it make if the LTA would include into = the Evidence Record its own policies=20 stating that it believed SHA-1 was valid until 2015? The verification = client would still have to follow its own=20 dssc policy data for the verification and must ignore this data provided = by the LTA. Thus, I can not see the value of DSSCs data provided with Evidence = Records. If you could provide a scenario=20 where this data is valuable, the best way to integrate dssc data it into = the structure would be in the form=20 of a "Cryptographic Information Type" with its own identifier (in which = case you would be right and we=20 would have to move the reference to the normative section). [Denis] Here is the scenario: for each step, the dssc policy (which is = part of the maintenance policy) MUST be=20 indicated. The verification process is a two steps process which may be = performed in any order: 1) evaluate the maintenance policy,=20 2) apply the maintenance policy. Evaluating the maintenance policy, is to make sure that the dssc policy = is acceptable or is correct.=20 Applying the maintenance policy is taking into consideration the dssc = policy as indicated. There is however a point where we are in agreement, since you said: " Policy/policies inclusion reminds me on the AESs and their references = to singing policies and=20 I am not really sure whether the basic ERs structure (ASN.1 or XML) is = to support that.=20 However I do agree this is a very important issue but it brings us to a = crossroad of policies=20 that may be part of the ERS structure. For example, the ERS system might = operate per different policies," The basic question is whether the maintenance policies should or should = not be part of the structure.=20 However, at this time this element cannot be included. A compromise = would be to consider the maintenance=20 policy as an optional element.=20 [Denis]=20 I said earlier: As the document does not sufficiently deal with the verification of the = data structure, the case of TSU compromise=20 is not sufficiently addressed. In short, if when applying a new TST, = the TSU certificate is marked as revoked,=20 this is not a problem if the revocation reason is anything else than = "compromise". If the revocation reason=20 is "compromise", then the text should say what to do (or what should = have been done earlier).=20 You replied: I can't agree here. Consequences of revocation event (whatever the = reason) might vary according to policies=20 (even legislation) and therefore I see no reason to go into details. As = Tobias explained, the draft addresses=20 the problem of loosing validity of TST in general (or TSU for whatever = reason) and proposes general measures to avoid that. TSA redundancy is one of the solutions which, however, = only reduces the risk of evidences=20 decomposition in the future. One can consider other countermeasures, but = the draft is not there to address all of them. Maybe my explanations were not sufficient. Let me state again why there = is a security hole in the current description. When a new TST is applied, it MUST be proven that at the time the new = TST is applied the certificate of the TSU=20 was not revoked due to a key compromise. If the revocation is for = "cessation of activity" this is not a problem,=20 since in that case the private key of the TSU has been previously = destroyed and thus cannot be used nor compromised=20 anymore.=20 [Carl] I disagree, for reasons you have cited in the past. There will = always be a grace period applied at validation time so this "MUST be = proven at the time the new TST is applied" cannot be true. In any case, = these sorts of issues are for the relying party to appraise and the = policies used by relying parties may vary, hence DSSC need not be = included. =20 The document is lacking to address this major issue. This is also due to = the fact that the document is providing=20 a static description of the data structure and does not sufficiently = address the use of the data structure. [Carl] This neatly summarizes the situation. The XMLERS format does not = address the use relative to crypto policy. Fortunately, it does not = need to as DSSC addresses this. Each and every evidence record need not = carry around this DSSC policy as the relying party can maintain a copy = of the policy it wishes to use when validating an evidence record. =20 This aspect should be addressed both in the main body of the document = and in the security considerations section.=20 If not, my position is the following: the document, as it is, should not = be published as an RFC on the Standards Track. [Carl] A security consideration on this topic seems like a reasonable = thing to do. Tobias, can you add a security consideration to address = the separation of evidence record from policy? I think that will close = this issue. =20 Denis ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : Tobias Gondrom,ltans=20 Date : 2010-10-08, 17:52:10 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt =20 It appears that the issues have been satisfactorily addressed. We'll = proceed with sending this draft to the AD early next week.=20 =09 > -----Original Message----- > From: ltans-bounces@ietf.org = [mailto:ltans-bounces@ietf.org ] On = Behalf > Of Tobias Gondrom > Sent: Saturday, September 25, 2010 2:26 PM > To: ltans@ietf.org =20 > Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt >=20 > I basically agree with Aljosa. More detailed answers in line > - Tobias >=20 >=20 > On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote: > > Denis, Tobias > > > > It took me a while to get back to XMLERS and my answers are in = line. > > > >> -----Original Message----- > >> From: ltans-bounces@ietf.org = [mailto:ltans-bounces@ietf.org ] On > Behalf > >> Of Denis Pinkas > >> Sent: September 14, 2010 12:34 > >> To: ltans > >> Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Tobias, > >> > >> See responses in line. > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-09-13, 19:38:14 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Hi Denis, > >> yes the response is a bit late, but as we still have IETF LC > >> ahead, not too late. > >> Based on Carl's decision we may discuss and resolve this here > >> while the draft proceeds to IESG and IETF LC. > >> Answers inline. > >> > >> Kind regards, Tobias > >> > >> > >> On 09/13/2010 04:48 PM, Denis Pinkas wrote: > >> > >> This is a late response. > >> > >> Comments on draft-ietf-ltans-xmlers-07 > >> > >> 1) The abstract from this draft states: > >> > >> In many scenarios, users must be able to demonstrate the > >> (time) > >> existence, integrity and validity of data including > >> signed data for > >> long or undetermined period of time. This document > >> specifies XML > >> syntax and processing rules for creating evidence for > >> long-term non- > >> repudiation of existence of data. > >> > >> The abstract from RFC 4998, which is very similar, states: > >> > >> In many scenarios, users must be able prove the > >> existence and > >> integrity of data, including digitally signed data, in a > >> common and > >> reproducible way over a long and possibly undetermined > >> period of > >> time. This document specifies the syntax and processing > >> of an > >> Evidence Record, a structure designed to support long- > >> term non- > >> repudiation of existence of data. > >> > >> Then an additional sentence in the draft states: > >> > >> ERS-XML incorporates alternative syntax and processing > >> rules to ASN.1 ERS syntax > >> by using XML language. > >> > >> The basic question is why an addendum has not been added to > >> RFC 4998 to include > >> an XML syntax, equivalent to the ASN.1. > >> > >> Some explanations are given on page 7 are not convincing: > >> > >> Due to the differences in XML processing rules and other > >> characteristics of XML language, XMLERS does not present > >> a direct > >> transformation of ERS in ASN.1 syntax. The XMLERS syntax > >> is based on > >> different processing rules as defined in [RFC4998] and > >> it does not > >> support for example import of ASN.1 values in XML tags. > >> Creating > >> Evidence Records in XML syntax must follow the steps as > >> defined in > >> this draft. XMLERS is a standalone draft and is based on > >> [RFC4998] > >> conceptually only. > >> > >> The text omits to highlight what the differences are. > >> > >> For example, ERS states: > >> > >> The data (e.g. certificates, Certificate Revocation > >> Lists (CRLs), or > >> Online Certificate Status Protocol (OCSP) responses) > >> needed to verify > >> the timestamp MUST be preserved, and SHOULD be stored in > >> the > >> timestamp itself unless this causes unnecessary > >> duplication. > >> > >> While the draft states: > >> > >> An ATS contains a Time-Stamp Token and optionally other > >> useful > >> data for Time-Stamp validation, e.g. certificates, CRLs > >> or OCSP > >> responses > >> > >> In one case CRLs should be part of the TST, while in the > >> other case it should be > >> external to the TST. > >> > >> Section 1.1 should be revised to mention the differences > >> with a rational about them. > >> > >> > >> > >> In theory we could have added XMLERS to ERS, but XML puts > >> different processing issues to the document, > >> for example the ordering problem of the XML elements (to always > >> produce identical hash values > >> for the same data structure). XMLERS required further explanation > >> regarding these processing rules and > >> a well-thought XML structure, plus identifiers to be assigned by > >> IANA for certain types. All these items are not > >> related to ERS or its ASN.1 structure and would have made the RFC > >> unnecessarily complex to read while > >> bringing not much benefit. > >> > >> So a lot of reasons to put this in a separate draft, and not much > >> harm from doing so. > > I support Tobias comments as the benefit of expanding ASN.1 > recommendation with additional XML based structure and processing = rules > would make the whole RFC unreadable. The intention of separate > specifications is to have one's decision on implementation type, i.e. > ASN.1 vs XML. Section 1.1. can be further revised to support these > facts. > >> [Denis] I am requesting to add further information to section 1.1. > so > >> that people may understand better why there has been no = translation > of > >> the ASN.1 into XML. > [Tobias]: I find section 1.1 as it is totally satisfactory regarding > reasons and explanations. Adding further reasons is redundant. = However > as opinions can obviously deviate on this matter, maybe you could > provide reasons for why you feel this additional paragraph is needed = to > understand the RFC better and maybe give some indication on how much > information you think would be needed (as I would like to keep it as > concise as possible)? Would a short three-line paragraph based on my > initial answer to your comment satisfy your request to further > information? >=20 > >> 2) Page 43 states: > >> > >> A generic solution for automatic interpretation of > >> security suitability > >> policies in electronic form is not the subject of this > >> specification. > >> > >> It is a copy and paste of the same text which existed in > >> RFC 4998. > >> > >> However, this document omits to take into consideration RFC > >> 5698 which has been issued > >> in November 2009 (Data Structure for the Security > >> Suitability of Cryptographic Algorithms > >> - DSSC) and which respond to the problem raised. > >> > >> While it is normal that the concept was not supported in > >> August 2007 when ERS was published, > >> it is abnormal that the problems highlighted in RFC 5698 > >> are not covered by this draft. In order to > >> demonstrate that an algorithm was not weak, it is useful to > >> include a data structure that lists the > >> weak algorithms at a given point of time. This is what RFC > >> 5698 allows. > >> > >> In any case, the text from section 7 (page 43) needs to be > >> updated. > >> > >> > >> > >> Thank you, I missed that. I agree. We definitely should refer to > >> RFC5698 as a method that may be used and add it to the informative > >> references. > >> > >> > >> [Denis] In fact , I am asking more that simply making a reference = to > >> RFC 5698, but to be able to include some structures defined in RFC > 5698 > >> into XMLERS. RFC 5698 should then be in the normative references. > Hm, I can not see the value of adding used dssc policy data to the > Evidence Records beyond anecdotal interest. > DSSC was intended to support the operation of a LTA (i.e. help decide > when to do which renewal processes) and verification clients to > automatically process policies (about which algorithms were valid for > which time spans). > All evidence in an evidence record is based on the used algorithms = and > the external TSA as a trust anchor. > So, although it may be interesting to see which policies the archive > did > use during its operation, this must not influence the future > verification of the signatures and evidence records. > (Consider the following case: a verification client in 2020 operates > based on a dssc policy that declares that e.g. SHA-1 was valid until > 2012 and that all hashes thereafter must be done by SHA-256 or = higher. > What difference would it make if the LTA would include into the > Evidence > Record its own policies stating that it believed SHA-1 was valid = until > 2015? The verification client would still have to follow its own dssc > policy data for the verification and must ignore this data provided = by > the LTA. Remember: a LTA is not trusted by itself, but relies on the > TSA > as a trust anchor for its evidence records.) >=20 > Thus, I can not see the value of DSSCs data provided with Evidence > Records. >=20 > If you could provide a scenario where this data is valuable, the best > way to integrate dssc data it into the structure would be in the form > of > a "Cryptographic Information Type" with its own identifier (in which > case you would be right and we would have to move the reference to = the > normative section). >=20 > >> 3) The most important concern is the following one : there > >> is no rule in the document to explain > >> how to really verify a given ERS-XML structure. Which root > >> keys need to be used to verify one structure ? > >> Which rules to apply to verify an ERS-XML data structure > >> that is 30 years old ? The notion of multiple > >> validation policies should be supported, since validation > >> policies that will exist 30 years from now are still unknown. > >> > >> Having a data structure is fine, but it is insufficient to > >> allow interoperability. > >> > >> The data structure should be able to reference the > >> validation policy used at each TST addition. > >> The current data structure is unable to support the > >> verification of an ERS-XML data structure that is 30 years old. > >> > >> Unless verification rules are explained in detail, this > >> document will not achieve its goal and will not be practically > usable. > >> > >> > >> > >> Verification rules may be different for different legislation and > >> countries and as you pointed out may even evolve over time. > >> A problem true for all signatures (be it certs, timestamps, etc.) > >> and not for XMLERS alone required to determine. > >> The draft (as with ERS) is based on the fact that all reasonable > >> validation data is stored and preserved > >> (e.g. by also using XMLERS/ERS or integrating into the timestamp > >> structures) and is validated based on the policy > >> at the time of the validation in the future. So a different > >> validation policy at each TST addition is not significant for the > >> future validation. > >> > >> [Denis] We are in strong disagreement here. > >> > >> Let us use a example. A TST is renewed every 10 years. > >> > >> After ten years, I apply what a would call an "algorithm = maintenance > >> policy" and I reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been = revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > the > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> Ten years later, I choose another "algorithm maintenance policy" = and > I > >> reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been = revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > >> inner "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. Then I look at the OID/URN from > outer > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> There is not a global verification, but a verification that is > >> different at each step. > >> > >> The implication is to add to the current structure a new field to > >> indicate the OID/URN of the "algorithm maintenance policy" > >> that has been used for that step. > Yes we are in disagreement, though am not sure about the root of it. > Our > disagreement may result from a number things: > First, verification of all individual timestamps inside an evidence > record (i.e. in the Archive time stamps) follow the same verification > rules as if you would use to verify them seen atomic (one by one) > (based > on the time of the following renewal). > Second, there may be misunderstanding of the role of a LTA: as > specified > in 4810 and 4998, the security of the provided evidence records = relies > on the cryptographic algorithms and a TSA as a trust anchor (there is > not need to e.g. certify a LTA itself as a trusted entity as well, at > least not for the validity of evidence records). > Therefore the applied policies must be appropriate for future > verifications to succeed, but this depends on the legal requirements = of > what verification data is required for the used timestamps (which may > vary based on what type of TSA is used (e.g. how long it is = guaranteed > to provide certificates and other verification data) and other means. > Third, the example I outlined at #2 may also help to understand why a > field "field to indicate the OID/URN of the "algorithm maintenance > policy"" does not add value. >=20 > > If I understand your comments correctly, what you are referring to = is > audit trail on the decision making process of time stamp renewal. > Policy/policies inclusion reminds me on the AESs and their references > to singing policies and I am not really sure whether the basic ERs > structure (ASN.1 or XML) is to support that. However I do agree this = is > a very important issue but it brings us to a crossroad of policies = that > may be part of the ERS structure. For example, the ERS system might > operate per different policies, also the organizational perspective = of > the evidence system may have implication on generation and = maintenance > of preservation evidences (which again might be a sub-element of much > broader electronic data preservation policies). > > > >> Note: if we add this information to XMLERS, it would make sense to > do > >> the same for ERS. > >> > >> So a different validation policy at each TST addition is not > >> significant for the future validation. Even if it might be > interesting, > >> the key decision making unit will be the validation at the future > >> point (e.g. in 30 years) and not what policies the system > >> might have found appropriate at the time of timestamp renewals. > >> > >> On a personal note: I started an individual draft > >> https://datatracker.ietf.org/doc/draft-ietf-ltans-validate/ about > >> validation > >> and necessary data. It is still very early stage work in progress > >> (as I wanted to wait for XMLERS to finish first) > >> and I find the procedures to be probably quite controversial. So > >> the draft will not be continued in the LTANS WG > >> but submitted only as an individual informational ID. (If you > >> don't mind, I'd actually like to come back to you on that > >> and ask you for your input on it once I have refined it in a few > >> weeks time) > >> > >> [Denis] Thank you for the information. Until we solve the previous > >> point, it is likely that we will be in disagreement. > >> > >> However, this illustrates the fact that without addtional > information > >> on how to use and verify the data structure, > >> the current XMLERS draft is not usable in practice (i.e. there is = no > >> interoperability). > No. XMLERS follows ERS in this regard and ERS is absolutely usable in > practice (best proof for that is that it is effectively used by a > number > of systems today). > To provide further explanation a bit more: Today, LTA operators = usually > get some operational or legal advice to which verification data is > required and based on that integrate this into the structures (based > e.g. on the retention time of the data and the times of guaranteed > availability of verification data). E.g. a LTA operator may store = data > that is kept only for 10 years, while the TSA (and even CAs for > signatures in stored documents) it uses has a government = certification > (guarantee) to keep verification data available for 30 years. (In = which > case he may not be legally bound to store that data.) >=20 >=20 > > Then this implies to ERS also. >=20 > >> 4) The text omits to consider how to deal with the risk of > >> TSU key compromission and what to do if a given > >> TSU key has been compromised. > >> > >> As I understand it, TSU key compromission would lead to > >> revocation of its certificate and loss of validity. > >> The draft talks about that, i.e. a Time-stamp renewal. > >> > >> However note, as such timestamp renewal would have to be done > >> timely (and actually before TS looses its validity, > >> there can be problems with cases of late discoveries of such TSU > >> compromissions. With this possibility in mind > >> it is recommended to use two redundant XMLERS with timestamps > >> from different timestamp authorities. > >> (see section 7 Security Considerations) > >> > >> As the detailed valuation of such events and legal requirements > >> may vary by country, it seemed prudent to describe things > >> up to the current level but not further. > >> > >> [Denis] As the document does not sufficiently deal with the > >> verification of the data structure, the case of TSU compromission > >> is not sufficiently addressed. > >> > >> In short, if when applying a new TST, the TSU certificate is = marked > as > >> revoked, this is not a problem if the revocation reason > >> is anything else than "compromise". > >> > >> If the revocation reason is "compromise", then the text should say > what > >> to do (or what should have been done earlier). > > I can't agree here. Consequences of revocation event (whatever the > reason) might vary according to policies (even legislation) and > therefore I see no reason to go into details. As Tobias explained, = the > draft addresses the problem of loosing validity of TST in general (or > TSU for whatever reason) and proposes general measures to avoid that. > TSA redundancy is one of the solutions which, however, only reduces = the > risk of evidences decomposition in the future. One can consider other > countermeasures, but the draft is not there to address all of them. >=20 > I fully agree with Aljosa's argument (and disagree with you Denis). >=20 > Tobias >=20 >=20 >=20 > > Aljosa > > > >> Once again the data structure is described, but there is > unsufficient > >> guidance on how to use it and check it. > >> > >> Denis > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-08-23, 21:08:54 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > >> Working group last call for this draft will begin > >> today and end on > >> September 7th. Shortly after this draft completes > >> IESG processing the > >> working group will close, as noted during the meeting > >> last month. > >> > >> > -----Original Message----- > >> > From: ltans-bounces@ietf.org = >> bounces@ietf.org > = [mailto:ltans-bounces@ietf.org = >> bounces@ietf.org > ] On Behalf > >> > Of Internet-Drafts@ietf.org = >> Drafts@ietf.org > > >> > Sent: Monday, August 23, 2010 2:00 PM > >> > To: i-d-announce@ietf.org = >> announce@ietf.org > > >> > Cc: ltans@ietf.org = > > >> > Subject: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > > >> > A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> > directories. > >> > This draft is a work item of the Long-Term Archive > >> and Notary Services > >> > Working Group of the IETF. > >> > > >> > Title : Extensible Markup Language Evidence Record > >> Syntax > >> > Author(s) : A. Blazic, S. Saljic, T. Gondrom > >> > Filename : draft-ietf-ltans-xmlers-07.txt > >> > Pages : 53 > >> > Date : 2010-8-23 > >> > > >> > In many scenarios, users must be able to > >> demonstrate the (time) > >> > existence, integrity and validity of data including > >> signed data for > >> > long or undetermined period of time. This document > >> specifies XML > >> > syntax and processing rules for creating evidence > >> for long-term > >> non- > >> > repudiation of existence of data. ERS-XML > >> incorporates alternative > >> > syntax and processing rules to ASN.1 ERS syntax by > >> using XML > >> > language. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf- > >> ltans-xmlers-07.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP > >> at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME > >> compliant mail reader > >> > implementation to automatically retrieve the ASCII > >> version of the > >> > Internet-Draft. > >> > > >> > > >> > > >> > = ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs > >> Email Security System. > >> > For more information please visit > >> http://www.messagelabs.com/email > >> > > >> > = ______________________________________________________________________ > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org = > > >> https://www.ietf.org/mailman/listinfo/ltans > >> > >> > >> > >> > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org =20 > >> https://www.ietf.org/mailman/listinfo/ltans > >> > > _______________________________________________ > > ltans mailing list > > ltans@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/ltans >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org =20 > https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org =20 https://www.ietf.org/mailman/listinfo/ltans ------_=_NextPart_001_01CB6ACC.461E4041 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Responses inline (as best I can given strange likely = inconsistent tagging of who said what)…

 

From:= ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of = Denis Pinkas
Sent: Tuesday, October 12, 2010 9:20 AM
To: tobias.gondrom; ltans
Subject: Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt

 

I wonder in which phase we are: still in the resolution of the = comment raised in the WG last call ?

Anyway, I don't believe that the issues I raised have been satisfactorily = addressed.

[Tobias] Hm, I can not see the value of adding = used dssc policy data to
the Evidence Records beyond anecdotal interest.

DSSC was intended to support the operation of a = LTA (i.e. help decide when to do
which renewal processes) and verification clients to automatically = process policies
(about which algorithms were valid for which time spans). All evidence = in an evidence record
is based on the used algorithms and the external TSA as a trust anchor. = So, although
it may be interesting to see which policies the archive did use during = its operation,
this must not influence the future verification of the signatures and = evidence records.

[Denis] You said: “it MAY be interesting to = see which policies the archive did use during its operation”. =

I would rather say: “it is MANDATORY to = know which [maintenance] policies have been applied
to the archive even time a new TST has been added.

The problem is that, at the minimum, there should = be an identifier of the maintenance policy
that has been used (which is not the case in the present document). This = will of course influence
the future verification of the TST since the maintenance policy used for = each step (if found acceptable)
will have to be used.

[Carl] DSSC = applies at validation time.=A0 I agree with Tobias that while one could package the = policy with a data item it is not necessary.=A0 It doesn’t really matter = what policy the LTA had in mind.=A0 What matters is that the evidence record = passes the policy used by the relying party.=A0 I see no reason to make a = change to include DSSC policy in the XMLERS format.

[Tobias]

Consider the following case: a verification = client in 2020 operates based on a dssc policy that
declares that e.g. SHA-1 was valid until 2012 and that all hashes = thereafter must be done by SHA-256
or higher. What difference would it make if the LTA would include into = the Evidence Record its own policies
stating that it believed SHA-1 was valid until 2015? The verification = client would still have to follow its own
dssc policy data for the verification and must ignore this data provided = by the LTA.

Thus, I can not see the value of DSSCs data = provided with Evidence Records.=A0 If you could provide a scenario
where this data is valuable, the best way to integrate dssc data it into = the structure would be in the form
of a "Cryptographic Information Type" with its own identifier = (in which case you would be right and we
would have to move the reference to the normative = section).

[Denis] Here is the scenario: for each step, the = dssc policy (which is part of the maintenance policy) MUST be
indicated. The verification process is a two steps process which may be performed in any order:

1) evaluate the maintenance policy, =

2) apply the maintenance = policy.

Evaluating the maintenance policy, is to make = sure that the dssc policy is acceptable or is correct.

Applying the maintenance policy is taking into consideration the dssc policy as indicated.

There is however a point where we are in = agreement, since you said:

“ Policy/policies inclusion reminds me on = the AESs and their references to singing policies and
I am not really sure whether the basic ERs structure (ASN.1 or XML) is = to support that.

However I do agree this is a very important issue = but it brings us to a crossroad of policies
that may be part of the ERS structure. For example, the ERS system might operate per different policies,”

The basic question is whether the maintenance = policies should or should not be part of the structure.
However, at this time this element cannot be included. A compromise = would be to consider the maintenance
policy as an optional element.

[Denis]

I said earlier:

As the document does not sufficiently deal with = the verification of the data structure, the case of TSU compromise
is not sufficiently addressed.=A0 In short, if when applying a new TST, = the TSU certificate is marked as revoked,
this is not a problem if the revocation reason is anything else than "compromise".=A0 If the revocation reason
is "compromise", then the text should say what to do (or what = should have been done earlier).

You replied:

I can't agree here. Consequences of revocation = event (whatever the reason) might vary according to policies
(even legislation) and therefore I see no reason to go into details. As = Tobias explained, the draft addresses
the problem of loosing validity of TST in general (or TSU for whatever = reason) and proposes general measures
to avoid that. TSA redundancy is one of the solutions which, however, = only reduces the risk of evidences
decomposition in the future. One can consider other countermeasures, but = the draft is not there to address all of them.

Maybe my explanations were not sufficient. Let me = state again why there is a security hole in the current = description.

When a new TST is applied, it MUST be proven that = at the time the new TST is applied the certificate of the TSU
was not revoked due to a key compromise. If the revocation is for “cessation of activity” this is not a problem,
since in that case the private key of the TSU has been previously = destroyed and thus cannot be used nor compromised
anymore.

[Carl] I = disagree, for reasons you have cited in the past.=A0 There will always be a grace = period applied at validation time so this “MUST be proven at the time the = new TST is applied” cannot be true.=A0 In any case, these sorts of = issues are for the relying party to appraise and the policies used by relying = parties may vary, hence DSSC need not be included.=A0

The document is lacking to address this major = issue. This is also due to the fact that the document is providing
a static description of the data structure and does not sufficiently = address the use of the data structure.

[Carl] This = neatly summarizes the situation.=A0 The XMLERS format does not address the use = relative to crypto policy.=A0 Fortunately, it does not need to as DSSC addresses = this.=A0 Each and every evidence record need not carry around this DSSC policy as = the relying party can maintain a copy of the policy it wishes to use when validating an evidence record.=A0

This aspect should be addressed both in the main = body of the document and in the security considerations section.
If not, my position is the following: the document, as it is, should not = be published as an RFC on the Standards Track.

[Carl] A = security consideration on this topic seems like a reasonable thing to do.=A0 = Tobias, can you add a security consideration to address the separation of evidence = record from policy?=A0 I think that will close this = issue.

 

Denis

----- Message re=E7u -----

Date : 2010-10-08, 17:52:10

Sujet : Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt

 <= /o:p>

It appears that the issues have been satisfactorily addressed. We'll = proceed with sending this draft to the AD early next week.

> -----Original Message-----
> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf
> Of Tobias Gondrom
> Sent: Saturday, September 25, 2010 2:26 PM
> To: ltans@ietf.org
> Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
>
> I basically agree with Aljosa. More detailed answers in line
> - Tobias
>
>
> On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote:
> > Denis, Tobias
> >
> > It took me a while to get back to XMLERS and my answers are in = line.
> >
> >> -----Original Message-----
> >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On
> Behalf
> >> Of Denis Pinkas
> >> Sent: September 14, 2010 12:34
> >> To: ltans
> >> Subject: Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt
> >>
> >> Tobias,
> >>
> >> See responses in line.
> >>
> >> Denis
> >>
> >> ----- Message re=E7u -----
> >> De : ltans-bounces
> >> =C0 : ltans
> >> Date : 2010-09-13, 19:38:14
> >> Sujet : Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt
> >>
> >> Hi Denis,
> >> yes the response is a bit late, but as we still have IETF = LC
> >> ahead, not too late.
> >> Based on Carl's decision we may discuss and resolve this = here
> >> while the draft proceeds to IESG and IETF LC.
> >> Answers inline.
> >>
> >> Kind regards, Tobias
> >>
> >>
> >> On 09/13/2010 04:48 PM, Denis Pinkas wrote:
> >>
> >> This is a late response.
> >>
> >> Comments on draft-ietf-ltans-xmlers-07
> >>
> >> 1) The abstract from this draft states:
> >>
> >> In many scenarios, users must be able to demonstrate = the
> >> (time)
> >> existence, integrity and validity of data including
> >> signed data for
> >> long or undetermined period of time. This document
> >> specifies XML
> >> syntax and processing rules for creating evidence for
> >> long-term non-
> >> repudiation of existence of data.
> >>
> >> The abstract from RFC 4998, which is very similar, = states:
> >>
> >> In many scenarios, users must be able prove the
> >> existence and
> >> integrity of data, including digitally signed data, in = a
> >> common and
> >> reproducible way over a long and possibly undetermined
> >> period of
> >> time. This document specifies the syntax and = processing
> >> of an
> >> Evidence Record, a structure designed to support long-
> >> term non-
> >> repudiation of existence of data.
> >>
> >> Then an additional sentence in the draft states:
> >>
> >> ERS-XML incorporates alternative syntax and processing
> >> rules to ASN.1 ERS syntax
> >> by using XML language.
> >>
> >> The basic question is why an addendum has not been added = to
> >> RFC 4998 to include
> >> an XML syntax, equivalent to the ASN.1.
> >>
> >> Some explanations are given on page 7 are not = convincing:
> >>
> >> Due to the differences in XML processing rules and = other
> >> characteristics of XML language, XMLERS does not = present
> >> a direct
> >> transformation of ERS in ASN.1 syntax. The XMLERS = syntax
> >> is based on
> >> different processing rules as defined in [RFC4998] and
> >> it does not
> >> support for example import of ASN.1 values in XML = tags.
> >> Creating
> >> Evidence Records in XML syntax must follow the steps = as
> >> defined in
> >> this draft. XMLERS is a standalone draft and is based = on
> >> [RFC4998]
> >> conceptually only.
> >>
> >> The text omits to highlight what the differences are.
> >>
> >> For example, ERS states:
> >>
> >> The data (e.g. certificates, Certificate Revocation
> >> Lists (CRLs), or
> >> Online Certificate Status Protocol (OCSP) responses)
> >> needed to verify
> >> the timestamp MUST be preserved, and SHOULD be stored = in
> >> the
> >> timestamp itself unless this causes unnecessary
> >> duplication.
> >>
> >> While the draft states:
> >>
> >> An ATS contains a Time-Stamp Token and optionally = other
> >> useful
> >> data for Time-Stamp validation, e.g. certificates, = CRLs
> >> or OCSP
> >> responses
> >>
> >> In one case CRLs should be part of the TST, while in = the
> >> other case it should be
> >> external to the TST.
> >>
> >> Section 1.1 should be revised to mention the = differences
> >> with a rational about them.
> >>
> >>
> >>
> >> In theory we could have added XMLERS to ERS, but XML = puts
> >> different processing issues to the document,
> >> for example the ordering problem of the XML elements (to = always
> >> produce identical hash values
> >> for the same data structure). XMLERS required further = explanation
> >> regarding these processing rules and
> >> a well-thought XML structure, plus identifiers to be = assigned by
> >> IANA for certain types. All these items are not
> >> related to ERS or its ASN.1 structure and would have made = the RFC
> >> unnecessarily complex to read while
> >> bringing not much benefit.
> >>
> >> So a lot of reasons to put this in a separate draft, and = not much
> >> harm from doing so.
> > I support Tobias comments as the benefit of expanding = ASN.1
> recommendation with additional XML based structure and processing = rules
> would make the whole RFC unreadable. The intention of separate
> specifications is to have one's decision on implementation type, = i.e.
> ASN.1 vs XML. Section 1.1. can be further revised to support = these
> facts.
> >> [Denis] I am requesting to add further information to = section 1.1.
> so
> >> that people may understand better why there has been no translation
> of
> >> the ASN.1 into XML.
> [Tobias]: I find section 1.1 as it is totally satisfactory = regarding
> reasons and explanations. Adding further reasons is redundant. = However
> as opinions can obviously deviate on this matter, maybe you = could
> provide reasons for why you feel this additional paragraph is = needed to
> understand the RFC better and maybe give some indication on how = much
> information you think would be needed (as I would like to keep it = as
> concise as possible)? Would a short three-line paragraph based on = my
> initial answer to your comment satisfy your request to further
> information?
>
> >> 2) Page 43 states:
> >>
> >> A generic solution for automatic interpretation of
> >> security suitability
> >> policies in electronic form is not the subject of this
> >> specification.
> >>
> >> It is a copy and paste of the same text which existed = in
> >> RFC 4998.
> >>
> >> However, this document omits to take into consideration = RFC
> >> 5698 which has been issued
> >> in November 2009 (Data Structure for the Security
> >> Suitability of Cryptographic Algorithms
> >> - DSSC) and which respond to the problem raised.
> >>
> >> While it is normal that the concept was not supported = in
> >> August 2007 when ERS was published,
> >> it is abnormal that the problems highlighted in RFC = 5698
> >> are not covered by this draft. In order to
> >> demonstrate that an algorithm was not weak, it is useful = to
> >> include a data structure that lists the
> >> weak algorithms at a given point of time. This is what = RFC
> >> 5698 allows.
> >>
> >> In any case, the text from section 7 (page 43) needs to = be
> >> updated.
> >>
> >>
> >>
> >> Thank you, I missed that. I agree. We definitely should = refer to
> >> RFC5698 as a method that may be used and add it to the informative
> >> references.
> >>
> >>
> >> [Denis] In fact , I am asking more that simply making a = reference to
> >> RFC 5698, but to be able to include some structures = defined in RFC
> 5698
> >> into XMLERS. RFC 5698 should then be in the normative = references.
> Hm, I can not see the value of adding used dssc policy data to = the
> Evidence Records beyond anecdotal interest.
> DSSC was intended to support the operation of a LTA (i.e. help = decide
> when to do which renewal processes) and verification clients to
> automatically process policies (about which algorithms were valid = for
> which time spans).
> All evidence in an evidence record is based on the used algorithms = and
> the external TSA as a trust anchor.
> So, although it may be interesting to see which policies the = archive
> did
> use during its operation, this must not influence the future
> verification of the signatures and evidence records.
> (Consider the following case: a verification client in 2020 = operates
> based on a dssc policy that declares that e.g. SHA-1 was valid = until
> 2012 and that all hashes thereafter must be done by SHA-256 or = higher.
> What difference would it make if the LTA would include into the
> Evidence
> Record its own policies stating that it believed SHA-1 was valid = until
> 2015? The verification client would still have to follow its own = dssc
> policy data for the verification and must ignore this data provided = by
> the LTA. Remember: a LTA is not trusted by itself, but relies on = the
> TSA
> as a trust anchor for its evidence records.)
>
> Thus, I can not see the value of DSSCs data provided with = Evidence
> Records.
>
> If you could provide a scenario where this data is valuable, the = best
> way to integrate dssc data it into the structure would be in the = form
> of
> a "Cryptographic Information Type" with its own = identifier (in which
> case you would be right and we would have to move the reference to = the
> normative section).
>
> >> 3) The most important concern is the following one : = there
> >> is no rule in the document to explain
> >> how to really verify a given ERS-XML structure. Which = root
> >> keys need to be used to verify one structure ?
> >> Which rules to apply to verify an ERS-XML data = structure
> >> that is 30 years old ? The notion of multiple
> >> validation policies should be supported, since = validation
> >> policies that will exist 30 years from now are still = unknown.
> >>
> >> Having a data structure is fine, but it is insufficient = to
> >> allow interoperability.
> >>
> >> The data structure should be able to reference the
> >> validation policy used at each TST addition.
> >> The current data structure is unable to support the
> >> verification of an ERS-XML data structure that is 30 years = old.
> >>
> >> Unless verification rules are explained in detail, = this
> >> document will not achieve its goal and will not be = practically
> usable.
> >>
> >>
> >>
> >> Verification rules may be different for different = legislation and
> >> countries and as you pointed out may even evolve over = time.
> >> A problem true for all signatures (be it certs, = timestamps, etc.)
> >> and not for XMLERS alone required to determine.
> >> The draft (as with ERS) is based on the fact that all = reasonable
> >> validation data is stored and preserved
> >> (e.g. by also using XMLERS/ERS or integrating into the = timestamp
> >> structures) and is validated based on the policy
> >> at the time of the validation in the future. So a = different
> >> validation policy at each TST addition is not significant = for the
> >> future validation.
> >>
> >> [Denis] We are in strong disagreement here.
> >>
> >> Let us use a example. A TST is renewed every 10 years.
> >>
> >> After ten years, I apply what a would call an = "algorithm maintenance
> >> policy" and I reference the OID/URN
> >> from that policy before applying new TST, a certification = path and
> CRLs
> >> captured at that time which demonstrate
> >> that the TSU certificate from the earlier TST has not been revoked.
> >>
> >> In order to verify the structure, I first look at the = OID/URN from
> the
> >> "algorithm maintenance policy" and if I find it acceptable,
> >> I apply the rules of the policy.
> >>
> >> Ten years later, I choose another "algorithm = maintenance policy" and
> I
> >> reference the OID/URN
> >> from that policy before applying new TST, a certification = path and
> CRLs
> >> captured at that time which demonstrate
> >> that the TSU certificate from the earlier TST has not been revoked.
> >>
> >> In order to verify the structure, I first look at the = OID/URN from
> >> inner "algorithm maintenance policy" and if I = find it acceptable,
> >> I apply the rules of the policy. Then I look at the = OID/URN from
> outer
> >> "algorithm maintenance policy" and if I find it acceptable,
> >> I apply the rules of the policy.
> >>
> >> There is not a global verification, but a verification = that is
> >> different at each step.
> >>
> >> The implication is to add to the current structure a new = field to
> >> indicate the OID/URN of the "algorithm maintenance policy"
> >> that has been used for that step.
> Yes we are in disagreement, though am not sure about the root of = it.
> Our
> disagreement may result from a number things:
> First, verification of all individual timestamps inside an = evidence
> record (i.e. in the Archive time stamps) follow the same = verification
> rules as if you would use to verify them seen atomic (one by = one)
> (based
> on the time of the following renewal).
> Second, there may be misunderstanding of the role of a LTA: as
> specified
> in 4810 and 4998, the security of the provided evidence records = relies
> on the cryptographic algorithms and a TSA as a trust anchor (there = is
> not need to e.g. certify a LTA itself as a trusted entity as well, = at
> least not for the validity of evidence records).
> Therefore the applied policies must be appropriate for future
> verifications to succeed, but this depends on the legal = requirements of
> what verification data is required for the used timestamps (which = may
> vary based on what type of TSA is used (e.g. how long it is = guaranteed
> to provide certificates and other verification data) and other = means.
> Third, the example I outlined at #2 may also help to understand why = a
> field "field to indicate the OID/URN of the "algorithm maintenance
> policy"" does not add value.
>
> > If I understand your comments correctly, what you are = referring to is
> audit trail on the decision making process of time stamp = renewal.
> Policy/policies inclusion reminds me on the AESs and their = references
> to singing policies and I am not really sure whether the basic = ERs
> structure (ASN.1 or XML) is to support that. However I do agree = this is
> a very important issue but it brings us to a crossroad of policies = that
> may be part of the ERS structure. For example, the ERS system = might
> operate per different policies, also the organizational perspective = of
> the evidence system may have implication on generation and = maintenance
> of preservation evidences (which again might be a sub-element of = much
> broader electronic data preservation policies).
> >
> >> Note: if we add this information to XMLERS, it would make = sense to
> do
> >> the same for ERS.
> >>
> >> So a different validation policy at each TST addition is = not
> >> significant for the future validation. Even if it might = be
> interesting,
> >> the key decision making unit will be the validation at the = future
> >> point (e.g. in 30 years) and not what policies the = system
> >> might have found appropriate at the time of timestamp = renewals.
> >>
> >> On a personal note: I started an individual draft
> >> http= s://datatracker.ietf.org/doc/draft-ietf-ltans-validate/ about
> >> validation
> >> and necessary data. It is still very early stage work in = progress
> >> (as I wanted to wait for XMLERS to finish first)
> >> and I find the procedures to be probably quite = controversial. So
> >> the draft will not be continued in the LTANS WG
> >> but submitted only as an individual informational ID. (If = you
> >> don't mind, I'd actually like to come back to you on = that
> >> and ask you for your input on it once I have refined it in = a few
> >> weeks time)
> >>
> >> [Denis] Thank you for the information. Until we solve the previous
> >> point, it is likely that we will be in disagreement.
> >>
> >> However, this illustrates the fact that without = addtional
> information
> >> on how to use and verify the data structure,
> >> the current XMLERS draft is not usable in practice (i.e. = there is no
> >> interoperability).
> No. XMLERS follows ERS in this regard and ERS is absolutely usable = in
> practice (best proof for that is that it is effectively used by = a
> number
> of systems today).
> To provide further explanation a bit more: Today, LTA operators = usually
> get some operational or legal advice to which verification data = is
> required and based on that integrate this into the structures = (based
> e.g. on the retention time of the data and the times of = guaranteed
> availability of verification data). E.g. a LTA operator may store = data
> that is kept only for 10 years, while the TSA (and even CAs for
> signatures in stored documents) it uses has a government = certification
> (guarantee) to keep verification data available for 30 years. (In = which
> case he may not be legally bound to store that data.)
>
>
> > Then this implies to ERS also.
>
> >> 4) The text omits to consider how to deal with the risk = of
> >> TSU key compromission and what to do if a given
> >> TSU key has been compromised.
> >>
> >> As I understand it, TSU key compromission would lead = to
> >> revocation of its certificate and loss of validity.
> >> The draft talks about that, i.e. a Time-stamp renewal.
> >>
> >> However note, as such timestamp renewal would have to be = done
> >> timely (and actually before TS looses its validity,
> >> there can be problems with cases of late discoveries of = such TSU
> >> compromissions. With this possibility in mind
> >> it is recommended to use two redundant XMLERS with = timestamps
> >> from different timestamp authorities.
> >> (see section 7 Security Considerations)
> >>
> >> As the detailed valuation of such events and legal = requirements
> >> may vary by country, it seemed prudent to describe = things
> >> up to the current level but not further.
> >>
> >> [Denis] As the document does not sufficiently deal with = the
> >> verification of the data structure, the case of TSU = compromission
> >> is not sufficiently addressed.
> >>
> >> In short, if when applying a new TST, the TSU certificate = is marked
> as
> >> revoked, this is not a problem if the revocation = reason
> >> is anything else than "compromise".
> >>
> >> If the revocation reason is "compromise", then = the text should say
> what
> >> to do (or what should have been done earlier).
> > I can't agree here. Consequences of revocation event (whatever = the
> reason) might vary according to policies (even legislation) and
> therefore I see no reason to go into details. As Tobias explained, = the
> draft addresses the problem of loosing validity of TST in general = (or
> TSU for whatever reason) and proposes general measures to avoid = that.
> TSA redundancy is one of the solutions which, however, only reduces = the
> risk of evidences decomposition in the future. One can consider = other
> countermeasures, but the draft is not there to address all of = them.
>
> I fully agree with Aljosa's argument (and disagree with you = Denis).
>
> Tobias
>
>
>
> > Aljosa
> >
> >> Once again the data structure is described, but there = is
> unsufficient
> >> guidance on how to use it and check it.
> >>
> >> Denis
> >>
> >> Denis
> >>
> >> ----- Message re=E7u -----
> >> De : ltans-bounces
> >> =C0 : ltans
> >> Date : 2010-08-23, 21:08:54
> >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-
> >> xmlers-07.txt
> >>
> >> Working group last call for this draft will begin
> >> today and end on
> >> September 7th. Shortly after this draft completes
> >> IESG processing the
> >> working group will close, as noted during the meeting
> >> last month.
> >>
> >> > -----Original Message-----
> >> > From: ltans-bounces@ietf.org <mailto:%20ltans-
> >> bounces@ietf.org> [mailto:ltans-bounces@ietf.org <mailto:%20ltans-
> >> bounces@ietf.org> ] On Behalf
> >> > Of Internet-Drafts@ietf.org <mailto:%20Internet-
> >> Drafts@ietf.org>
> >> > Sent: Monday, August 23, 2010 2:00 PM
> >> > To: i-d-announce@ietf.org <mailto:%20i-d-
> >> announce@ietf.org>
> >> > Cc: ltans@ietf.org <mailto:%20ltans@ietf.org>
> >> > Subject: [ltans] I-D ACTION:draft-ietf-ltans-
> >> xmlers-07.txt
> >> >
> >> > A New Internet-Draft is available from the = on-line
> >> Internet-Drafts
> >> > directories.
> >> > This draft is a work item of the Long-Term = Archive
> >> and Notary Services
> >> > Working Group of the IETF.
> >> >
> >> > Title : Extensible Markup Language Evidence = Record
> >> Syntax
> >> > Author(s) : A. Blazic, S. Saljic, T. Gondrom
> >> > Filename : draft-ietf-ltans-xmlers-07.txt
> >> > Pages : 53
> >> > Date : 2010-8-23
> >> >
> >> > In many scenarios, users must be able to
> >> demonstrate the (time)
> >> > existence, integrity and validity of data = including
> >> signed data for
> >> > long or undetermined period of time. This = document
> >> specifies XML
> >> > syntax and processing rules for creating evidence
> >> for long-term
> >> non-
> >> > repudiation of existence of data. ERS-XML
> >> incorporates alternative
> >> > syntax and processing rules to ASN.1 ERS syntax = by
> >> using XML
> >> > language.
> >> >
> >> > A URL for this Internet-Draft is:
> >> > http://www.ietf.= org/internet-drafts/draft-ietf-
> >> ltans-xmlers-07.txt
> >> >
> >> > Internet-Drafts are also available by anonymous = FTP
> >> at:
> >> > ftp://ftp.ietf.org/internet-drafts/
> >> >
> >> > Below is the data which will enable a MIME
> >> compliant mail reader
> >> > implementation to automatically retrieve the = ASCII
> >> version of the
> >> > Internet-Draft.
> >> >
> >> >
> >> >
> >>
> = ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs
> >> Email Security System.
> >> > For more information please visit
> >> http://www.messagelabs.com/emai= l
> >> >
> >>
> = ______________________________________________________________________ > >> _______________________________________________
> >> ltans mailing list
> >> ltans@ietf.org <mailto:%20ltans@ietf.org>
> >> https://www.ietf.org= /mailman/listinfo/ltans
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> ltans mailing list
> >> ltans@ietf.org
> >> https://www.ietf.org= /mailman/listinfo/ltans
> >>
> > _______________________________________________
> > ltans mailing list
> > ltans@ietf.org
> > https://www.ietf.org= /mailman/listinfo/ltans
>
> _______________________________________________
> ltans mailing list
> ltans@ietf.org
> https://www.ietf.org= /mailman/listinfo/ltans
_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org= /mailman/listinfo/ltans

------_=_NextPart_001_01CB6ACC.461E4041-- From denis.pinkas@bull.net Mon Oct 18 04:39:35 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316C83A6D99 for ; Mon, 18 Oct 2010 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.323 X-Spam-Level: *** X-Spam-Status: No, score=3.323 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_56=0.6, J_CHICKENPOX_75=0.6, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLD+QDRPU3Tq for ; Mon, 18 Oct 2010 04:39:30 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 96FB83A6D9A for ; Mon, 18 Oct 2010 04:39:06 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 2AA6B180D3 for ; Mon, 18 Oct 2010 13:46:48 +0200 (CEST) Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010101813403369:86826 ; Mon, 18 Oct 2010 13:40:33 +0200 From: "Denis Pinkas" To: "ltans" Date: Mon, 18 Oct 2010 13:40:22 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 18/10/2010 13:40:33, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 18/10/2010 13:40:34, Serialize complete at 18/10/2010 13:40:34 Content-Type: multipart/alternative; boundary="----=_NextPart_10101813401774576506024_002" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 11:39:35 -0000 ------=_NextPart_10101813401774576506024_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Carl, 1 - You said: [Carl] DSSC applies at validation time. I agree with Tobias that while o= ne could package the policy=20 with a data item it is not necessary. It doesn=92t really matter what po= licy the LTA had in mind. =20 What matters is that the evidence record passes the policy used by the re= lying party. =20 I see no reason to make a change to include DSSC policy in the XMLERS for= mat. Let us make a comparison with the concept of signature policy. Electronic sigantures comes with two flavors: BES (Basic ES) and EPES (Ex= plicit Policy ES). In EPES, the signature policy is indicated. My request is to be able to i= ncorporate the maintenance policy, like in EPES. You say you don't need it, like in BES. So let us make it OPTIONAL, which= means that it will be possible to place it=20 in the structure, whereas it is not the case today. 2 - You said: [Carl] I disagree, for reasons you have cited in the past. There will al= ways be a grace period applied at validation time=20 so this =93MUST be proven at the time the new TST is applied=94 cannot be= true. In any case, these sorts of issues=20 are for the relying party to appraise and the policies used by relying pa= rties may vary, hence DSSC need not be included. When you consider a grace period, the TST on the previous data can be app= lied first and the CRL for the previous TST=20 captured, e.g. 24 hours later. The DSCC information used at that time should also be added to the struct= ure, before the new TST is applied. In this way, it will be possible to split the overall verification by doi= ng two sequences of verifications in any order: a) verifying the whole structure, making the assumption that every DSCC i= nformation that has been used is correct, and b) verifying that every DSCC information placed in the structure comes fr= om a reliable source and was correct=20 at the time indicated in the associated TST. The advantage is that check a) can be fully automated. 3 - You said: [Carl] A security consideration on this topic seems like a reasonable thi= ng to do. Tobias, can you add a security consideration=20 to address the separation of evidence record from policy? I think that w= ill close this issue. Addressing the issue in the security considerations is fine. However, cha= nges in the main body of the document are still necessary. Denis ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : denis.pinkas,tobias.gondrom,ltans=20 Date : 2010-10-13, 13:46:28 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt Responses inline (as best I can given strange likely inconsistent tagging= of who said what)=85 From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of= Denis Pinkas Sent: Tuesday, October 12, 2010 9:20 AM To: tobias.gondrom; ltans Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt I wonder in which phase we are: still in the resolution of the comment ra= ised in the WG last call ? Anyway, I don't believe that the issues I raised have been satisfactorily= addressed. [Tobias] Hm, I can not see the value of adding used dssc policy data to=20 the Evidence Records beyond anecdotal interest. DSSC was intended to support the operation of a LTA (i.e. help decide whe= n to do=20 which renewal processes) and verification clients to automatically proces= s policies=20 (about which algorithms were valid for which time spans). All evidence in= an evidence record=20 is based on the used algorithms and the external TSA as a trust anchor. S= o, although=20 it may be interesting to see which policies the archive did use during it= s operation,=20 this must not influence the future verification of the signatures and evi= dence records.=20 [Denis] You said: =93it MAY be interesting to see which policies the arch= ive did use during its operation=94.=20 I would rather say: =93it is MANDATORY to know which [maintenance] polici= es have been applied=20 to the archive even time a new TST has been added. The problem is that, at the minimum, there should be an identifier of the= maintenance policy=20 that has been used (which is not the case in the present document). This = will of course influence=20 the future verification of the TST since the maintenance policy used for = each step (if found acceptable)=20 will have to be used.=20 [Carl] DSSC applies at validation time. I agree with Tobias that while o= ne could package the policy with a data item it is not necessary. It doe= sn=92t really matter what policy the LTA had in mind. What matters is th= at the evidence record passes the policy used by the relying party. I se= e no reason to make a change to include DSSC policy in the XMLERS format. [Tobias] Consider the following case: a verification client in 2020 operates based= on a dssc policy that=20 declares that e.g. SHA-1 was valid until 2012 and that all hashes thereaf= ter must be done by SHA-256=20 or higher. What difference would it make if the LTA would include into th= e Evidence Record its own policies=20 stating that it believed SHA-1 was valid until 2015? The verification cli= ent would still have to follow its own=20 dssc policy data for the verification and must ignore this data provided = by the LTA. Thus, I can not see the value of DSSCs data provided with Evidence Record= s. If you could provide a scenario=20 where this data is valuable, the best way to integrate dssc data it into = the structure would be in the form=20 of a "Cryptographic Information Type" with its own identifier (in which c= ase you would be right and we=20 would have to move the reference to the normative section). [Denis] Here is the scenario: for each step, the dssc policy (which is pa= rt of the maintenance policy) MUST be=20 indicated. The verification process is a two steps process which may be p= erformed in any order: 1) evaluate the maintenance policy,=20 2) apply the maintenance policy. Evaluating the maintenance policy, is to make sure that the dssc policy i= s acceptable or is correct.=20 Applying the maintenance policy is taking into consideration the dssc pol= icy as indicated. There is however a point where we are in agreement, since you said: =93 Policy/policies inclusion reminds me on the AESs and their references= to singing policies and=20 I am not really sure whether the basic ERs structure (ASN.1 or XML) is to= support that.=20 However I do agree this is a very important issue but it brings us to a c= rossroad of policies=20 that may be part of the ERS structure. For example, the ERS system might = operate per different policies,=94 The basic question is whether the maintenance policies should or should n= ot be part of the structure.=20 However, at this time this element cannot be included. A compromise would= be to consider the maintenance=20 policy as an optional element.=20 [Denis]=20 I said earlier: As the document does not sufficiently deal with the verification of the d= ata structure, the case of TSU compromise=20 is not sufficiently addressed. In short, if when applying a new TST, the= TSU certificate is marked as revoked,=20 this is not a problem if the revocation reason is anything else than "com= promise". If the revocation reason=20 is "compromise", then the text should say what to do (or what should have= been done earlier).=20 You replied: I can't agree here. Consequences of revocation event (whatever the reason= ) might vary according to policies=20 (even legislation) and therefore I see no reason to go into details. As T= obias explained, the draft addresses=20 the problem of loosing validity of TST in general (or TSU for whatever re= ason) and proposes general measures to avoid that. TSA redundancy is one of the solutions which, however, onl= y reduces the risk of evidences=20 decomposition in the future. One can consider other countermeasures, but = the draft is not there to address all of them. Maybe my explanations were not sufficient. Let me state again why there i= s a security hole in the current description. When a new TST is applied, it MUST be proven that at the time the new TST= is applied the certificate of the TSU=20 was not revoked due to a key compromise. If the revocation is for =93cess= ation of activity=94 this is not a problem,=20 since in that case the private key of the TSU has been previously destroy= ed and thus cannot be used nor compromised=20 anymore.=20 [Carl] I disagree, for reasons you have cited in the past. There will al= ways be a grace period applied at validation time so this =93MUST be prov= en at the time the new TST is applied=94 cannot be true. In any case, th= ese sorts of issues are for the relying party to appraise and the policie= s used by relying parties may vary, hence DSSC need not be included. =20 The document is lacking to address this major issue. This is also due to = the fact that the document is providing=20 a static description of the data structure and does not sufficiently addr= ess the use of the data structure. [Carl] This neatly summarizes the situation. The XMLERS format does not = address the use relative to crypto policy. Fortunately, it does not need= to as DSSC addresses this. Each and every evidence record need not carr= y around this DSSC policy as the relying party can maintain a copy of the= policy it wishes to use when validating an evidence record. =20 This aspect should be addressed both in the main body of the document and= in the security considerations section.=20 If not, my position is the following: the document, as it is, should not = be published as an RFC on the Standards Track. [Carl] A security consideration on this topic seems like a reasonable thi= ng to do. Tobias, can you add a security consideration to address the se= paration of evidence record from policy? I think that will close this is= sue. Denis ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : Tobias Gondrom,ltans=20 Date : 2010-10-08, 17:52:10 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt It appears that the issues have been satisfactorily addressed. We'll proc= eed with sending this draft to the AD early next week.=20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of Tobias Gondrom > Sent: Saturday, September 25, 2010 2:26 PM > To: ltans@ietf.org > Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt >=20 > I basically agree with Aljosa. More detailed answers in line > - Tobias >=20 >=20 > On 09/25/2010 02:19 PM, Aljosa Jerman Blazic wrote: > > Denis, Tobias > > > > It took me a while to get back to XMLERS and my answers are in line. > > > >> -----Original Message----- > >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On > Behalf > >> Of Denis Pinkas > >> Sent: September 14, 2010 12:34 > >> To: ltans > >> Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Tobias, > >> > >> See responses in line. > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-09-13, 19:38:14 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > >> > >> Hi Denis, > >> yes the response is a bit late, but as we still have IETF LC > >> ahead, not too late. > >> Based on Carl's decision we may discuss and resolve this here > >> while the draft proceeds to IESG and IETF LC. > >> Answers inline. > >> > >> Kind regards, Tobias > >> > >> > >> On 09/13/2010 04:48 PM, Denis Pinkas wrote: > >> > >> This is a late response. > >> > >> Comments on draft-ietf-ltans-xmlers-07 > >> > >> 1) The abstract from this draft states: > >> > >> In many scenarios, users must be able to demonstrate the > >> (time) > >> existence, integrity and validity of data including > >> signed data for > >> long or undetermined period of time. This document > >> specifies XML > >> syntax and processing rules for creating evidence for > >> long-term non- > >> repudiation of existence of data. > >> > >> The abstract from RFC 4998, which is very similar, states: > >> > >> In many scenarios, users must be able prove the > >> existence and > >> integrity of data, including digitally signed data, in a > >> common and > >> reproducible way over a long and possibly undetermined > >> period of > >> time. This document specifies the syntax and processing > >> of an > >> Evidence Record, a structure designed to support long- > >> term non- > >> repudiation of existence of data. > >> > >> Then an additional sentence in the draft states: > >> > >> ERS-XML incorporates alternative syntax and processing > >> rules to ASN.1 ERS syntax > >> by using XML language. > >> > >> The basic question is why an addendum has not been added to > >> RFC 4998 to include > >> an XML syntax, equivalent to the ASN.1. > >> > >> Some explanations are given on page 7 are not convincing: > >> > >> Due to the differences in XML processing rules and other > >> characteristics of XML language, XMLERS does not present > >> a direct > >> transformation of ERS in ASN.1 syntax. The XMLERS syntax > >> is based on > >> different processing rules as defined in [RFC4998] and > >> it does not > >> support for example import of ASN.1 values in XML tags. > >> Creating > >> Evidence Records in XML syntax must follow the steps as > >> defined in > >> this draft. XMLERS is a standalone draft and is based on > >> [RFC4998] > >> conceptually only. > >> > >> The text omits to highlight what the differences are. > >> > >> For example, ERS states: > >> > >> The data (e.g. certificates, Certificate Revocation > >> Lists (CRLs), or > >> Online Certificate Status Protocol (OCSP) responses) > >> needed to verify > >> the timestamp MUST be preserved, and SHOULD be stored in > >> the > >> timestamp itself unless this causes unnecessary > >> duplication. > >> > >> While the draft states: > >> > >> An ATS contains a Time-Stamp Token and optionally other > >> useful > >> data for Time-Stamp validation, e.g. certificates, CRLs > >> or OCSP > >> responses > >> > >> In one case CRLs should be part of the TST, while in the > >> other case it should be > >> external to the TST. > >> > >> Section 1.1 should be revised to mention the differences > >> with a rational about them. > >> > >> > >> > >> In theory we could have added XMLERS to ERS, but XML puts > >> different processing issues to the document, > >> for example the ordering problem of the XML elements (to always > >> produce identical hash values > >> for the same data structure). XMLERS required further explanation > >> regarding these processing rules and > >> a well-thought XML structure, plus identifiers to be assigned by > >> IANA for certain types. All these items are not > >> related to ERS or its ASN.1 structure and would have made the RFC > >> unnecessarily complex to read while > >> bringing not much benefit. > >> > >> So a lot of reasons to put this in a separate draft, and not much > >> harm from doing so. > > I support Tobias comments as the benefit of expanding ASN.1 > recommendation with additional XML based structure and processing rules > would make the whole RFC unreadable. The intention of separate > specifications is to have one's decision on implementation type, i.e. > ASN.1 vs XML. Section 1.1. can be further revised to support these > facts. > >> [Denis] I am requesting to add further information to section 1.1. > so > >> that people may understand better why there has been no translation > of > >> the ASN.1 into XML. > [Tobias]: I find section 1.1 as it is totally satisfactory regarding > reasons and explanations. Adding further reasons is redundant. However > as opinions can obviously deviate on this matter, maybe you could > provide reasons for why you feel this additional paragraph is needed to > understand the RFC better and maybe give some indication on how much > information you think would be needed (as I would like to keep it as > concise as possible)? Would a short three-line paragraph based on my > initial answer to your comment satisfy your request to further > information? >=20 > >> 2) Page 43 states: > >> > >> A generic solution for automatic interpretation of > >> security suitability > >> policies in electronic form is not the subject of this > >> specification. > >> > >> It is a copy and paste of the same text which existed in > >> RFC 4998. > >> > >> However, this document omits to take into consideration RFC > >> 5698 which has been issued > >> in November 2009 (Data Structure for the Security > >> Suitability of Cryptographic Algorithms > >> - DSSC) and which respond to the problem raised. > >> > >> While it is normal that the concept was not supported in > >> August 2007 when ERS was published, > >> it is abnormal that the problems highlighted in RFC 5698 > >> are not covered by this draft. In order to > >> demonstrate that an algorithm was not weak, it is useful to > >> include a data structure that lists the > >> weak algorithms at a given point of time. This is what RFC > >> 5698 allows. > >> > >> In any case, the text from section 7 (page 43) needs to be > >> updated. > >> > >> > >> > >> Thank you, I missed that. I agree. We definitely should refer to > >> RFC5698 as a method that may be used and add it to the informative > >> references. > >> > >> > >> [Denis] In fact , I am asking more that simply making a reference to > >> RFC 5698, but to be able to include some structures defined in RFC > 5698 > >> into XMLERS. RFC 5698 should then be in the normative references. > Hm, I can not see the value of adding used dssc policy data to the > Evidence Records beyond anecdotal interest. > DSSC was intended to support the operation of a LTA (i.e. help decide > when to do which renewal processes) and verification clients to > automatically process policies (about which algorithms were valid for > which time spans). > All evidence in an evidence record is based on the used algorithms and > the external TSA as a trust anchor. > So, although it may be interesting to see which policies the archive > did > use during its operation, this must not influence the future > verification of the signatures and evidence records. > (Consider the following case: a verification client in 2020 operates > based on a dssc policy that declares that e.g. SHA-1 was valid until > 2012 and that all hashes thereafter must be done by SHA-256 or higher. > What difference would it make if the LTA would include into the > Evidence > Record its own policies stating that it believed SHA-1 was valid until > 2015? The verification client would still have to follow its own dssc > policy data for the verification and must ignore this data provided by > the LTA. Remember: a LTA is not trusted by itself, but relies on the > TSA > as a trust anchor for its evidence records.) >=20 > Thus, I can not see the value of DSSCs data provided with Evidence > Records. >=20 > If you could provide a scenario where this data is valuable, the best > way to integrate dssc data it into the structure would be in the form > of > a "Cryptographic Information Type" with its own identifier (in which > case you would be right and we would have to move the reference to the > normative section). >=20 > >> 3) The most important concern is the following one : there > >> is no rule in the document to explain > >> how to really verify a given ERS-XML structure. Which root > >> keys need to be used to verify one structure ? > >> Which rules to apply to verify an ERS-XML data structure > >> that is 30 years old ? The notion of multiple > >> validation policies should be supported, since validation > >> policies that will exist 30 years from now are still unknown. > >> > >> Having a data structure is fine, but it is insufficient to > >> allow interoperability. > >> > >> The data structure should be able to reference the > >> validation policy used at each TST addition. > >> The current data structure is unable to support the > >> verification of an ERS-XML data structure that is 30 years old. > >> > >> Unless verification rules are explained in detail, this > >> document will not achieve its goal and will not be practically > usable. > >> > >> > >> > >> Verification rules may be different for different legislation and > >> countries and as you pointed out may even evolve over time. > >> A problem true for all signatures (be it certs, timestamps, etc.) > >> and not for XMLERS alone required to determine. > >> The draft (as with ERS) is based on the fact that all reasonable > >> validation data is stored and preserved > >> (e.g. by also using XMLERS/ERS or integrating into the timestamp > >> structures) and is validated based on the policy > >> at the time of the validation in the future. So a different > >> validation policy at each TST addition is not significant for the > >> future validation. > >> > >> [Denis] We are in strong disagreement here. > >> > >> Let us use a example. A TST is renewed every 10 years. > >> > >> After ten years, I apply what a would call an "algorithm maintenance > >> policy" and I reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > the > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> Ten years later, I choose another "algorithm maintenance policy" and > I > >> reference the OID/URN > >> from that policy before applying new TST, a certification path and > CRLs > >> captured at that time which demonstrate > >> that the TSU certificate from the earlier TST has not been revoked. > >> > >> In order to verify the structure, I first look at the OID/URN from > >> inner "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. Then I look at the OID/URN from > outer > >> "algorithm maintenance policy" and if I find it acceptable, > >> I apply the rules of the policy. > >> > >> There is not a global verification, but a verification that is > >> different at each step. > >> > >> The implication is to add to the current structure a new field to > >> indicate the OID/URN of the "algorithm maintenance policy" > >> that has been used for that step. > Yes we are in disagreement, though am not sure about the root of it. > Our > disagreement may result from a number things: > First, verification of all individual timestamps inside an evidence > record (i.e. in the Archive time stamps) follow the same verification > rules as if you would use to verify them seen atomic (one by one) > (based > on the time of the following renewal). > Second, there may be misunderstanding of the role of a LTA: as > specified > in 4810 and 4998, the security of the provided evidence records relies > on the cryptographic algorithms and a TSA as a trust anchor (there is > not need to e.g. certify a LTA itself as a trusted entity as well, at > least not for the validity of evidence records). > Therefore the applied policies must be appropriate for future > verifications to succeed, but this depends on the legal requirements of > what verification data is required for the used timestamps (which may > vary based on what type of TSA is used (e.g. how long it is guaranteed > to provide certificates and other verification data) and other means. > Third, the example I outlined at #2 may also help to understand why a > field "field to indicate the OID/URN of the "algorithm maintenance > policy"" does not add value. >=20 > > If I understand your comments correctly, what you are referring to is > audit trail on the decision making process of time stamp renewal. > Policy/policies inclusion reminds me on the AESs and their references > to singing policies and I am not really sure whether the basic ERs > structure (ASN.1 or XML) is to support that. However I do agree this is > a very important issue but it brings us to a crossroad of policies that > may be part of the ERS structure. For example, the ERS system might > operate per different policies, also the organizational perspective of > the evidence system may have implication on generation and maintenance > of preservation evidences (which again might be a sub-element of much > broader electronic data preservation policies). > > > >> Note: if we add this information to XMLERS, it would make sense to > do > >> the same for ERS. > >> > >> So a different validation policy at each TST addition is not > >> significant for the future validation. Even if it might be > interesting, > >> the key decision making unit will be the validation at the future > >> point (e.g. in 30 years) and not what policies the system > >> might have found appropriate at the time of timestamp renewals. > >> > >> On a personal note: I started an individual draft > >> https://datatracker.ietf.org/doc/draft-ietf-ltans-validate/ about > >> validation > >> and necessary data. It is still very early stage work in progress > >> (as I wanted to wait for XMLERS to finish first) > >> and I find the procedures to be probably quite controversial. So > >> the draft will not be continued in the LTANS WG > >> but submitted only as an individual informational ID. (If you > >> don't mind, I'd actually like to come back to you on that > >> and ask you for your input on it once I have refined it in a few > >> weeks time) > >> > >> [Denis] Thank you for the information. Until we solve the previous > >> point, it is likely that we will be in disagreement. > >> > >> However, this illustrates the fact that without addtional > information > >> on how to use and verify the data structure, > >> the current XMLERS draft is not usable in practice (i.e. there is no > >> interoperability). > No. XMLERS follows ERS in this regard and ERS is absolutely usable in > practice (best proof for that is that it is effectively used by a > number > of systems today). > To provide further explanation a bit more: Today, LTA operators usually > get some operational or legal advice to which verification data is > required and based on that integrate this into the structures (based > e.g. on the retention time of the data and the times of guaranteed > availability of verification data). E.g. a LTA operator may store data > that is kept only for 10 years, while the TSA (and even CAs for > signatures in stored documents) it uses has a government certification > (guarantee) to keep verification data available for 30 years. (In which > case he may not be legally bound to store that data.) >=20 >=20 > > Then this implies to ERS also. >=20 > >> 4) The text omits to consider how to deal with the risk of > >> TSU key compromission and what to do if a given > >> TSU key has been compromised. > >> > >> As I understand it, TSU key compromission would lead to > >> revocation of its certificate and loss of validity. > >> The draft talks about that, i.e. a Time-stamp renewal. > >> > >> However note, as such timestamp renewal would have to be done > >> timely (and actually before TS looses its validity, > >> there can be problems with cases of late discoveries of such TSU > >> compromissions. With this possibility in mind > >> it is recommended to use two redundant XMLERS with timestamps > >> from different timestamp authorities. > >> (see section 7 Security Considerations) > >> > >> As the detailed valuation of such events and legal requirements > >> may vary by country, it seemed prudent to describe things > >> up to the current level but not further. > >> > >> [Denis] As the document does not sufficiently deal with the > >> verification of the data structure, the case of TSU compromission > >> is not sufficiently addressed. > >> > >> In short, if when applying a new TST, the TSU certificate is marked > as > >> revoked, this is not a problem if the revocation reason > >> is anything else than "compromise". > >> > >> If the revocation reason is "compromise", then the text should say > what > >> to do (or what should have been done earlier). > > I can't agree here. Consequences of revocation event (whatever the > reason) might vary according to policies (even legislation) and > therefore I see no reason to go into details. As Tobias explained, the > draft addresses the problem of loosing validity of TST in general (or > TSU for whatever reason) and proposes general measures to avoid that. > TSA redundancy is one of the solutions which, however, only reduces the > risk of evidences decomposition in the future. One can consider other > countermeasures, but the draft is not there to address all of them. >=20 > I fully agree with Aljosa's argument (and disagree with you Denis). >=20 > Tobias >=20 >=20 >=20 > > Aljosa > > > >> Once again the data structure is described, but there is > unsufficient > >> guidance on how to use it and check it. > >> > >> Denis > >> > >> Denis > >> > >> ----- Message re=E7u ----- > >> De : ltans-bounces > >> =C0 : ltans > >> Date : 2010-08-23, 21:08:54 > >> Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > >> Working group last call for this draft will begin > >> today and end on > >> September 7th. Shortly after this draft completes > >> IESG processing the > >> working group will close, as noted during the meeting > >> last month. > >> > >> > -----Original Message----- > >> > From: ltans-bounces@ietf.org >> bounces@ietf.org> [mailto:ltans-bounces@ietf.org >> bounces@ietf.org> ] On Behalf > >> > Of Internet-Drafts@ietf.org >> Drafts@ietf.org> > >> > Sent: Monday, August 23, 2010 2:00 PM > >> > To: i-d-announce@ietf.org >> announce@ietf.org> > >> > Cc: ltans@ietf.org > >> > Subject: [ltans] I-D ACTION:draft-ietf-ltans- > >> xmlers-07.txt > >> > > >> > A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> > directories. > >> > This draft is a work item of the Long-Term Archive > >> and Notary Services > >> > Working Group of the IETF. > >> > > >> > Title : Extensible Markup Language Evidence Record > >> Syntax > >> > Author(s) : A. Blazic, S. Saljic, T. Gondrom > >> > Filename : draft-ietf-ltans-xmlers-07.txt > >> > Pages : 53 > >> > Date : 2010-8-23 > >> > > >> > In many scenarios, users must be able to > >> demonstrate the (time) > >> > existence, integrity and validity of data including > >> signed data for > >> > long or undetermined period of time. This document > >> specifies XML > >> > syntax and processing rules for creating evidence > >> for long-term > >> non- > >> > repudiation of existence of data. ERS-XML > >> incorporates alternative > >> > syntax and processing rules to ASN.1 ERS syntax by > >> using XML > >> > language. > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf- > >> ltans-xmlers-07.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP > >> at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > Below is the data which will enable a MIME > >> compliant mail reader > >> > implementation to automatically retrieve the ASCII > >> version of the > >> > Internet-Draft. > >> > > >> > > >> > > >> > ______________________________________________________________________ > >> > This email has been scanned by the MessageLabs > >> Email Security System. > >> > For more information please visit > >> http://www.messagelabs.com/email > >> > > >> > ______________________________________________________________________ > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > >> > >> > >> > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> > > _______________________________________________ > > ltans mailing list > > ltans@ietf.org > > https://www.ietf.org/mailman/listinfo/ltans >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans ------=_NextPart_10101813401774576506024_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Carl,

1 - You said:

[Carl]=20 DSSC applies at validation time.  I agree with Tobias that while one= could=20 package the policy
with a data item it is not necessary.  It doe= sn=92t=20 really matter what policy the LTA had in mind. 
What matters is = that=20 the evidence record passes the policy used by the relying party.  I see=20 no reason to make a change to include DSSC policy in the XMLERS=20 format.

Let us make a comparison with the concept of signature policy.
Elec= tronic=20 sigantures comes with two flavors: BES (Basic ES) and EPES (Explicit Poli= cy=20 ES).

In EPES, the signature policy is indicated. My request is to be able t= o=20 incorporate the maintenance policy, like in EPES.
You say you don't ne= ed it,=20 like in BES. So let us make it OPTIONAL, which means that it will be= =20 possible to place it
in the structure, whereas it is not the case tod= ay.

2 - You said:

[Carl]=20 I disagree, for reasons you have cited in the past.  There will alwa= ys be a=20 grace period applied at validation time
so this =93MUST be proven at = the time=20 the new TST is applied=94 cannot be true.  In any case, these sorts = of issues=20
are for the relying party to appraise and the policies used by relyin= g=20 parties may vary, hence DSSC need not be included.

When you consider a grace period, the TST on the previous data can be = applied=20 first and the CRL for the previous TST
captured, e.g. 24 hours later.=

The DSCC information used at that time should also be added to the str= ucture,=20 before the new TST is applied.

In this way, it will be possible to split the overall verifi= cation=20 by doing two sequences of verifications in any order:
a) verifying the= whole=20 structure, making the assumption that every DSCC information that ha= s been=20 used is correct, and
b) verifying that every DSCC information pla= ced in=20 the structure comes from a reliable source and was=20 correct 
    at the time indicated in the associat= ed=20 TST.

The advantage is that check a) can be fully automated.

3 - You said:

[Carl]=20 A security consideration on this topic seems like a reasonable thing to=20 do.  Tobias, can you add a security consideration
to address the= =20 separation of evidence record from policy?  I think that will close = this=20 issue.

Addressing the issue in the security considerations is fine. However, = changes=20 in the main body of the document are still necessary.

Denis

-----=20 Message re=E7u ----- De=20 : ltans-bounces =C0=20 : denis.pinkas,tobias.gondrom,ltans=20 Date=20 : 2010-10-13, 13:46:28 Sujet=20 : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

Responses=20 inline (as best I can given strange likely inconsistent tagging of who = said=20 what)=85

From:=20 ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of=20 Denis Pinkas
Sent: Tuesday, October 12, 2010 9:20=20 AM
To: tobias.gondrom; ltans
Subject: Re: [ltans] I= -D=20 ACTION:draft-ietf-ltans-xmlers-07.txt

I wonder = in which=20 phase we are: still in the resolution of the comment raised in the= WG=20 last call ?

Anyway, I= don't=20 believe that the issues I raised have been satisfactorily=20 addressed.

[Tobias] Hm, I can not see= the=20 value of adding used dssc policy data to
the Evidence Records beyon= d=20 anecdotal interest.

DSSC was intended to suppo= rt the=20 operation of a LTA (i.e. help decide when to do
which renewal proce= sses)=20 and verification clients to automatically process policies
(about w= hich=20 algorithms were valid for which time spans). All evidence in an evidenc= e=20 record
is based on the used algorithms and the external TSA as a tr= ust=20 anchor. So, although
it may be interesting to see which policies th= e=20 archive did use during its operation,
this must not influence the f= uture=20 verification of the signatures and evidence records. =

[Denis] You said: =93it MA= Y be=20 interesting to see which policies the archive did use during its operat= ion=94.=20

I would rather say: =93it = is=20 MANDATORY to know which [maintenance] policies have been applied
to= the=20 archive even time a new TST has been added.

The problem is that, at th= e=20 minimum, there should be an identifier of the maintenance policy
th= at has=20 been used (which is not the case in the present document). This will of= course=20 influence
the future verification of the TST since the maintenance = policy=20 used for each step (if found acceptable)
will have to be used.=20

[Carl]=20 DSSC applies at validation time.  I agree with Tobias that while o= ne=20 could package the policy with a data item it is not necessary.  It= =20 doesn=92t really matter what policy the LTA had in mind.  What mat= ters is=20 that the evidence record passes the policy used by the relying party.&n= bsp; I=20 see no reason to make a change to include DSSC policy in the XMLERS=20 format.

[Tobias]=

Consider the following cas= e: a=20 verification client in 2020 operates based on a dssc policy that
de= clares=20 that e.g. SHA-1 was valid until 2012 and that all hashes thereafter mus= t be=20 done by SHA-256
or higher. What difference would it make if the LTA= would=20 include into the Evidence Record its own policies
stating that it b= elieved=20 SHA-1 was valid until 2015? The verification client would still have to= follow=20 its own
dssc policy data for the verification and must ignore this = data=20 provided by the LTA.

Thus, I can not see the va= lue of=20 DSSCs data provided with Evidence Records.  If you could provide a= =20 scenario
where this data is valuable, the best way to integrate dss= c data=20 it into the structure would be in the form
of a "Cryptographic Info= rmation=20 Type" with its own identifier (in which case you would be right and we=20
would have to move the reference to the normative=20 section).

[Denis] Here is the scenar= io: for=20 each step, the dssc policy (which is part of the maintenance policy) MU= ST be=20
indicated. The verification process is a two steps process which ma= y be=20 performed in any order:

1) evaluate the maintenanc= e policy,=20

2) apply the maintenance=20 policy.

Evaluating the maintenance= policy,=20 is to make sure that the dssc policy is acceptable or is correct.=20

Applying the maintenance p= olicy is=20 taking into consideration the dssc policy as indicated.

There is however a point w= here we=20 are in agreement, since you said:

=93 Policy/policies inclus= ion reminds=20 me on the AESs and their references to singing policies and
I am no= t=20 really sure whether the basic ERs structure (ASN.1 or XML) is to suppor= t that.=20

However I do agree this is= a very=20 important issue but it brings us to a crossroad of policies
that ma= y be=20 part of the ERS structure. For example, the ERS system might operate pe= r=20 different policies,=94

The basic question is whet= her the=20 maintenance policies should or should not be part of the structure.=20
However, at this time this element cannot be included. A compromise= would=20 be to consider the maintenance
policy as an optional element.=20

[Denis] =

I said=20 earlier:

As the document does not=20 sufficiently deal with the verification of the data structure, the case= of TSU=20 compromise
is not sufficiently addressed.  In short, if when a= pplying=20 a new TST, the TSU certificate is marked as revoked,
this is not a = problem=20 if the revocation reason is anything else than "compromise".  If t= he=20 revocation reason
is "compromise", then the text should say what to= do (or=20 what should have been done earlier).

You replied:

I can't agree here. Conseq= uences of=20 revocation event (whatever the reason) might vary according to policies= =20
(even legislation) and therefore I see no reason to go into details= . As=20 Tobias explained, the draft addresses
the problem of loosing validi= ty of=20 TST in general (or TSU for whatever reason) and proposes general=20 measures
to avoid that. TSA redundancy is one of the solutions which= ,=20 however, only reduces the risk of evidences
decomposition in the fu= ture.=20 One can consider other countermeasures, but the draft is not there to a= ddress=20 all of them.

Maybe my explanations were= not=20 sufficient. Let me state again why there is a security hole in the curr= ent=20 description.

When a new TST is applied,= it MUST=20 be proven that at the time the new TST is applied the certificate of th= e TSU=20
was not revoked due to a key compromise. If the revocation is for=20 =93cessation of activity=94 this is not a problem,
since in that ca= se the=20 private key of the TSU has been previously destroyed and thus cannot be= used=20 nor compromised
anymore.

[Carl]=20 I disagree, for reasons you have cited in the past.  There will al= ways be=20 a grace period applied at validation time so this =93MUST be proven at = the time=20 the new TST is applied=94 cannot be true.  In any case, these sort= s of=20 issues are for the relying party to appraise and the policies used by r= elying=20 parties may vary, hence DSSC need not be included. =20

The document is lacking to= address=20 this major issue. This is also due to the fact that the document is pro= viding=20
a static description of the data structure and does not sufficientl= y=20 address the use of the data structure.

[Carl]=20 This neatly summarizes the situation.  The XMLERS format does not = address=20 the use relative to crypto policy.  Fortunately, it does not need = to as=20 DSSC addresses this.  Each and every evidence record need not carr= y=20 around this DSSC policy as the relying party can maintain a copy of the= policy=20 it wishes to use when validating an evidence record. =20

This aspect should be addr= essed=20 both in the main body of the document and in the security consideration= s=20 section.
If not, my position is the following: the document, as it = is,=20 should not be published as an RFC on the Standards=20 Track.

[Carl]=20 A security consideration on this topic seems like a reasonable thing to= =20 do.  Tobias, can you add a security consideration to address the=20 separation of evidence record from policy?  I think that will clos= e this=20 issue.

Denis

----- Me= ssage=20 re=E7u -----

De=20 : ltans-bounces=20

=C0=20 : Tobias=20 Gondrom,ltans

Date=20 : 2010-10= -08,=20 17:52:10

Sujet=20 : Re: [lt= ans] I-D=20 ACTION:draft-ietf-ltans-xmlers-07.txt

It appe= ars that=20 the issues have been satisfactorily addressed. We'll proceed with sen= ding=20 this draft to the AD early next week.

> -----Original=20 Message-----
> From: ltans-bounces@ietf.org=20 [mailto:ltans-bounces@ietf.org]= On=20 Behalf
> Of Tobias Gondrom
> Sent: Saturday, September 25= , 2010=20 2:26 PM
> To: ltans@ietf.org
> Subject:= Re:=20 [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
>
> I=20 basically agree with Aljosa. More detailed answers in line
> -=20 Tobias
>
>
> On 09/25/2010 02:19 PM, Aljosa Jerma= n=20 Blazic wrote:
> > Denis, Tobias
> >
> > It= took=20 me a while to get back to XMLERS and my answers are in line.
>=20 >
> >> -----Original Message-----
> >> Fro= m: ltans-bounces@ietf.org=20 [mailto:ltans-bounces@ietf.org]= =20 On
> Behalf
> >> Of Denis Pinkas
> >> S= ent:=20 September 14, 2010 12:34
> >> To: ltans
> >>=20 Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
>= ;=20 >>
> >> Tobias,
> >>
> >> S= ee=20 responses in line.
> >>
> >> Denis
>=20 >>
> >> ----- Message re=E7u -----
> >>= De :=20 ltans-bounces
> >> =C0 : ltans
> >> Date : 20= 10-09-13,=20 19:38:14
> >> Sujet : Re: [ltans] I-D=20 ACTION:draft-ietf-ltans-xmlers-07.txt
> >>
> >&g= t; Hi=20 Denis,
> >> yes the response is a bit late, but as we sti= ll have=20 IETF LC
> >> ahead, not too late.
> >> Based = on=20 Carl's decision we may discuss and resolve this here
> >>= while=20 the draft proceeds to IESG and IETF LC.
> >> Answers=20 inline.
> >>
> >> Kind regards, Tobias
>= ;=20 >>
> >>
> >> On 09/13/2010 04:48 PM, De= nis=20 Pinkas wrote:
> >>
> >> This is a late=20 response.
> >>
> >> Comments on=20 draft-ietf-ltans-xmlers-07
> >>
> >> 1) The a= bstract=20 from this draft states:
> >>
> >> In many sce= narios,=20 users must be able to demonstrate the
> >> (time)
>= =20 >> existence, integrity and validity of data including
>=20 >> signed data for
> >> long or undetermined period= of=20 time. This document
> >> specifies XML
> >> s= yntax=20 and processing rules for creating evidence for
> >> long-= term=20 non-
> >> repudiation of existence of data.
>=20 >>
> >> The abstract from RFC 4998, which is very s= imilar,=20 states:
> >>
> >> In many scenarios, users mu= st be=20 able prove the
> >> existence and
> >> integr= ity of=20 data, including digitally signed data, in a
> >> common=20 and
> >> reproducible way over a long and possibly=20 undetermined
> >> period of
> >> time. This d= ocument=20 specifies the syntax and processing
> >> of an
> &g= t;>=20 Evidence Record, a structure designed to support long-
> >&g= t; term=20 non-
> >> repudiation of existence of data.
>=20 >>
> >> Then an additional sentence in the draft=20 states:
> >>
> >> ERS-XML incorporates altern= ative=20 syntax and processing
> >> rules to ASN.1 ERS syntax
&= gt;=20 >> by using XML language.
> >>
> >> The= basic=20 question is why an addendum has not been added to
> >> RF= C 4998=20 to include
> >> an XML syntax, equivalent to the ASN.1.>=20 >>
> >> Some explanations are given on page 7 are n= ot=20 convincing:
> >>
> >> Due to the differences = in XML=20 processing rules and other
> >> characteristics of XML la= nguage,=20 XMLERS does not present
> >> a direct
> >>=20 transformation of ERS in ASN.1 syntax. The XMLERS syntax
> >= > is=20 based on
> >> different processing rules as defined in [R= FC4998]=20 and
> >> it does not
> >> support for example= import=20 of ASN.1 values in XML tags.
> >> Creating
> >&g= t;=20 Evidence Records in XML syntax must follow the steps as
> >&= gt;=20 defined in
> >> this draft. XMLERS is a standalone draft = and is=20 based on
> >> [RFC4998]
> >> conceptually=20 only.
> >>
> >> The text omits to highlight w= hat the=20 differences are.
> >>
> >> For example, ERS=20 states:
> >>
> >> The data (e.g. certificates= ,=20 Certificate Revocation
> >> Lists (CRLs), or
> >= >=20 Online Certificate Status Protocol (OCSP) responses)
> >>= needed=20 to verify
> >> the timestamp MUST be preserved, and SHOUL= D be=20 stored in
> >> the
> >> timestamp itself unle= ss this=20 causes unnecessary
> >> duplication.
> >>
= >=20 >> While the draft states:
> >>
> >> An= ATS=20 contains a Time-Stamp Token and optionally other
> >>=20 useful
> >> data for Time-Stamp validation, e.g. certific= ates,=20 CRLs
> >> or OCSP
> >> responses
>=20 >>
> >> In one case CRLs should be part of the TST,= while=20 in the
> >> other case it should be
> >> exte= rnal to=20 the TST.
> >>
> >> Section 1.1 should be revi= sed to=20 mention the differences
> >> with a rational about them.<= BR>>=20 >>
> >>
> >>
> >> In theory= we=20 could have added XMLERS to ERS, but XML puts
> >> differe= nt=20 processing issues to the document,
> >> for example the o= rdering=20 problem of the XML elements (to always
> >> produce ident= ical=20 hash values
> >> for the same data structure). XMLERS req= uired=20 further explanation
> >> regarding these processing rules= =20 and
> >> a well-thought XML structure, plus identifiers t= o be=20 assigned by
> >> IANA for certain types. All these items = are=20 not
> >> related to ERS or its ASN.1 structure and would = have=20 made the RFC
> >> unnecessarily complex to read while
= >=20 >> bringing not much benefit.
> >>
> >>= So a=20 lot of reasons to put this in a separate draft, and not much
>=20 >> harm from doing so.
> > I support Tobias comments a= s the=20 benefit of expanding ASN.1
> recommendation with additional XML= based=20 structure and processing rules
> would make the whole RFC unrea= dable.=20 The intention of separate
> specifications is to have one's dec= ision=20 on implementation type, i.e.
> ASN.1 vs XML. Section 1.1. can b= e=20 further revised to support these
> facts.
> >> [Den= is] I=20 am requesting to add further information to section 1.1.
> so>=20 >> that people may understand better why there has been no=20 translation
> of
> >> the ASN.1 into XML.
>=20 [Tobias]: I find section 1.1 as it is totally satisfactory regarding<= BR>>=20 reasons and explanations. Adding further reasons is redundant.=20 However
> as opinions can obviously deviate on this matter, may= be you=20 could
> provide reasons for why you feel this additional paragr= aph is=20 needed to
> understand the RFC better and maybe give some indic= ation=20 on how much
> information you think would be needed (as I would= like=20 to keep it as
> concise as possible)? Would a short three-line=20 paragraph based on my
> initial answer to your comment satisfy = your=20 request to further
> information?
>
> >> 2) = Page 43=20 states:
> >>
> >> A generic solution for auto= matic=20 interpretation of
> >> security suitability
> >&= gt;=20 policies in electronic form is not the subject of this
> >&g= t;=20 specification.
> >>
> >> It is a copy and pas= te of=20 the same text which existed in
> >> RFC 4998.
>=20 >>
> >> However, this document omits to take into=20 consideration RFC
> >> 5698 which has been issued
>= =20 >> in November 2009 (Data Structure for the Security
> &g= t;>=20 Suitability of Cryptographic Algorithms
> >> - DSSC) and = which=20 respond to the problem raised.
> >>
> >> Whil= e it is=20 normal that the concept was not supported in
> >> August = 2007=20 when ERS was published,
> >> it is abnormal that the prob= lems=20 highlighted in RFC 5698
> >> are not covered by this draf= t. In=20 order to
> >> demonstrate that an algorithm was not weak,= it is=20 useful to
> >> include a data structure that lists the>=20 >> weak algorithms at a given point of time. This is what RFC>=20 >> 5698 allows.
> >>
> >> In any case, = the=20 text from section 7 (page 43) needs to be
> >> updated.>=20 >>
> >>
> >>
> >> Thank you= , I=20 missed that. I agree. We definitely should refer to
> >> = RFC5698=20 as a method that may be used and add it to the informative
> &g= t;>=20 references.
> >>
> >>
> >> [Denis= ] In=20 fact , I am asking more that simply making a reference to
> >= ;>=20 RFC 5698, but to be able to include some structures defined in RFC>=20 5698
> >> into XMLERS. RFC 5698 should then be in the nor= mative=20 references.
> Hm, I can not see the value of adding used dssc p= olicy=20 data to the
> Evidence Records beyond anecdotal interest.
&g= t; DSSC=20 was intended to support the operation of a LTA (i.e. help decide
&= gt;=20 when to do which renewal processes) and verification clients to
&g= t;=20 automatically process policies (about which algorithms were valid=20 for
> which time spans).
> All evidence in an evidence re= cord is=20 based on the used algorithms and
> the external TSA as a trust=20 anchor.
> So, although it may be interesting to see which polic= ies the=20 archive
> did
> use during its operation, this must not=20 influence the future
> verification of the signatures and evide= nce=20 records.
> (Consider the following case: a verification client = in 2020=20 operates
> based on a dssc policy that declares that e.g. SHA-1= was=20 valid until
> 2012 and that all hashes thereafter must be done = by=20 SHA-256 or higher.
> What difference would it make if the LTA w= ould=20 include into the
> Evidence
> Record its own policies sta= ting=20 that it believed SHA-1 was valid until
> 2015? The verification= client=20 would still have to follow its own dssc
> policy data for the=20 verification and must ignore this data provided by
> the LTA.=20 Remember: a LTA is not trusted by itself, but relies on the
>=20 TSA
> as a trust anchor for its evidence records.)
>
= >=20 Thus, I can not see the value of DSSCs data provided with Evidence>=20 Records.
>
> If you could provide a scenario where this = data is=20 valuable, the best
> way to integrate dssc data it into the str= ucture=20 would be in the form
> of
> a "Cryptographic Information = Type"=20 with its own identifier (in which
> case you would be right and= we=20 would have to move the reference to the
> normative section).>=20
> >> 3) The most important concern is the following one = :=20 there
> >> is no rule in the document to explain
>=20 >> how to really verify a given ERS-XML structure. Which root>=20 >> keys need to be used to verify one structure ?
> >&= gt;=20 Which rules to apply to verify an ERS-XML data structure
> >= >=20 that is 30 years old ? The notion of multiple
> >> valida= tion=20 policies should be supported, since validation
> >> polic= ies=20 that will exist 30 years from now are still unknown.
>=20 >>
> >> Having a data structure is fine, but it is=20 insufficient to
> >> allow interoperability.
>=20 >>
> >> The data structure should be able to refere= nce=20 the
> >> validation policy used at each TST addition.
= >=20 >> The current data structure is unable to support the
>=20 >> verification of an ERS-XML data structure that is 30 years=20 old.
> >>
> >> Unless verification rules are=20 explained in detail, this
> >> document will not achieve = its=20 goal and will not be practically
> usable.
> >>
= >=20 >>
> >>
> >> Verification rules may be=20 different for different legislation and
> >> countries an= d as=20 you pointed out may even evolve over time.
> >> A problem= true=20 for all signatures (be it certs, timestamps, etc.)
> >> a= nd not=20 for XMLERS alone required to determine.
> >> The draft (a= s with=20 ERS) is based on the fact that all reasonable
> >> valida= tion=20 data is stored and preserved
> >> (e.g. by also using XML= ERS/ERS=20 or integrating into the timestamp
> >> structures) and is= =20 validated based on the policy
> >> at the time of the val= idation=20 in the future. So a different
> >> validation policy at e= ach TST=20 addition is not significant for the
> >> future=20 validation.
> >>
> >> [Denis] We are in stron= g=20 disagreement here.
> >>
> >> Let us use a exa= mple. A=20 TST is renewed every 10 years.
> >>
> >> Afte= r ten=20 years, I apply what a would call an "algorithm maintenance
> &g= t;>=20 policy" and I reference the OID/URN
> >> from that policy= before=20 applying new TST, a certification path and
> CRLs
> >&= gt;=20 captured at that time which demonstrate
> >> that the TSU= =20 certificate from the earlier TST has not been revoked.
>=20 >>
> >> In order to verify the structure, I first l= ook at=20 the OID/URN from
> the
> >> "algorithm maintenance = policy"=20 and if I find it acceptable,
> >> I apply the rules of th= e=20 policy.
> >>
> >> Ten years later, I choose a= nother=20 "algorithm maintenance policy" and
> I
> >> referen= ce the=20 OID/URN
> >> from that policy before applying new TST, a=20 certification path and
> CRLs
> >> captured at that= time=20 which demonstrate
> >> that the TSU certificate from the = earlier=20 TST has not been revoked.
> >>
> >> In order = to=20 verify the structure, I first look at the OID/URN from
> >&g= t;=20 inner "algorithm maintenance policy" and if I find it acceptable,
= >=20 >> I apply the rules of the policy. Then I look at the OID/URN=20 from
> outer
> >> "algorithm maintenance policy" an= d if I=20 find it acceptable,
> >> I apply the rules of the=20 policy.
> >>
> >> There is not a global=20 verification, but a verification that is
> >> different a= t each=20 step.
> >>
> >> The implication is to add to = the=20 current structure a new field to
> >> indicate the OID/UR= N of=20 the "algorithm maintenance policy"
> >> that has been use= d for=20 that step.
> Yes we are in disagreement, though am not sure abo= ut the=20 root of it.
> Our
> disagreement may result from a number= =20 things:
> First, verification of all individual timestamps insi= de an=20 evidence
> record (i.e. in the Archive time stamps) follow the = same=20 verification
> rules as if you would use to verify them seen at= omic=20 (one by one)
> (based
> on the time of the following=20 renewal).
> Second, there may be misunderstanding of the role o= f a=20 LTA: as
> specified
> in 4810 and 4998, the security of t= he=20 provided evidence records relies
> on the cryptographic algorit= hms and=20 a TSA as a trust anchor (there is
> not need to e.g. certify a = LTA=20 itself as a trusted entity as well, at
> least not for the vali= dity of=20 evidence records).
> Therefore the applied policies must be=20 appropriate for future
> verifications to succeed, but this dep= ends on=20 the legal requirements of
> what verification data is required = for the=20 used timestamps (which may
> vary based on what type of TSA is = used=20 (e.g. how long it is guaranteed
> to provide certificates and o= ther=20 verification data) and other means.
> Third, the example I outl= ined at=20 #2 may also help to understand why a
> field "field to indicate= the=20 OID/URN of the "algorithm maintenance
> policy"" does not add=20 value.
>
> > If I understand your comments correctly,= what=20 you are referring to is
> audit trail on the decision making pr= ocess=20 of time stamp renewal.
> Policy/policies inclusion reminds me o= n the=20 AESs and their references
> to singing policies and I am not re= ally=20 sure whether the basic ERs
> structure (ASN.1 or XML) is to sup= port=20 that. However I do agree this is
> a very important issue but i= t=20 brings us to a crossroad of policies that
> may be part of the = ERS=20 structure. For example, the ERS system might
> operate per diff= erent=20 policies, also the organizational perspective of
> the evidence= system=20 may have implication on generation and maintenance
> of preserv= ation=20 evidences (which again might be a sub-element of much
> broader= =20 electronic data preservation policies).
> >
> >>= Note:=20 if we add this information to XMLERS, it would make sense to
>=20 do
> >> the same for ERS.
> >>
> >&g= t; So a=20 different validation policy at each TST addition is not
> >&= gt;=20 significant for the future validation. Even if it might be
>=20 interesting,
> >> the key decision making unit will be th= e=20 validation at the future
> >> point (e.g. in 30 years) an= d not=20 what policies the system
> >> might have found appropriat= e at=20 the time of timestamp renewals.
> >>
> >> On = a=20 personal note: I started an individual draft
> >> = https://datatracker.ietf.org/doc/draft-ietf-ltans-validate/=20 about
> >> validation
> >> and necessary data= . It is=20 still very early stage work in progress
> >> (as I wanted= to=20 wait for XMLERS to finish first)
> >> and I find the proc= edures=20 to be probably quite controversial. So
> >> the draft wil= l not=20 be continued in the LTANS WG
> >> but submitted only as a= n=20 individual informational ID. (If you
> >> don't mind, I'd= =20 actually like to come back to you on that
> >> and ask yo= u for=20 your input on it once I have refined it in a few
> >> wee= ks=20 time)
> >>
> >> [Denis] Thank you for the=20 information. Until we solve the previous
> >> point, it i= s=20 likely that we will be in disagreement.
> >>
> >= >=20 However, this illustrates the fact that without addtional
>=20 information
> >> on how to use and verify the data=20 structure,
> >> the current XMLERS draft is not usable in= =20 practice (i.e. there is no
> >> interoperability).
>= ; No.=20 XMLERS follows ERS in this regard and ERS is absolutely usable in
= >=20 practice (best proof for that is that it is effectively used by a
= >=20 number
> of systems today).
> To provide further explanat= ion a=20 bit more: Today, LTA operators usually
> get some operational o= r legal=20 advice to which verification data is
> required and based on th= at=20 integrate this into the structures (based
> e.g. on the retenti= on time=20 of the data and the times of guaranteed
> availability of verif= ication=20 data). E.g. a LTA operator may store data
> that is kept only f= or 10=20 years, while the TSA (and even CAs for
> signatures in stored=20 documents) it uses has a government certification
> (guarantee)= to=20 keep verification data available for 30 years. (In which
> case= he may=20 not be legally bound to store that data.)
>
>
> &= gt;=20 Then this implies to ERS also.
>
> >> 4) The text = omits=20 to consider how to deal with the risk of
> >> TSU key=20 compromission and what to do if a given
> >> TSU key has = been=20 compromised.
> >>
> >> As I understand it, TS= U key=20 compromission would lead to
> >> revocation of its certif= icate=20 and loss of validity.
> >> The draft talks about that, i.= e. a=20 Time-stamp renewal.
> >>
> >> However note, a= s such=20 timestamp renewal would have to be done
> >> timely (and=20 actually before TS looses its validity,
> >> there can be= =20 problems with cases of late discoveries of such TSU
> >>=20 compromissions. With this possibility in mind
> >> it is=20 recommended to use two redundant XMLERS with timestamps
> >&= gt;=20 from different timestamp authorities.
> >> (see section 7= =20 Security Considerations)
> >>
> >> As the det= ailed=20 valuation of such events and legal requirements
> >> may = vary by=20 country, it seemed prudent to describe things
> >> up to = the=20 current level but not further.
> >>
> >> [Den= is] As=20 the document does not sufficiently deal with the
> >>=20 verification of the data structure, the case of TSU compromission
= >=20 >> is not sufficiently addressed.
> >>
> >= > In=20 short, if when applying a new TST, the TSU certificate is marked
&= gt;=20 as
> >> revoked, this is not a problem if the revocation=20 reason
> >> is anything else than "compromise".
>=20 >>
> >> If the revocation reason is "compromise", t= hen the=20 text should say
> what
> >> to do (or what should h= ave=20 been done earlier).
> > I can't agree here. Consequences of=20 revocation event (whatever the
> reason) might vary according t= o=20 policies (even legislation) and
> therefore I see no reason to = go into=20 details. As Tobias explained, the
> draft addresses the problem= of=20 loosing validity of TST in general (or
> TSU for whatever reaso= n) and=20 proposes general measures to avoid that.
> TSA redundancy is on= e of=20 the solutions which, however, only reduces the
> risk of eviden= ces=20 decomposition in the future. One can consider other
> counterme= asures,=20 but the draft is not there to address all of them.
>
> I= fully=20 agree with Aljosa's argument (and disagree with you Denis).
> <= BR>>=20 Tobias
>
>
>
> > Aljosa
> >>=20 >> Once again the data structure is described, but there is
= >=20 unsufficient
> >> guidance on how to use it and check=20 it.
> >>
> >> Denis
> >>
>=20 >> Denis
> >>
> >> ----- Message re=E7u= =20 -----
> >> De : ltans-bounces
> >> =C0 : ltan= s
>=20 >> Date : 2010-08-23, 21:08:54
> >> Sujet : Re: [lt= ans]=20 I-D ACTION:draft-ietf-ltans-
> >> xmlers-07.txt
>=20 >>
> >> Working group last call for this draft will= =20 begin
> >> today and end on
> >> September 7t= h.=20 Shortly after this draft completes
> >> IESG processing=20 the
> >> working group will close, as noted during the=20 meeting
> >> last month.
> >>
> >>= ; >=20 -----Original Message-----
> >> > From: ltans-bounces@ietf.org=20 <mailto:%20ltans-
> >> bounces@ietf.org> [mailto:= ltans-bounces@ietf.org=20 <mailto:%20ltans-
> >> bounces@ietf.org> ] On=20 Behalf
> >> > Of Internet-Drafts@ietf.org<= /A>=20 <mailto:%20Internet-
> >> Drafts@ietf.org>
> &g= t;>=20 > Sent: Monday, August 23, 2010 2:00 PM
> >> > To: = i-d-announce@ietf.org=20 <mailto:%20i-d-
> >> announce@ietf.org>
>= ;=20 >> > Cc: ltans@ietf.org= =20 <mailto:%20ltans@ietf.org>
> = >>=20 > Subject: [ltans] I-D ACTION:draft-ietf-ltans-
> >>=20 xmlers-07.txt
> >> >
> >> > A New=20 Internet-Draft is available from the on-line
> >>=20 Internet-Drafts
> >> > directories.
> >> &= gt;=20 This draft is a work item of the Long-Term Archive
> >> a= nd=20 Notary Services
> >> > Working Group of the IETF.
&= gt;=20 >> >
> >> > Title : Extensible Markup Languag= e=20 Evidence Record
> >> Syntax
> >> > Author(= s) : A.=20 Blazic, S. Saljic, T. Gondrom
> >> > Filename :=20 draft-ietf-ltans-xmlers-07.txt
> >> > Pages : 53
&g= t;=20 >> > Date : 2010-8-23
> >> >
> >>= >=20 In many scenarios, users must be able to
> >> demonstrate= the=20 (time)
> >> > existence, integrity and validity of dat= a=20 including
> >> signed data for
> >> > long= or=20 undetermined period of time. This document
> >> specifies= =20 XML
> >> > syntax and processing rules for creating=20 evidence
> >> for long-term
> >> non-
>= =20 >> > repudiation of existence of data. ERS-XML
> >&= gt;=20 incorporates alternative
> >> > syntax and processing = rules=20 to ASN.1 ERS syntax by
> >> using XML
> >> &g= t;=20 language.
> >> >
> >> > A URL for this=20 Internet-Draft is:
> >> > http://www.i= etf.org/internet-drafts/draft-ietf-
>=20 >> ltans-xmlers-07.txt
> >> >
> >> &= gt;=20 Internet-Drafts are also available by anonymous FTP
> >>=20 at:
> >> > ftp://ftp.ietf.org/internet-drafts/
>= =20 >> >
> >> > Below is the data which will enab= le a=20 MIME
> >> compliant mail reader
> >> >=20 implementation to automatically retrieve the ASCII
> >> v= ersion=20 of the
> >> > Internet-Draft.
> >> >>=20 >> >
> >> >
> >>
>=20 _____________________________________________________________________= _
>=20 >> > This email has been scanned by the MessageLabs
>=20 >> Email Security System.
> >> > For more inform= ation=20 please visit
> >> http://www.messagelabs.com/= email
>=20 >> >
> >>
>=20 _____________________________________________________________________= _
>=20 >> _______________________________________________
> >= >=20 ltans mailing list
> >> ltans@ietf.org <mailto:%20ltans@ietf.org>
> = >>=20 https://www.ietf= .org/mailman/listinfo/ltans
>=20 >>
> >>
> >>
> >>
> &= gt;>=20 _______________________________________________
> >> ltan= s=20 mailing list
> >> ltans@ietf.org
> >>= https://www.ietf= .org/mailman/listinfo/ltans
>=20 >>
> >=20 _______________________________________________
> > ltans ma= iling=20 list
> > ltans@ietf.org
> > https://www.ietf= .org/mailman/listinfo/ltans
>=20
> _______________________________________________
> ltan= s=20 mailing list
> ltans@ietf.org
> https://www.ietf= .org/mailman/listinfo/ltans
______________________________________= _________
ltans=20 mailing list
ltans@ietf.org
https://www.ietf= .org/mailman/listinfo/ltans

------=_NextPart_10101813401774576506024_002-- From aljosa@setcce.si Mon Oct 18 11:47:59 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B78A3A6BB0 for ; Mon, 18 Oct 2010 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1QkCv8VxrZI for ; Mon, 18 Oct 2010 11:47:58 -0700 (PDT) Received: from setcce.si (mail.setcce.si [88.200.65.130]) by core3.amsl.com (Postfix) with ESMTP id 42D6D3A6E34 for ; Mon, 18 Oct 2010 11:47:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Oct 2010 20:49:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt thread-index: ActuuWtloMnE2kxdSfSFnBdY0M2WCAAOfvfA References: From: "Aljosa Jerman Blazic" To: "ltans" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 18:47:59 -0000 Denis, My comments in-line =20 > Carl, >=20 > 1 - You said: >=20 > [Carl] DSSC applies at validation time. I agree with Tobias that while > one could package the policy with a data item it is not necessary. It > doesn't really matter what policy the LTA had in mind. > What matters is that the evidence record passes the policy used by the > relying party. > I see no reason to make a change to include DSSC policy in the XMLERS > format. >=20 > Let us make a comparison with the concept of signature policy. > Electronic sigantures comes with two flavors: BES (Basic ES) and EPES > (Explicit Policy ES). >=20 > In EPES, the signature policy is indicated. My request is to be able to > incorporate the maintenance policy, like in EPES. > You say you don't need it, like in BES. So let us make it OPTIONAL, > which means that it will be possible to place it in the structure, > whereas it is not the case today. We can evaluate this option and see if it fits as my concern is to what extent optional parameters are to be added. In case of maintenance policy I would at least miss the original operation policy. With this info one could decide on the reliability of ERS evidences and ERS operation. > 2 - You said: >=20 > [Carl] I disagree, for reasons you have cited in the past. There will > always be a grace period applied at validation time so this "MUST be > proven at the time the new TST is applied" cannot be true. In any > case, these sorts of issues are for the relying party to appraise and > the policies used by relying parties may vary, hence DSSC need not be > included. >=20 > When you consider a grace period, the TST on the previous data can be > applied first and the CRL for the previous TST captured, e.g. 24 hours > later. Now what happens if the CRL is compromised or ceases to exist, so its integrity is questionable? The information (CRL) provided after TST does not give any value at all only if it is ERSed as the rest of the information. Similarly, the AES does not consider such approach. =20 > The DSCC information used at that time should also be added to the > structure, before the new TST is applied. >=20 > In this way, it will be possible to split the overall verification by > doing two sequences of verifications in any order: > a) verifying the whole structure, making the assumption that every DSCC > information that has been used is correct, and > b) verifying that every DSCC information placed in the structure comes > from a reliable source and was correct > at the time indicated in the associated TST. >=20 > The advantage is that check a) can be fully automated. Agree if the reason for DSSC inclusion stands. > 3 - You said: >=20 > [Carl] A security consideration on this topic seems like a reasonable > thing to do. Tobias, can you add a security consideration to address > the separation of evidence record from policy? I think that will close > this issue. >=20 > Addressing the issue in the security considerations is fine. However, > changes in the main body of the document are still necessary. As said before, optional element might be considered, however in this case, I would say, the question remains open with the original ERS syntax (I think you have mentioned that already). Security considerations can be updated to address the above issues. Aljosa From denis.pinkas@bull.net Tue Oct 19 10:27:49 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8C93A68C2 for ; Tue, 19 Oct 2010 10:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SRMWUbCrP7q for ; Tue, 19 Oct 2010 10:27:48 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id E42B93A68B7 for ; Tue, 19 Oct 2010 10:27:47 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 63560180DE for ; Tue, 19 Oct 2010 19:35:33 +0200 (CEST) Received: from FRCLS4013 ([129.184.39.15]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010101919291728:15343 ; Tue, 19 Oct 2010 19:29:17 +0200 From: "Denis Pinkas" To: "ltans" Date: Tue, 19 Oct 2010 19:29:13 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 19/10/2010 19:29:17, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 19/10/2010 19:29:18, Serialize complete at 19/10/2010 19:29:18 Content-Type: multipart/alternative; boundary="----=_NextPart_10101919291279112304808_002" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:27:49 -0000 ------=_NextPart_10101919291279112304808_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Responses are in-line. ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : ltans=20 Date : 2010-10-18, 20:49:37 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt Denis, My comments in-line =20 > Carl, >=20 > 1 - You said: >=20 > [Carl] DSSC applies at validation time. I agree with Tobias that while > one could package the policy with a data item it is not necessary. It > doesn't really matter what policy the LTA had in mind. > What matters is that the evidence record passes the policy used by the > relying party. > I see no reason to make a change to include DSSC policy in the XMLERS > format. >=20 > Let us make a comparison with the concept of signature policy. > Electronic sigantures comes with two flavors: BES (Basic ES) and EPES > (Explicit Policy ES). >=20 > In EPES, the signature policy is indicated. My request is to be able to > incorporate the maintenance policy, like in EPES. > You say you don't need it, like in BES. So let us make it OPTIONAL, > which means that it will be possible to place it in the structure, > whereas it is not the case today. We can evaluate this option and see if it fits as my concern is to what extent optional parameters are to be added. In case of maintenance policy I would at least miss the original operation policy. With this info one could decide on the reliability of ERS evidences and ERS operation. I understand the first sentence, but not clearly the second one. > 2 - You said: >=20 > [Carl] I disagree, for reasons you have cited in the past. There will > always be a grace period applied at validation time so this "MUST be > proven at the time the new TST is applied" cannot be true. In any > case, these sorts of issues are for the relying party to appraise and > the policies used by relying parties may vary, hence DSSC need not be > included. >=20 > When you consider a grace period, the TST on the previous data can be > applied first and the CRL for the previous TST captured, e.g. 24 hours > later. Now what happens if the CRL is compromised or ceases to exist, so its integrity is questionable? The information (CRL) provided after TST does not give any value at all only if it is ERSed as the rest of the information. Similarly, the AES does not consider such approach. The AES (Advanced Electronic Signature) does support that case.=20 However, it does not mandate to support it, since the risk of a CRL Issue= r compromise=20 is much lower than the risk of the signer's key compromise. A second time stamp token can be placed on the references of the certific= ation path=20 including the revocation information. Since the references include a hash= of the values,=20 there is a full protection. For example, see XAdES-X type 2.=20 > The DSCC information used at that time should also be added to the > structure, before the new TST is applied. >=20 > In this way, it will be possible to split the overall verification by > doing two sequences of verifications in any order: > a) verifying the whole structure, making the assumption that every DSCC > information that has been used is correct, and > b) verifying that every DSCC information placed in the structure comes > from a reliable source and was correct > at the time indicated in the associated TST. >=20 > The advantage is that check a) can be fully automated. Agree if the reason for DSSC inclusion stands. Fine. > 3 - You said: >=20 > [Carl] A security consideration on this topic seems like a reasonable > thing to do. Tobias, can you add a security consideration to address > the separation of evidence record from policy? I think that will close > this issue. >=20 > Addressing the issue in the security considerations is fine. However, > changes in the main body of the document are still necessary. As said before, optional element might be considered, however in this case, I would say, the question remains open with the original ERS syntax (I think you have mentioned that already). Security considerations can be updated to address the above issues. Indeed, ERS does not support these features. Aljosa _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans ------=_NextPart_10101919291279112304808_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Responses are in-line.
 
-----=20 Message re=E7u ----- De=20 : ltans-bounces =C0=20 : ltans Date=20 : 2010-10-18, 20:49:37 Sujet=20 : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

Denis,

My comments in-line

 
> Carl,
&= gt;=20
> 1 - You said:
>
> [Carl] DSSC applies at validati= on=20 time. I agree with Tobias that
while
> one could package the p= olicy=20 with a data item it is not necessary. It
> doesn't really matter = what=20 policy the LTA had in mind.
> What matters is that the evidence r= ecord=20 passes the policy used by the
> relying party.
> I see no r= eason=20 to make a change to include DSSC policy in the XMLERS
> format.>=20
> Let us make a comparison with the concept of signature=20 policy.
> Electronic sigantures comes with two flavors: BES (Basi= c ES)=20 and EPES
> (Explicit Policy ES).
>
> In EPES, the si= gnature=20 policy is indicated. My request is to be able to
> incorporate th= e=20 maintenance policy, like in EPES.
> You say you don't need it, li= ke in=20 BES. So let us make it OPTIONAL,
> which means that it will be po= ssible=20 to place it in the structure,
> whereas it is not the case=20 today.

We can evaluate this option and see if it fits as my conc= ern is=20 to what
extent optional parameters are to be added. In case of=20 maintenance
policy I would at least miss the original operation poli= cy.=20 With this
info one could decide on the reliability of ERS evidences = and=20 ERS
operation.

I understand the first sentence, but not clearly the second one.

> 2 - You said:
>
> [Carl] I disagree, for reasons= you=20 have cited in the past. There will
> always be a grace period app= lied at=20 validation time so this "MUST be
> proven at the time the new TST= is=20 applied" cannot be true. In any
> case, these sorts of issues are= for=20 the relying party to appraise and
> the policies used by relying = parties=20 may vary, hence DSSC need not be
> included.
>
> Whe= n you=20 consider a grace period, the TST on the previous data can be
> ap= plied=20 first and the CRL for the previous TST captured, e.g. 24 hours
>=20 later.

Now what happens if the CRL is compromised or ceases to e= xist,=20 so its
integrity is questionable? The information (CRL) provided aft= er TST=20 does
not give any value at all only if it is ERSed as the rest of=20 the
information. Similarly, the AES does not consider such=20 approach.

The AES (Advanced Electronic Signature) does support that case.
Ho= wever,=20 it does not mandate to support it, since the risk of a CRL Issuer comprom= ise=20
is much lower than the risk of the signer's key compromise.

A second time stamp token can be placed on the references of the=20 certification path
including the revocation information. Since the=20 references include a hash of the values,
there is a full protection. = For=20 example, see  XAdES-X type 2.

 > The DSCC information used at that time should also be a= dded to=20 the
> structure, before the new TST is applied.
>
> = In this=20 way, it will be possible to split the overall verification by
> d= oing=20 two sequences of verifications in any order:
> a) verifying the w= hole=20 structure, making the assumption that every DSCC
> information th= at has=20 been used is correct, and
> b) verifying that every DSCC informat= ion=20 placed in the structure comes
> from a reliable source and was=20 correct
> at the time indicated in the associated TST.
> >=20 The advantage is that check a) can be fully automated.

Agree if = the=20 reason for DSSC inclusion stands.
 
Fine.

 

> 3 - You said:
>
> [Carl] A security consideratio= n on=20 this topic seems like a reasonable
> thing to do. Tobias, can you= add a=20 security consideration to address
> the separation of evidence re= cord=20 from policy? I think that will
close
> this issue.
> >=20 Addressing the issue in the security considerations is fine. However,>=20 changes in the main body of the document are still necessary.

As= said=20 before, optional element might be considered, however in this
case, = I would=20 say, the question remains open with the original ERS
syntax (I think= you=20 have mentioned that already). Security
considerations can be updated= to=20 address the above issues.
 
Indeed, ERS does not support these = features.

 

Aljosa
_______________________________________________
ltans= =20 mailing list
ltans@ietf.orghttps://www.ietf.o= rg/mailman/listinfo/ltans

------=_NextPart_10101919291279112304808_002-- From tobias.gondrom@gondrom.org Tue Oct 19 16:45:21 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81713A6959 for ; Tue, 19 Oct 2010 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.808 X-Spam-Level: X-Spam-Status: No, score=-94.808 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFJ3D77SKEw4 for ; Tue, 19 Oct 2010 16:45:19 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id CBC043A693A for ; Tue, 19 Oct 2010 16:45:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=jSxp+ah0eSWGrzKIP5uy9a8L3ZUcOus90D0kxV1MiKMtzWwzlZa3dH0vC8Vmu5iSgJbTz0e87jXUQLD06i1/XpPyinZ6f1O7OzJnoF3mm9U9Zx0gf7B/0T/C6m4wynS1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 1761 invoked from network); 20 Oct 2010 01:46:46 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Oct 2010 01:46:46 +0200 Message-ID: <4CBE2DE6.5010007@gondrom.org> Date: Wed, 20 Oct 2010 00:46:46 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: ltans@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------040000050900090205000804" Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 23:45:21 -0000 This is a multi-part message in MIME format. --------------040000050900090205000804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Ok, let's try to resolve this. Over the last three days I've been working on possible changes to the current draft that offer a way to store dssc in it. And I think I found options that could be done fairly straight forward, but will need to discuss the best options/wording with Aljosa tomorrow. And I think we can add something to the security considerations, too. Regarding Denis point #3: you mentioned that beyond the additional discussion in the security considerations you feel further changes to the main body would be necessary. Could you please elaborate, why, what you mean by that / what you think is missing or a problem? Tobias On 10/19/2010 06:29 PM, Denis Pinkas wrote: > Responses are in-line. > > > ----- Message reçu ----- > *De :* ltans-bounces > *À :* ltans > *Date :* 2010-10-18, 20:49:37 > *Sujet :* Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt > > Denis, > > My comments in-line > > > > Carl, > > > > 1 - You said: > > > > [Carl] DSSC applies at validation time. I agree with Tobias that > while > > one could package the policy with a data item it is not > necessary. It > > doesn't really matter what policy the LTA had in mind. > > What matters is that the evidence record passes the policy used > by the > > relying party. > > I see no reason to make a change to include DSSC policy in the > XMLERS > > format. > > > > Let us make a comparison with the concept of signature policy. > > Electronic sigantures comes with two flavors: BES (Basic ES) and > EPES > > (Explicit Policy ES). > > > > In EPES, the signature policy is indicated. My request is to be > able to > > incorporate the maintenance policy, like in EPES. > > You say you don't need it, like in BES. So let us make it OPTIONAL, > > which means that it will be possible to place it in the structure, > > whereas it is not the case today. > > We can evaluate this option and see if it fits as my concern is to > what > extent optional parameters are to be added. In case of maintenance > policy I would at least miss the original operation policy. With this > info one could decide on the reliability of ERS evidences and ERS > operation. > > I understand the first sentence, but not clearly the second one. > > > 2 - You said: > > > > [Carl] I disagree, for reasons you have cited in the past. There > will > > always be a grace period applied at validation time so this "MUST be > > proven at the time the new TST is applied" cannot be true. In any > > case, these sorts of issues are for the relying party to > appraise and > > the policies used by relying parties may vary, hence DSSC need > not be > > included. > > > > When you consider a grace period, the TST on the previous data > can be > > applied first and the CRL for the previous TST captured, e.g. 24 > hours > > later. > > Now what happens if the CRL is compromised or ceases to exist, so its > integrity is questionable? The information (CRL) provided after > TST does > not give any value at all only if it is ERSed as the rest of the > information. Similarly, the AES does not consider such approach. > > The AES (Advanced Electronic Signature) does support that case. > However, it does not mandate to support it, since the risk of a CRL > Issuer compromise > is much lower than the risk of the signer's key compromise. > > A second time stamp token can be placed on the references of the > certification path > including the revocation information. Since the references include a > hash of the values, > there is a full protection. For example, see XAdES-X type 2. > > > The DSCC information used at that time should also be added to the > > structure, before the new TST is applied. > > > > In this way, it will be possible to split the overall > verification by > > doing two sequences of verifications in any order: > > a) verifying the whole structure, making the assumption that > every DSCC > > information that has been used is correct, and > > b) verifying that every DSCC information placed in the structure > comes > > from a reliable source and was correct > > at the time indicated in the associated TST. > > > > The advantage is that check a) can be fully automated. > > Agree if the reason for DSSC inclusion stands. > > > Fine. > > > > > 3 - You said: > > > > [Carl] A security consideration on this topic seems like a > reasonable > > thing to do. Tobias, can you add a security consideration to address > > the separation of evidence record from policy? I think that will > close > > this issue. > > > > Addressing the issue in the security considerations is fine. > However, > > changes in the main body of the document are still necessary. > > As said before, optional element might be considered, however in this > case, I would say, the question remains open with the original ERS > syntax (I think you have mentioned that already). Security > considerations can be updated to address the above issues. > > > Indeed, ERS does not support these features. > > > > Aljosa > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans --------------040000050900090205000804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ok, let's try to resolve this.
Over the last three days I've been working on possible changes to the current draft that offer a way to store dssc in it. And I think I found options that could be done fairly straight forward, but will need to discuss the best options/wording with Aljosa tomorrow.
And I think we can add something to the security considerations, too.

Regarding Denis point #3: you mentioned that beyond the additional discussion in the security considerations you feel further changes to the main body would be necessary. Could you please elaborate, why, what you mean by that / what you think is missing or a problem?

Tobias



On 10/19/2010 06:29 PM, Denis Pinkas wrote:
Responses are in-line.
 
----- Message reçu -----
À : ltans
Date : 2010-10-18, 20:49:37
Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

Denis,

My comments in-line

 
> Carl,
>
> 1 - You said:
>
> [Carl] DSSC applies at validation time. I agree with Tobias that
while
> one could package the policy with a data item it is not necessary. It
> doesn't really matter what policy the LTA had in mind.
> What matters is that the evidence record passes the policy used by the
> relying party.
> I see no reason to make a change to include DSSC policy in the XMLERS
> format.
>
> Let us make a comparison with the concept of signature policy.
> Electronic sigantures comes with two flavors: BES (Basic ES) and EPES
> (Explicit Policy ES).
>
> In EPES, the signature policy is indicated. My request is to be able to
> incorporate the maintenance policy, like in EPES.
> You say you don't need it, like in BES. So let us make it OPTIONAL,
> which means that it will be possible to place it in the structure,
> whereas it is not the case today.

We can evaluate this option and see if it fits as my concern is to what
extent optional parameters are to be added. In case of maintenance
policy I would at least miss the original operation policy. With this
info one could decide on the reliability of ERS evidences and ERS
operation.

I understand the first sentence, but not clearly the second one.

> 2 - You said:
>
> [Carl] I disagree, for reasons you have cited in the past. There will
> always be a grace period applied at validation time so this "MUST be
> proven at the time the new TST is applied" cannot be true. In any
> case, these sorts of issues are for the relying party to appraise and
> the policies used by relying parties may vary, hence DSSC need not be
> included.
>
> When you consider a grace period, the TST on the previous data can be
> applied first and the CRL for the previous TST captured, e.g. 24 hours
> later.

Now what happens if the CRL is compromised or ceases to exist, so its
integrity is questionable? The information (CRL) provided after TST does
not give any value at all only if it is ERSed as the rest of the
information. Similarly, the AES does not consider such approach.

The AES (Advanced Electronic Signature) does support that case.
However, it does not mandate to support it, since the risk of a CRL Issuer compromise
is much lower than the risk of the signer's key compromise.

A second time stamp token can be placed on the references of the certification path
including the revocation information. Since the references include a hash of the values,
there is a full protection. For example, see  XAdES-X type 2.

 > The DSCC information used at that time should also be added to the
> structure, before the new TST is applied.
>
> In this way, it will be possible to split the overall verification by
> doing two sequences of verifications in any order:
> a) verifying the whole structure, making the assumption that every DSCC
> information that has been used is correct, and
> b) verifying that every DSCC information placed in the structure comes
> from a reliable source and was correct
> at the time indicated in the associated TST.
>
> The advantage is that check a) can be fully automated.

Agree if the reason for DSSC inclusion stands.
 
Fine.

 

> 3 - You said:
>
> [Carl] A security consideration on this topic seems like a reasonable
> thing to do. Tobias, can you add a security consideration to address
> the separation of evidence record from policy? I think that will
close
> this issue.
>
> Addressing the issue in the security considerations is fine. However,
> changes in the main body of the document are still necessary.

As said before, optional element might be considered, however in this
case, I would say, the question remains open with the original ERS
syntax (I think you have mentioned that already). Security
considerations can be updated to address the above issues.
 
Indeed, ERS does not support these features.

 

Aljosa
_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans


_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans

--------------040000050900090205000804-- From andreas.menke@openlimit.com Wed Oct 20 00:53:52 2010 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128643A690E for ; Wed, 20 Oct 2010 00:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.154 X-Spam-Level: X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVnXZ9zijE1V for ; Wed, 20 Oct 2010 00:53:49 -0700 (PDT) Received: from postrelay19.edis.at (postrelay19.edis.at [81.223.126.227]) by core3.amsl.com (Postfix) with ESMTP id F3AE23A69D2 for ; Wed, 20 Oct 2010 00:53:43 -0700 (PDT) Received: from mailrelay.edis.at (postrelay19.edis.at [81.223.126.227]) by postrelay19.edis.at (Postfix) with ESMTP id EC3E018099F4D for ; Wed, 20 Oct 2010 09:55:14 +0200 (CEST) Received: from ANDY-MOB ([::ffff:212.202.128.19]) (AUTH: LOGIN andreas.menke@openlimit.com) by mailrelay.edis.at with esmtp; Wed, 20 Oct 2010 09:55:13 +0200 id 000000000000085D.000000004CBEA061.00002357 Received: from ANDYMOB by ANDY-MOB (PGP Universal service); Wed, 20 Oct 2010 09:55:18 +0100 X-PGP-Universal: processed; by ANDY-MOB on Wed, 20 Oct 2010 09:55:18 +0100 From: "Andreas Menke" To: "'ltans'" References: In-Reply-To: Date: Wed, 20 Oct 2010 09:55:12 +0200 Organization: OpenLimit SignCubes GmbH Message-ID: <000901cb702c$2066efc0$6134cf40$@menke@openlimit.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActvsyyzlIysHeN6QZO5xtSGKkfERwABfdow Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CB703C.E3EFBFC0" Content-Language: de Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 07:53:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01CB703C.E3EFBFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello to all, =20 your discussion seems to me a bit misleading. In case I want to verify = an ERS I do it in my security context. We do NOT have a signing process = like AdES where we want to keep context information for use in future time as part of the signer role; we DO have a time-stamping process and we DO time-stamp for keeping cryptography at top of security. Nothing more. Everything else is part of private data which has to be kept in the data section. =20 The hard decision comes from the my fear of many different policies and = many different archives which could not interact (e.g. migration) because any policy and / or DSSC and so on is not understood by any archive system. = And that is worst case if a future archive cannot verify ERS without = breaking standard. =20 Kind Regards =20 Andreas Menke =20 ----------------------------- Andreas Menke Team Leader, Development Abteilungsleiter SecDocs =20 OpenLimit SignCubes GmbH Saarbr=FCcker Str. 38a D - 10405 Berlin =20 Tel: +49 30 400 3510 23 Fax: +49 30 400 3510 11 Mobil: +49 176 10 333 127 =20 E-Mail: andreas.menke@openlimit.com Web: http://www.openlimit.com/ =20 Gesch=E4ftsf=FChrer:=20 Marc Gurov, Armin Lunkeit, Nadine Model (Prokuristin), Dr. Stephan Lachmann (Prokurist) Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 86352 B Finanzamt f=FCr K=F6rperschaften II St.-Nr. 37/155/20819 USt-ID: DE 224136339 =20 OpenLimit unterst=FCtzt den Wettbewerb "Digitale Identit=E4t 2020", bei = dem junge Menschen das digitale Leben in 10 Jahren beschreiben und tolle = Preise gewinnen k=F6nnen. Bitte weitersagen! http://www.facebook.com/note.php?note_id=3D388251447004=20 =20 Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] Im Auftrag = von Denis Pinkas Gesendet: Dienstag, 19. Oktober 2010 19:29 An: ltans Betreff: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt =20 Responses are in-line. =20 ----- Message re=E7u -----=20 De : ltans-bounces=20 =C0 : ltans=20 Date : 2010-10-18, 20:49:37 Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt =20 Denis, My comments in-line =20 > Carl, >=20 > 1 - You said: >=20 > [Carl] DSSC applies at validation time. I agree with Tobias that while > one could package the policy with a data item it is not necessary. It > doesn't really matter what policy the LTA had in mind. > What matters is that the evidence record passes the policy used by the > relying party. > I see no reason to make a change to include DSSC policy in the XMLERS > format. >=20 > Let us make a comparison with the concept of signature policy. > Electronic sigantures comes with two flavors: BES (Basic ES) and EPES > (Explicit Policy ES). >=20 > In EPES, the signature policy is indicated. My request is to be able = to > incorporate the maintenance policy, like in EPES. > You say you don't need it, like in BES. So let us make it OPTIONAL, > which means that it will be possible to place it in the structure, > whereas it is not the case today. We can evaluate this option and see if it fits as my concern is to what extent optional parameters are to be added. In case of maintenance policy I would at least miss the original operation policy. With this info one could decide on the reliability of ERS evidences and ERS operation. I understand the first sentence, but not clearly the second one. > 2 - You said: >=20 > [Carl] I disagree, for reasons you have cited in the past. There will > always be a grace period applied at validation time so this "MUST be > proven at the time the new TST is applied" cannot be true. In any > case, these sorts of issues are for the relying party to appraise and > the policies used by relying parties may vary, hence DSSC need not be > included. >=20 > When you consider a grace period, the TST on the previous data can be > applied first and the CRL for the previous TST captured, e.g. 24 hours > later. Now what happens if the CRL is compromised or ceases to exist, so its integrity is questionable? The information (CRL) provided after TST does not give any value at all only if it is ERSed as the rest of the information. Similarly, the AES does not consider such approach. The AES (Advanced Electronic Signature) does support that case.=20 However, it does not mandate to support it, since the risk of a CRL = Issuer compromise=20 is much lower than the risk of the signer's key compromise. A second time stamp token can be placed on the references of the certification path=20 including the revocation information. Since the references include a = hash of the values,=20 there is a full protection. For example, see XAdES-X type 2.=20 > The DSCC information used at that time should also be added to the > structure, before the new TST is applied. >=20 > In this way, it will be possible to split the overall verification by > doing two sequences of verifications in any order: > a) verifying the whole structure, making the assumption that every = DSCC > information that has been used is correct, and > b) verifying that every DSCC information placed in the structure comes > from a reliable source and was correct > at the time indicated in the associated TST. >=20 > The advantage is that check a) can be fully automated. Agree if the reason for DSSC inclusion stands. =20 Fine.=20 =20 > 3 - You said: >=20 > [Carl] A security consideration on this topic seems like a reasonable > thing to do. Tobias, can you add a security consideration to address > the separation of evidence record from policy? I think that will close > this issue. >=20 > Addressing the issue in the security considerations is fine. However, > changes in the main body of the document are still necessary. As said before, optional element might be considered, however in this case, I would say, the question remains open with the original ERS syntax (I think you have mentioned that already). Security considerations can be updated to address the above issues. =20 Indeed, ERS does not support these features.=20 =20 Aljosa _______________________________________________ ltans mailing list ltans@ietf.org =20 https://www.ietf.org/mailman/listinfo/ltans ------=_NextPart_000_000A_01CB703C.E3EFBFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello to all,

 

your discussion seems to me a bit misleading. In case I = want to verify an ERS I do it in my security context. We do NOT have a signing = process like AdES where we want to keep context information for use in future time as = part of the signer role; we DO have a time-stamping process and we DO = time-stamp for keeping cryptography at top of security. Nothing more. Everything else = is part of private data which has to be kept in the data = section.

 

The hard decision comes from the my fear of many = different policies and many different archives which could not interact (e.g. = migration) because any policy and / or DSSC and so on is not understood by any = archive system. And that is worst case if a future archive cannot verify ERS = without breaking standard.

 

Kind Regards

 

Andreas Menke

 

-----------------------------
Andreas Menke
Team Leader, Development
Abteilungsleiter SecDocs

 

OpenLimit SignCubes GmbH

Saarbr=FCcker Str. 38a

D - 10405 Berlin

 

Tel:    +49 30 400 3510 = 23

Fax:    +49 30 400 3510 = 11

Mobil: +49 176 10 333 127

 

E-Mail:  andreas.menke@openlimit.co= m

Web:     http://www.openlimit.com/

 

Gesch=E4ftsf=FChrer:

Marc Gurov, Armin Lunkeit,

Nadine Model (Prokuristin),

Dr. Stephan Lachmann (Prokurist)

Sitz der Gesellschaft: Berlin

Amtsgericht Charlottenburg HRB 86352 = B

Finanzamt f=FCr K=F6rperschaften II

St.-Nr. 37/155/20819

USt-ID: DE 224136339

 

OpenLimit unterst=FCtzt den Wettbewerb "Digitale = Identit=E4t 2020", bei dem junge Menschen das digitale Leben in 10 Jahren = beschreiben und tolle Preise gewinnen k=F6nnen. Bitte = weitersagen!

http://www.fac= ebook.com/note.php?note_id=3D388251447004 =

 

Von:<= /b> ltans-bounces@ietf.org [mailto:ltans-bounces@iet= f.org] Im Auftrag von Denis Pinkas
Gesendet: Dienstag, 19. Oktober 2010 19:29
An: ltans
Betreff: Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt

 

Responses are in-line.

 <= /o:p>

----- Message re=E7u -----

=C0 : ltans

Date : 2010-10-18, 20:49:37

Sujet : Re: [ltans] I-D = ACTION:draft-ietf-ltans-xmlers-07.txt

 <= /o:p>

Denis,

My comments in-line

 
> Carl,
>
> 1 - You said:
>
> [Carl] DSSC applies at validation time. I agree with Tobias = that
while
> one could package the policy with a data item it is not necessary. = It
> doesn't really matter what policy the LTA had in mind.
> What matters is that the evidence record passes the policy used by = the
> relying party.
> I see no reason to make a change to include DSSC policy in the = XMLERS
> format.
>
> Let us make a comparison with the concept of signature policy.
> Electronic sigantures comes with two flavors: BES (Basic ES) and = EPES
> (Explicit Policy ES).
>
> In EPES, the signature policy is indicated. My request is to be = able to
> incorporate the maintenance policy, like in EPES.
> You say you don't need it, like in BES. So let us make it = OPTIONAL,
> which means that it will be possible to place it in the = structure,
> whereas it is not the case today.

We can evaluate this option and see if it fits as my concern is to = what
extent optional parameters are to be added. In case of maintenance
policy I would at least miss the original operation policy. With = this
info one could decide on the reliability of ERS evidences and ERS
operation.

I understand the first sentence, but not clearly the second = one.

> 2 - You said:
>
> [Carl] I disagree, for reasons you have cited in the past. There = will
> always be a grace period applied at validation time so this = "MUST be
> proven at the time the new TST is applied" cannot be true. In = any
> case, these sorts of issues are for the relying party to appraise = and
> the policies used by relying parties may vary, hence DSSC need not = be
> included.
>
> When you consider a grace period, the TST on the previous data can = be
> applied first and the CRL for the previous TST captured, e.g. 24 = hours
> later.

Now what happens if the CRL is compromised or ceases to exist, so = its
integrity is questionable? The information (CRL) provided after TST = does
not give any value at all only if it is ERSed as the rest of the
information. Similarly, the AES does not consider such = approach.

The AES (Advanced Electronic Signature) does support that case.
However, it does not mandate to support it, since the risk of a CRL = Issuer compromise
is much lower than the risk of the signer's key = compromise.

A = second time stamp token can be placed on the references of the certification = path
including the revocation information. Since the references include a = hash of the values,
there is a full protection. For example, see  XAdES-X type 2. =

 > The DSCC information used at that time should also be added to the
> structure, before the new TST is applied.
>
> In this way, it will be possible to split the overall verification = by
> doing two sequences of verifications in any order:
> a) verifying the whole structure, making the assumption that every = DSCC
> information that has been used is correct, and
> b) verifying that every DSCC information placed in the structure = comes
> from a reliable source and was correct
> at the time indicated in the associated TST.
>
> The advantage is that check a) can be fully automated.

Agree if the reason for DSSC inclusion stands.

 <= /o:p>

Fine.

 <= /o:p>

> 3 - You said:
>
> [Carl] A security consideration on this topic seems like a = reasonable
> thing to do. Tobias, can you add a security consideration to = address
> the separation of evidence record from policy? I think that = will
close
> this issue.
>
> Addressing the issue in the security considerations is fine. = However,
> changes in the main body of the document are still necessary.

As said before, optional element might be considered, however in = this
case, I would say, the question remains open with the original ERS
syntax (I think you have mentioned that already). Security
considerations can be updated to address the above = issues.

 <= /o:p>

Indeed, ERS does not support these features.

 <= /o:p>

Aljosa
_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org= /mailman/listinfo/ltans

------=_NextPart_000_000A_01CB703C.E3EFBFC0--