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

["Aljosa Jerman Blazic" <[e-mail]>]

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

Now back to your questions. See my answers in-line:

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

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.

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

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.

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

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

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

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