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

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 11 Jan 2007 11:20:15 +0100

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: [email-masked]
>> 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: [email-masked] [mailto:owner-ietf-
>> [email-masked]]
>> > On Behalf Of [email-masked]
>> > Sent: Friday, January 05, 2007 12:50 AM
>> > To: [email-masked]
>> > Cc: [email-masked]
>> > 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
>> > [email-masked] 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:
>> > 	[email-masked].
>> > 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.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 11 Jan 2007 07:59:32 -0500

Comments inline... 

> From: Denis Pinkas [mailto:[email-masked]] 
> Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG 
> Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd
> 
> 

There is just one document that has been submitted for working group last
call.

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

These two drafts were prepared quickly in advance of the last working group
meeting.  During the meeting, a call was made for additional co-authors to
help clarify and complete the documents.  One person has joined Tobias in
this effort but no follow-up drafts have been released yet.

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

The ASN.1 was changed as a result of comments during the previous working
group last call.  Minor errors can be corrected without much cause for
alarm.  I assume in this case you are referring to the missing 's' at the
end of EncryptionInfo.  Also, the id-EvidenceRecord-Internal and
id-EvidenceRecord-External values are missing OBJECT IDENTIFIER.  

>                                 ArchiveTimeStampChain and 
> 
> ContentInfo is supposed to carry a TST. This means that 
> timeStamp should be defined as TimeStampToken rather than ContentInfo.

timeStamp was defined as a ContentInfo to allow a type other than
TimeStampToken to be used.  

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

This info appears in Section 4 (middle of page 10): "The root hash value,
which represents unambiguously all data objects, is timestamped."

> 
> 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 :
> 

See above.

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

This comment was made during a previous last call and resulted in Tobias'
posting to the list a few instances of structures that could be conveyed in
these fields.  These could be defined in a peer document or defined in this
draft.
 
> 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. 

The two are not used interchangably.  Why is this a problem?
 
> 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.

Why would one element be suppressed?  What would you want to have happen in
this case?  As-is, verification would fail.  I have commented previously
that it might be better if the chain supported shallow verification, which
would enable you to suppress a contiguous set of elements from the beginning
of the chain up to the point from which verification was desired.  There was
no support for making a change along these lines, and there seemed to be no
real need to have this feature.  

What do you mean the EvidenceRecord does not include a timestamp?  It
includes ArchiveTimeStampSequence, which may have one or more timestamps.
 
> 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. 

An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence.  The
draft describes how to add additional ArchiveTimeStamps to the last
ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a
new ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I don't disagree
that trying to follow discussion of these three similarly-named structures
is difficult, but have failed to come up with clearer alternative
suggestions.  
 
> 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.

This document defines a syntax for representing a chain of cryptographic
evidence.  This syntax may be used by an archive service.  However, no
archive service is required to produce an evidence record.  Archive service
signatures are addressed in the context of a protocol for interacting with
an archive service.
 
> The draft claims to protect against weak algorithms or keys. 
> However, it does not make a clear and clean separation 
> between the cases of :
> 
> 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 

This should be clarified.

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

Good point.

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

We should not cloud the review of ERS by referring to typos in -ari and
-validate.
 
> 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.

The ISO drafts have been discussed on the list and are referenced by this
document as a source for alternative timestamp formats.

> discussions on that topic.

Thanks for the review.

---

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

Hi Denis, 

Thank you for your time and the review. As Carl already commented on
most of your comments, and I fully agree with him, I will only add a few
things:

1. At first to set one thing straight:

The ERS document has been discussed extensively over the last two years
and there have been literally hundreds of emails with comments and
discussion about it on the mailing-list and there are world wide several
companies who already implemented ERS some months ago (based o the draft
versions 5-8 which are very similar to version 9). So I can only assume
that you are not talking about ERS but about validate or ari, which are
like add-ons to explain ERS further but still very young  - those two
documents documents are NOT in WGLC - only ERS!

(note: the work on the next version of validate with the new second
author is currently in progress and a new version should be ready in
about 3-4 weeks.)

2. I will propose to LTANS improvements according to the last two
comments in your review: 

a) make the separation of the protection mechanisms clearer 

and

b) clarify whether Appendix A's annex is informative or normative and
explain the benefits of including an EvidenceRecord as an unsigned
attribute.

So again also from my side, thank you for your review.

            Tobias

 

________________________________

From: Carl Wallace [mailto:[email-masked]] 
Sent: Thursday, January 11, 2007 2:00 PM
To: Denis Pinkas; [email-masked]
Cc: [email-masked]; Russ Housley; Tobias Gondrom
Subject: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call:
draft-ietf-ltans-ers-09.txt- until Jan 23rd

Comments inline... 

> Nearly no comments were sent on the LTANS mailing list on 

There is just one document that has been submitted for working group
last call. 

> raise a number of questions to be solved. 

These two drafts were prepared quickly in advance of the last working
group meeting.  During the meeting, a call was made for additional
co-authors to help clarify and complete the documents.  One person has
joined Tobias in this effort but no follow-up drafts have been released
yet.

> obvious ASN.1 error on EvidenceRecord. 

The ASN.1 was changed as a result of comments during the previous
working group last call.  Minor errors can be corrected without much
cause for alarm.  I assume in this case you are referring to the missing
's' at the end of EncryptionInfo.  Also, the id-EvidenceRecord-Internal
and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER.  

> know on which data the digest contained in the TimeStampToken 

This info appears in Section 4 (middle of page 10): "The root hash
value, which represents unambiguously all data objects, is timestamped."

See above. 

> can be obtained on these two fields using this specification. 

This comment was made during a previous last call and resulted in
Tobias' posting to the list a few instances of structures that could be
conveyed in these fields.  These could be defined in a peer document or
defined in this draft.

  
> an EvidenceRecord includes a time stamp. However, it does not not. 

Why would one element be suppressed?  What would you want to have happen
in this case?  As-is, verification would fail.  I have commented
previously that it might be better if the chain supported shallow
verification, which would enable you to suppress a contiguous set of
elements from the beginning of the chain up to the point from which
verification was desired.  There was no support for making a change
along these lines, and there seemed to be no real need to have this
feature.  

What do you mean the EvidenceRecord does not include a timestamp?  It
includes ArchiveTimeStampSequence, which may have one or more
timestamps.

An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence.  The
draft describes how to add additional ArchiveTimeStamps to the last
ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to
add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I
don't disagree that trying to follow discussion of these three
similarly-named structures is difficult, but have failed to come up with
clearer alternative suggestions.  

This document defines a syntax for representing a chain of cryptographic
evidence.  This syntax may be used by an archive service.  However, no
archive service is required to produce an evidence record.  Archive
service signatures are addressed in the context of a protocol for
interacting with an archive service.

Good point. 

  
> explanations may be given, then this work should be stopped. 

The ISO drafts have been discussed on the list and are referenced by
this document as a source for alternative timestamp formats.

Thanks for the review.