Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call:draft-ietf-ltans-ers-09.txt- untilJan 23rd

From: "Tobias Gondrom" <[email-masked]>
Date: Thu, 11 Jan 2007 19:19:53 +0100

Tony and Denis,

about 12 months LTANS investigated and discussed the relationship and
use of other timestamps from the ISO-18014 family. 

The result was that ISO-18014 timestamps/tokens could be used instead of
the RFC-3161 timestamps within the ERS structure. 

18014-3 definitely can not replace or even be directly compared to ERS -
both specs refer to different goals and technical concepts. 

It would be like comparing apples and oranges, to use a metaphor (for a
comparison which is not valid). 

Tobias

________________________________

From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 6:08 PM
To: Tony Capel; 'Denis Pinkas'; [email-masked]
Cc: [email-masked]; Tobias Gondrom; 'Russ Housley'
Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG - RE: WG
Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

Tony,

I think Denis should provide additional details when calling for a
working group item to be dropped, especially when making this request
this late in the process with non-freely available documents as the
basis.  However, I'll try to make the case in the other direction.

I don't think it's simply a case of too many options that require
profiling.  One motivation often cited during the development of ERS is
support for aggregations of data.  This is represented in ERS via the
reducedHashtree field in the ArchiveTimeStamp structure.  This field and
the related ArchiveTimeStampChain and ArchiveTimeStampSequence
structures allow handling of the aggregation when the initial timestamp
is generated, when simple timestamp renewal is required as well as when
simple timestamp renewal is not sufficient and the original data must be
hashed again.

The ISO spec uses the ExtRenewal extension for timestamp renewal.  This
is roughly analogous to the timestamp renewal feature in ERS.  However,
there does not seem to be sufficient support for cases where the hash
algorithm is updated and the original data must be rehashed.  In ERS,
when a hash algorithm update is necessary, the preceding timestamp
tokens are hashed along with the original data.  In the ISO spec, an
existing timestamp token is presented for renewal but the original data
is not.  It may be possible to make this work using the extHash
extension, but I don't see any description of this in the current spec
(nor do I see any text that describes verification of the ExtRenewal
extension).  I don't follow how the aggregation mechanisms in the ISO
spec can be used to aggregate data for the initial timestamp well enough
to compare them to ERS.  

ERS support for aggregation is more clearly stated and ERS provides more
complete handling of renewal operations.  For these reasons, I think we
should proceed with ERS instead of trying to enhance the ISO spec.

Carl

________________________________

	From: Tony Capel [mailto:[email-masked]] 
	Sent: Thursday, January 11, 2007 11:04 AM
	To: 'Carl Wallace'; 'Denis Pinkas'; [email-masked]
	Cc: [email-masked]; 'Tobias Gondrom'; 'Russ Housley'
	Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG -
RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

	Carl:

	I think Denis asks simply for the justification for the
introduction of new technology to solve a problem which may already be
solved with an existing ISO standard (which has already been published
and is presumably more mature than what is being proposed).

	Denis notes (in his previous comment) that perhaps the ISO
standard offers too many options and that perhaps a Profile of this ISO
standard might be published as an RFC to tailor the ISO standard for the
specific application(s) you have in mind.  In such a case the RFC should
profile (see ISO/IEC TR10000) the ISO standard and not introduce new
technology.

	Tony

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Carl Wallace
	Sent: January 11, 2007 10:16 AM
	To: Denis Pinkas; [email-masked]
	Cc: [email-masked]; Tobias Gondrom; Russ Housley
	Subject: RE: RE: RE: Cross review of draft ERS from LTANS WG -
RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

	My response wasn't a reversal of the question but a request for
details.  Folks on the list have previously discussed these
specifications, including their use within an EvidenceRecord.  You made
a sweeping comment that lacked any details and called for fairly drastic
measures.  I simply asked for justification.

________________________________

		From: Denis Pinkas [mailto:[email-masked]] 
		Sent: Thursday, January 11, 2007 9:46 AM
		To: Carl Wallace; [email-masked]
		Cc: [email-masked]; Russ Housley; Tobias Gondrom
		Subject: Re: RE: RE: Cross review of draft ERS from
LTANS WG - RE: WG Last Ca ll:draft-ietf-ltans-ers-09.txt- untilJan 23rd

		Carl,

		Please do not reverse the question. ISO 18014-3 already
exists. The WG has to justify why it would not fulfill its needs.

		I will refine my question: Why is a profile of ISO
18014-3 not adequate to fulfill the needs ?

		A profile would make sense, since ISO 18014-3 has many
options.

		Denis