[Top] [All Lists]

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

2007-01-11 03:54:19

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 ::= 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 ::= SEQUENCE OF ArchiveTimeStamp


   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 
for each data item and thus cannot apply globally at the level of an 
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 
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 
a time stamp. However, it does not not.

The current draft does not allow to apply the processing recursively. Having 
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 

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 
Nevertheless, the benefits of the inclusion of an EvidenceRecord as an unsigned 
are not explained. The advantages and drawbacks of each case is not explained 


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 
?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 
then this should be explained in an informative annex. If no acceptable 
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.


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

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
the meeting in San Diego, I again initiate the formal final WG last
(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
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
its final preparation phase by the IETF editor team.

-----Original Message-----
From: owner-ietf-ltans(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
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
This draft is a work item of the Long-Term Archive and Notary
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
   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:

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 
the message.
You can also visit
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

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
   "FILE /internet-drafts/draft-ietf-ltans-ers-09.txt".

NOTE:      The mail server at 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
   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

<Prev in Thread] Current Thread [Next in Thread>