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

["Andreas Menke" <[e-mail]>]

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: [phone] – 10
Fax: [phone] – 11
[e-mail]
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