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:capel(_at_)comgate(_dot_)com]
Sent: Thursday, January 11, 2007 11:04 AM
To: 'Carl Wallace'; 'Denis Pinkas'; ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org; '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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Carl Wallace
Sent: January 11, 2007 10:16 AM
To: Denis Pinkas; ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org; 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:denis(_dot_)pinkas(_at_)bull(_dot_)net]
Sent: Thursday, January 11, 2007 9:46 AM
To: Carl Wallace; ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org; 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