Carl,
ERS + LTAP do not meet the requirements.
In order to understand LTAP, there is the need to wait until page 28,
where the operations are only sketched :
- The ARCHIVE operation applies to "rawData and a messageDigest"
without any information on these two pieces of information and
their relationship, if any, with ERS.
- The STATUS operation is hardly defined.
- The EXPORT operation returns "data and metadata of the object"
without any information on these two pieces of information and
their relationship, if any, with ERS.
- The DELETE operation "returns the updated metadata (or nothing)"
without any information on this piece of information and its relationship,
if any, with ERS.
The archival policy, the archival time period and the crypto maintenance policy
are never mentioned.
Since they are currently not part of ERS, they appear nowhere.
It is never mentioned that a response is signed.
ERS + LTAP contain no signature from a LTA agent.
About the DELETE operation, what is worse is the following sentence: "Note that
this does not mean that
the server does not maintain a trace record of the delete operation". A trace
record would not be sufficient.
Deletion of an archive shall normally not happen, since the LTA is trusted to
keep the data until the end of
the archive period. A signed permission of deletion, by the owner of the data
shall be given, before deletion
can occur. This is mentioned nowhere in the document.
Once again, the current set of documents does not meet the requirements.
I guess you reacted too quickly to my proposal from yesterday and you should
pay more attention to it.
Denis
Denis,
Thanks for the analysis. Regarding:
ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?
We've been proceeding with ERS + LTAP intended to meet the requirements, not
ERS in isolation. Thus, some of the information you mentioned is addressed at
the protocol level, not in the evidence record. I think this is certainly true
of items 1, 2 and 4. For item 3, the service can provide the evidence without
contributing signatures to the evidence record. It simply has to be trusted to
take the appropriate renewal actions at the right times. For item 7, the
period is implied by the time in the innermost timestamp and the outermost
timestamp and the evidence record is itself the evidence being provided.
For items 5 and 6, I agree that the ArchiveTimestamp is probably the best place
to represent the policies to meet this requirement. Since these values can
change over time, they are not as easily represented in an outer wrapper
applied at the protocol level. Perhaps the following:
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
policy [1] OBJECT IDENTIFIER OPTIONAL,
timeStamp ContentInfo}
Using this structure, the policy would be asserted when a renewal is performed.
Carl
________________________________
From: owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis
Pinkas
Sent: Monday, January 15, 2007 9:59 AM
To: ietf-smime(_at_)imc(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org; 'Russ Housley'
Subject: Re: Cross review of draft ERS from LTANS WG until Jan 23 rd
I said in an earlier e-mail: "The WG has to justify why it would not
fulfill its needs".
Carl has provided interesting information to explain the differences
with ISO ISO-18014-3
and why ERS is different. The main advantage is the use of "ordinary"
time-stamps rather
than time-stamps with specific extensions. However, this information
should not be lost
and be used to write an informative annex.
There are indeed much more important topics.
ERS is supposed to respond to draft-ietf-ltans-reqs-10.txt, isn'it ?
However, many of the requirements that are present in the requirements
document
are not met by the current ERS draft.
Here are a few examples :
1. ltans-reqs-10 defines an Archival Period as "The period
during which an archived
data object is preserved by a long-term archive service". How may a
long term-archive
service be held responsible of storing the data during that
time-period, since
the information to know the time period is not present in the ER ?
2. ltans-reqs-10 defines a Cryp!
tographic Maintenance Policy. There is no corresponding
element in ERS. How can a long term-archive service know which
maintenance to apply,
since the information to perform the maintenance correctly is not
present in ER ?
3. ltans-reqs-10 states on page 7: A long-term archive service
provides evidence
that may be used to demonstrate the existence of an archived data
object at a given time
and the integrity of the archived data object since that time. The ER
is supposed
to be the basic piece of data to support that evidence. However, it is
not signed
by the long term-archive service, thus it cannot be used "to
demonstrate the existence
of an archived data object at a given time and the integrity of the
archived data object
since that time".
4. ltans-reqs-10 adds on page 7: "Additionally, the evidence
identifies the LTA(s)
that have participated in the preservation of the archived data
object". However,
ER does not contain the names of the LTA(s) that have participated in
the preservation
of the archived data object.
5. ltans-reqs-10 states on page 9: "A long-term archive service
must operate in accordance
with a long-term archive service policy that defines characteristics of
the implementation
of the long-term archive service". However, ER does not contain a data
item to support
the "long-term archive service policy".
6. ltans-reqs-10 adds on page 10: " Over the course of many
years, the policies under which
an LTA operates may undergo modification. Thus, an evidence record may
feature multiple
indications of policies active at various points during the life of an
archived data object."
However, the ER does not contain such an information.
7. ltans-reqs-10 states on page 11: "A long-term archive
service must be capable of providing
evidence that can be used to demonstrate the integrity of data for
which it is responsible
from the time it received the data until the expiration of the archival
period of the data".
However, no data item is specified in ER to provide this evidence.
This means that much work is still needed on the document to fulfill
the requirements.
Now, let us see what should be done. The following is obviously an
unpolished strawman proposal.
In order to reduce the number of time stamps, it is necessary to be
able to aggregate data
before applying a time stamp on it. For doing it, the following
structure (close to the
structure of ArchiveTimeStamp, but different) would fulfill the need).
TimeStampedNode ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
archivalPolicy ArchivalPolicy,
archivalTimePeriod ArchivalTimePeriod,
cryptoMaintenancePolicy CryptoMaintenancePolicy,
reducedHashtree SEQUENCE OF PartialHashtree,
timeStamp TimeStampToken }
PartialHashtree ::= SEQUENCE OF OCTET STRING
ArchivalPolicy::= OBJECT IDENTIFIER
ArchivalTimePeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime }
CryptoMaintenancePolicy would need more work to be defined, but
basically
would contain a sequence of algorithm identifiers with their
parameters.
The CryptoMaintenancePolicy applies to the data in the tree and to the
crypto of
the time stamp token.
The hash included in the TimeStampToken is computed on the
reducedHashtree element.
If this structure is signed by an agent from an archival service, then
it can be used
to demonstrate that a given agent from an LTA has accepted to archive,
under a given
policy for a given time period, the data items that are under the hash
tree.
This means that TimeStampedNode must be the eContent of a CMS message
signed by
an LTA agent in order to form a SignedNode.
Later on, the same, another or more LTA agents may need to add some
other data to
a signed Node, without loosing the previous time-stamp and signature.
This leads to the following structure:
EvidenceNode ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
archivalPolicy ArchivalPolicy,
archivalTimePeriod ArchivalTimePeriod,
cryptoMaintenancePolicy CryptoMaintenancePolicy,
evidenceRecord EvidenceRecord,
-- the evidence record that serves
-- for the construction
signedNodeSequence SignedNodeSequence OPTIONAL,
-- the elements that are added
-- to the previous evidence
timeStamp TimeStampToken }
with:
signedNodeSequence ::= SEQUENCE OF SignedNode
The CryptoMaintenancePolicy applies to the previous evidence record, to
all
the data that are in the tree and to the crypto of the time stamp
token.
The hash included in the TimeStampToken is computed on the
concatenation of the
evidenceRecord element and of the signedNodeSequence element.
This means that EvidenceNode must be the eContent of a CMS message
signed by
an LTA agent in order to form an EvidenceRecord.
This new proposal fulfills the seven requirements mentioned here above.
Denis
________________________________
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
________________________________