Nearly no comments were sent on the LTANS mailing list on these documents.
It may be questionable why. The fact is that these documents are badly written,
and thus it takes an enormous amount of time to attempt to understand them.
Even though, most readers will fail, but will not dare to report that they did.
I am unsure that I understood them, but I dare to report it.
This draft and its companion documents namely draft-ietf-ltans-ari-00 and
draft-ietf-ltans-validate-00 raise a number of questions to be solved.
Let us look now at the details of ERS.
No ASN.1 compiler has been used to validate the syntax, otherwise,
it would have been noticed that there is an obvious ASN.1 error on
EvidenceRecord.
EvidenceRecord ::= SEQUENCE {
version INTEGER { v1(1) } ,
digestAlgorithms SEQUENCE OF AlgorithmIdentifier,
cryptoInfos [0] CryptoInfos OPTIONAL,
encryptionInfo [1] EncryptionInfo OPTIONAL,
archiveTimeStampSequence ArchiveTimeStampSequence,
...
}
Later on the text defines ArchiveTimeStampSequence as:
ArchiveTimeStampSequence ::= SEQUENCE OF
ArchiveTimeStampChain
and
ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
and
ArchiveTimeStamp ::= SEQUENCE {
digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
timeStamp ContentInfo}
PartialHashtree ::= SEQUENCE OF OCTET STRING
Note that this information is spread all around the document,
rather than presented in sequence which does not ease its reading.
ContentInfo is supposed to carry a TST. This means that timeStamp
should be defined as TimeStampToken rather than ContentInfo.
There is no explanation in section 4.1 (top of page 11) to know on which data
the digest
contained in the TimeStampToken is computed.
If another kind of time-stamp token would need to be carried, the syntax
would need to be changed. This comes into contradiction with the following
sentence :
Other types of timestamp MAY be used, if they contain time data,
timestamped data and a cryptographically secure confirmation from the
TSA of these data.
CryptoInfos from EvidenceRecord should be suppressed, since it is not proven
that this additional item will ever be useful: encryption techniques may be
different
for each data item and thus cannot apply globally at the level of an
EvidenceRecord.
EncryptionInfo should be suppressed too. No interoperability can be obtained on
these two fields using this specification.
ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain which is itself
a sequence of ArchiveTimeStamp. However, there is no way to make a difference
between
an ArchiveTimeStampChain and an ArchiveTimeStampSequence.
If within an EvidenceRecord, one element within of an archiveTimeStampSequence
is suppressed (e.g. a ArchiveTimeStamp) this is not detectable. What is the
real value
of the EvidenceRecord structure ? One would expect that an EvidenceRecord
includes
a time stamp. However, it does not not.
The current draft does not allow to apply the processing recursively. Having
constructed
one EvidenceRecord (that would include a time stamp), it is currently not
possible to construct
another one using a previous one.
This document is supposed to apply to a long term archive service. However,
there is no signature
from an archive service. The TSA should not be confused with a Archive
Authority. With the current
structure the Archive service may not be held responsible of the storage of the
data.
The draft claims to protect against weak algorithms or keys. However, it does
not make
a clear and clean separation between the cases of :
- the key of a Time-Stamping Unit has been compromised,
- an asymmetric algorithm has been broken for a given key size,
- a hash algorithm exhibits collisions.
With ?Timestamp renewal? the text omits to say that it is necessary using ?out
of bands
means? that a given key from a Time Stamping Unit has been compromised or a
that given
asymmetric algorithm has been broken for a given key size.
?Hash-Tree renewal? would apply when hash algorithm exhibits collisions.
However a complete
reconstruction is needed and it is not clearly explained which data from the
previous structure
may re-used.
Appendix A contains an annex and it is not said whether it is informative or
normative.
Nevertheless, the benefits of the inclusion of an EvidenceRecord as an unsigned
attribute
are not explained. The advantages and drawbacks of each case is not explained
either.
CONCLUSION
In my opinion, none of these documents is ready to be sent to the IESG and
it does not make sense to send ERS alone. The usefulness of the whole work
is very questionable. These documents are not mature and contain numerous typos.
The primary question is : ? Is this work really needed ??. SC 27 has issued ISO
18014-3:
?Time-stamp services. Mechanisms producing linked tokens? that is very close.
It would be interesting that the authors position their documents towards
the ISO standard. Duplication of work should be avoided. If there is no
duplication,
then this should be explained in an informative annex. If no acceptable
explanations
may be given, then this work should be stopped.
P.S. I spent several hours to read the documents and to write this message,
but I do not have the time available to sustain long discussions on
that topic.
Denis
Hello dear SMIME WG,
at the last meeting of the LTANS WG in San Diego, Russ recommended to
ask your WG for a cross review of the ERS draft in its final stage (it
is currently in WGLC).
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt
It would be nice if some of you could read the draft, review it and
provide your feedback.
(As probably most of you already know the draft is about the data
structure for an Evidence Record to ensure and protect integrity of data
and signatures even when the algorithms used at signing time become
insecure at a later point in time.)
WG Last Call runs until January 23rd.
If some of you need longer, please send me a note about how much time
you need.
Thank you very much for your help, Tobias
Chair of LTANS
-----Original Message-----
From: Tobias Gondrom
Sent: Tuesday, January 09, 2007 8:12 PM
To: ietf-ltans(_at_)imc(_dot_)org
Cc: 'Carl Wallace'
Subject: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd
Importance: High
Hello dear LTANS WG,
with the small adjustments made in version-9, based on the discussion
at
the meeting in San Diego, I again initiate the formal final WG last
call.
(Hopefully this time it will really be the last one ;-) )
Additionally I will also ask the SMIME WG for cross review of the
draft as
it has been discussed and decided at the last meeting in San Diego.
WG Last Call closes on January 23rd. After which the revised document
will
hopefully be ready for submission to the IESG.
Thank you, Tobias
Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now
in
its final preparation phase by the IETF editor team.
-----Original Message-----
From: owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
ltans(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Internet-Drafts(_at_)ietf(_dot_)org
Sent: Friday, January 05, 2007 12:50 AM
To: i-d-announce(_at_)ietf(_dot_)org
Cc: ietf-ltans(_at_)imc(_dot_)org
Subject: I-D ACTION:draft-ietf-ltans-ers-09.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 : Evidence Record Syntax (ERS)
Author(s) : R. Brandner, et al.
Filename : draft-ietf-ltans-ers-09.txt
Pages : 29
Date : 2007-1-4
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.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the
body
of
the message.
You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-ietf-ltans-ers-09.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv(_at_)ietf(_dot_)org(_dot_)
In the body type:
"FILE /internet-drafts/draft-ietf-ltans-ers-09.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail
readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.