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

From: "Carl Wallace" <[email-masked]>
Date: Fri, 8 Oct 2010 11:52:10 -0400

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 12 Oct 2010 15:20:05 +0200

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

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 13 Oct 2010 07:46:28 -0400

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

From: [email-masked] [mailto:[email-masked]] 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

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

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

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

[Denis] 

I said earlier:

You replied:

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

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

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

Denis

	----- Message reçu ----- 

	De : ltans-bounces 

	À : Tobias Gondrom,ltans 

	
	> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf
	> Of Tobias Gondrom
	> To: [email-masked] <mailto:[email-masked]> 
	> >> From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On
	> Behalf
	> >> Of Denis Pinkas
	> >> > From: [email-masked] <mailto:[email-masked]>  <mailto:%20ltans-
	> >> [email-masked] <mailto:[email-masked]> > [mailto:[email-masked] <mailto:[email-masked]>  <mailto:%20ltans-
	> >> [email-masked] <mailto:[email-masked]> > ] On Behalf
	> >> > Of [email-masked] <mailto:[email-masked]>  <mailto:%20Internet-
	> >> [email-masked] <mailto:[email-masked]> >
	> >> > To: [email-masked] <mailto:[email-masked]>  <mailto:%20i-d-
	> >> [email-masked] <mailto:[email-masked]> >
	> >> > Cc: [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
	> >> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 18 Oct 2010 13:40:22 +0200

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.
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.
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.
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.
Denis
----- Message reçu ----- 
De : ltans-bounces 
À : denis.pinkas,tobias.gondrom,ltans 
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)…

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

Denis

---

From: "Aljosa Jerman Blazic" <[email-masked]>
Date: Mon, 18 Oct 2010 20:49:37 +0200

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

Agree if the reason for DSSC inclusion stands.

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

Aljosa

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 19 Oct 2010 19:29:13 +0200

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

while
> In EPES, the signature policy is indicated. My request is to be able to

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

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. 
> a) verifying the whole structure, making the assumption that every DSCC

Fine.

close

Indeed, ERS does not support these features.

Aljosa

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 20 Oct 2010 00:46:46 +0100

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 <mailto%20:[email-masked]>
>     *À :* ltans <mailto%20:[email-masked]>
>     *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:
>     >
>     > 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.
>     >
>     > Electronic sigantures comes with two flavors: BES (Basic ES) and
>     EPES
>     > (Explicit Policy ES).
>     >
>     > b) verifying that every DSCC information placed in the structure
>     comes
>     > from a reliable source and was correct

---

From: "Andreas Menke" <[email-masked]>
Date: Wed, 20 Oct 2010 09:55:12 +0200

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ücker 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:   <mailto:[email-masked]>
[email-masked]

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

Geschäftsführer: 

Marc Gurov, Armin Lunkeit,

Nadine Model (Prokuristin),

Dr. Stephan Lachmann (Prokurist)

Sitz der Gesellschaft: Berlin

Amtsgericht Charlottenburg HRB 86352 B

Finanzamt für Körperschaften II

St.-Nr. 37/155/20819

USt-ID: DE 224136339

OpenLimit unterstützt den Wettbewerb "Digitale Identität 2020", bei dem
junge Menschen das digitale Leben in 10 Jahren beschreiben und tolle Preise
gewinnen können. Bitte weitersagen!

 <http://www.facebook.com/note.php?note_id=388251447004>
http://www.facebook.com/note.php?note_id=388251447004 

Von: [email-masked] [mailto:[email-masked]] 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.

----- Message reçu ----- 

De : ltans-bounces 

À : ltans 

Denis,

My comments in-line

while

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. 

Fine. 

close

Aljosa