ietf-smime
[Top] [All Lists]

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

2007-01-11 07:28:39
Thank you for your quick response. I will make a quicker answer. You said:

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

Why is the ISO format insufficient ? Why was there a need to develop these 
documents ?
Unless the responses to these questions are given and added to the document, 
I do not think that the documents should continue to progress.

Denis




Comments inline... 
From: Denis Pinkas [mailto:denis(_dot_)pinkas(_at_)bull(_dot_)net] 
Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG 
Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd 


Nearly no comments were sent on the LTANS mailing list on 
these documents. 
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. 

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

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

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

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

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

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. 
Thanks for the review. 

Denis 

<Prev in Thread] Current Thread [Next in Thread>
  • Re: RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- untilJan 23rd, Denis Pinkas <=