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

["Denis Pinkas"<[e-mail]>]

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


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.
  
 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:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Monday, August 23, 2010 2:00 PM
> To: [e-mail]
> Cc: [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]
https://www.ietf.org/mailman/listinfo/ltans