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

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 13 Sep 2010 17:48:05 +0200

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

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 13 Sep 2010 18:38:14 +0100

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

> Section 1.1 should be revised to mention the differences with a
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.

> 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.
 
> validation policies should be supported, since validation policies
> that will exist 30 years from now are still unknown. 
>  
> 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)

> 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:[email-masked]>
>     *À :* ltans <mailto%20:[email-masked]>
>     *Date :* 2010-08-23, 21:08:54
>     *Sujet :* Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
>
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     On Behalf
>     > Of [email-masked] <mailto:[email-masked]>
>     > To: [email-masked] <mailto:[email-masked]>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 14 Sep 2010 12:33:54 +0200

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

  

  

  

  
For example, ERS states:  

While the draft states:  

  

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.
[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.
  2) Page 43 states:  

  

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. 

  

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

Syntax
non-

---

From: "Aljosa Jerman Blazic" <[email-masked]>
Date: Sat, 25 Sep 2010 15:19:38 +0200

Denis, Tobias

It took me a while to get back to XMLERS and my answers are in line.

> 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
> 	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
> 
> 
> 	In theory we could have added XMLERS to ERS, but XML puts
> different processing issues to the document,
> 	a well-thought XML structure, plus identifiers to be assigned by
> IANA for certain types. All these items are not

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.
> 
> 		  2) Page 43 states:
> 
> 		it is abnormal that the problems highlighted in RFC 5698
> are not covered by this draft. In order to
> 	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.

Point taken.

> 		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.
> 
> 		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.
> 
> 
> 
> 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.
> 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.
> 
> In order to verify the structure, I first look at the OID/URN from the
> "algorithm maintenance policy" and if I find it acceptable,
> 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,
> The implication is to add to the current structure a new field to
> indicate the OID/URN of the "algorithm maintenance policy"

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

> 	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
> 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
> [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,

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
> 	As I understand it, TSU key compromission would lead to
> revocation of its certificate and loss of validity.
> 	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
> 	As the detailed valuation of such events and legal requirements
> may vary by country, it seemed prudent to describe things
> [Denis] As the document does not sufficiently deal with the
> verification of the data structure, the case of TSU compromission
> In short, if when applying a new TST, the TSU certificate is marked as
> revoked, this is not a problem if the revocation reason
> 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.

Aljosa

> 			> From: [email-masked] <mailto:%20ltans-
> [email-masked]>  [mailto:[email-masked] <mailto:%20ltans-
> [email-masked]> ] On Behalf

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 25 Sep 2010 19:26:18 +0100

I basically agree with Aljosa. More detailed answers in line
- Tobias

>> that people may understand better why there has been no translation of
[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?

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

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

>> the current XMLERS draft is not usable in practice (i.e. there is no
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.)

> 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,…

I fully agree with Aljosa's argument (and disagree with you Denis).

Tobias