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

["Carl Wallace" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Tobias Gondrom
> Sent: Saturday, September 25, 2010 2:26 PM
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] 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çu -----
> >> 	De : ltans-bounces
> >> 	À : 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
> >> 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.)
> 
> 
> > 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çu -----
> >> 			De : ltans-bounces
> >> 			À : 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: [e-mail] <mailto:%20ltans-
> >> [e-mail]>  [mailto:[e-mail] <mailto:%20ltans-
> >> [e-mail]> ] On Behalf
> >> 			> Of [e-mail] <mailto:%20Internet-
> >> [e-mail]>
> >> 			> Sent: Monday, August 23, 2010 2:00 PM
> >> 			> To: [e-mail] <mailto:%20i-d-
> >> [e-mail]>
> >> 			> Cc: [e-mail] <mailto:[e-mail]>
> >> 			> 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
> >> 			[e-mail] <mailto:[e-mail]>
> >> 			https://www.ietf.org/mailman/listinfo/ltans
> >>
> >>
> >>
> >>
> >> 		_______________________________________________
> >> 		ltans mailing list
> >> 		[e-mail]
> >> 		https://www.ietf.org/mailman/listinfo/ltans
> >>
> > _______________________________________________
> > ltans mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ltans
> 
> _______________________________________________
> ltans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltans