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

[Tobias Gondrom <[e-mail]>]

 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.

>   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.
 
> 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.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)

>  
> 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
>
>     ----- Message reçu -----
>     *De :* ltans-bounces <mailto%20:[e-mail]>
>     *À :* ltans <mailto%20:[e-mail]>
>     *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:[e-mail]>
>     [mailto:[e-mail] <mailto:[e-mail]>]
>     On Behalf
>     > Of [e-mail] <mailto:[e-mail]>
>     > Sent: Monday, August 23, 2010 2:00 PM
>     > To: [e-mail] <mailto:[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