Subject: Comment on draft-ietf-ltans-xmlers-03.txt (3)

From: "Andreas Menke" <[email-masked]>
Date: Thu, 16 Jul 2009 12:03:39 +0200

Hello list.

I did not got a response on my 'Comment on ...' from Di 23.06.2009 09:14. So
I want to insist.

Is it truly understood, that if 'Calculate hash value from binary
representation of the last
      <ArchiveTimeStamp> element [...].' (Section 4.2.1, point 2, sentence
2) is correct, than there is no chance ever cumulating hash-trees of
hash-trees and so on to get a new timestamp on top during timestamp renewal
since an ATS is for (mostly) every ERS different? If, for example, in the
last 30years there are 1 million hash-trees build with 1 million timestamps
on top, reduced to >= 1million ERS. Than it would be on timestamp renewal
that one must get 1 million new timestamps (preserving the same hash-tree
size)? It is true, that this must be done in case of weakness of the digest
algorithm, but why on timestamp renewal? What is the deeper sense on using
the ATS to hash and not the <TimeStamp> element which likely is the same for
all generated ERS of some hash-tree? If, for example, one wants that the
revocation values are to be secured by the next timestamp, than it might be
nicer to define a new element inside <TimeStamp> which is capable of holding
that data, *not* including the reduced hash-tree which varies from ERS to
ERS.

Is it truly understood, that if 'Acquire the time-stamp for the calculated
hash value.' (Section 4.2.1, point 2, sentence 3) in direct conjunction with
sentence 2 (see above) is correct, than one must get a timestamp for *every*
ERS on timestamp renewal? Why not doing Merkle-HashTrees and than reducing?

In Section 4.3, point 4, part of sentence 2 it is not clear why to verify
that some ATS 'does not contain other hash values'. Do any hash values (of
known or unknown data) disturb any prove in XML but not in DER?

XML ERS might be useless in case of large archives. RFC4998 seems to be
clearer.

Regards

Andreas Menke

-----------------------------
Diplom-Informatiker (Uni.)
Andreas Menke
Team Leader, Development

OPENLiMiT SignCubes GmbH
Saarbrücker Str. 38 A
D-10405 Berlin

Fon: +49 30 868 766 – 10
Fax: +49 30 868 766 – 11
[email-masked]
www.openlimit.com

Geschäftsführer:
Heinrich Dattler, Armin Lunkeit
Nadine Model (Prokuristin)
Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 86352 B
Finanzamt für Körperschaften II
St.-Nr. 37/155/20819
USt-ID: DE 224136339
---

Erleben Sie, wie einfach es ist, elektronisch zu unterschreiben und testen
Sie die neue Signatur-Software OpenLimit CC Sign 2.5 für 30 Tage kostenlos.
Hier downloaden:
https://www.openlimit.com/de/produkte/cc-sign/download-cc-sign-testversion.h
tml

---

From: "Aljosa Jerman Blazic" <[email-masked]>
Date: Thu, 16 Jul 2009 13:17:51 +0200

Dear Andreas

First sorry for slow reply. We did some work on new draft to be published within days and I thnik your second question was answered driectly (about the ordering and XML schema - this should be fixed now - thank you!).

> that data, *not* including the reduced hash-tree which varies from ERS

The problem arises from the fact that in case timeStamp element only holds, e.g. hash value, and signature value (i.e. no cryptographic information) and if there are no other means used to time-stamp cryptographic information from the preceding time-stamp (e.g. CRL, certs...) it would be impossible to check the validity of the time-stamps in the chain. This is the reason why a complete ATS (ATS has a placeholder for cryptographic information) has to be hashed and timeStamped again.

Another limitation arises in case timestamp element only is re-time-stamped - that would limit the renewal process only for the original group. In some cases it might be desirable that as archive data are grouped to obtain one time stamp e.g. per-day, then the renewal process takes under consideration all timestamp tokens generated, e.g. through the year. This is why the current proposal is more generic. However there is a point in your statement and we'll consider that with the new draft version.

> ERS on timestamp renewal? Why not doing Merkle-HashTrees and than

This is another possibility, but it would make the whole process much more complex. A simple answer would be to collect timeStamp and cryptographicInformation elements, compute hash values and get new timeStamp. This information (timeStamp + cryptographicInformation) is the same for every ERS record.

> known or unknown data) disturb any prove in XML but not in DER?

The simple reason for that is hash collision prevention. In case that other hash values are allowed it might happen that some random values are added (note that the amount of combination without this restriction is infinite) until the hash value computed form the list is equal to the hash value computed from the original list of input hash values.
 
> XML ERS might be useless in case of large archives. RFC4998 seems to be

I disagree here as this heavily depends on the scenarios. It may be desirable to preserve XML structures for uniformity and we see no particular obstacle to deploy XML interpretation of ERS. Mind you that (archive) data may also come in a form of XML. On top of that, there are efficient ways to compress XML or use Efficient XML (EXI). This should be no problem for large archives.

Thank you again for your valuable comments!

Best regards

Aljosa Jerman Blazic

> Fon: +49 30 868 766 - 10
> Fax: +49 30 868 766 - 11