Re: ERS - using hash tree?

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

Jesus Maria Mendez Perez wrote:
> Hello Tobias, I´m Jesus.
Merry Christmas.
> I have some questions and I hope you can help me.
>
> First, about what happen with the gap of time that pass while you send 
> a data object and finally at the evening the ERS-system build
> the hastree for all documents that were archived during that day?. For 
> example, if you send a data object at 3:00 pm and the ERS-system build 
> the hashtree at 8:00 pm... you have 5 hours during which that data 
> object could lose its integrity. What can we do in this situation?
> Could be the solution to timestamp every data object separately and 
> inmediately after they are sent by the client and when the ERS-system 
> have to build the hashtree, the hash-tree will built with all these 
> data objects and its timestamps?
IMO opinion you need to distingusih two events: A 3:00pm a client enters 
something into an archive.Looking
at LTAP, this may result in a first 'receipt', indicating that archiving 
is 'in progress'. At 8:00 or
even a day later (when backup copies etc are made), the archive may 
return a 'now we have a safe archived copy'
message.
> And now about the ARCHIVE operation. In the LTAP Protocol draft is 
> said LTAP Protocol is asynchronous by nature. And my question is about 
> then second response (service response). Will a client receive the 
> second response when the TAS hast just received the data object or 
> when the archive operation has just finished (the hashtree has been 
> built)?
The second message is sent when the TAS can safely assume that it has a 
good recoverable copy.
If ERS is part of the policy of the TAS, then the TAS most likely does 
not respond before having
created a good tree, and backups and backups of the trees ... etc
> If the ARCHIVE operation is asynchronous we really need another 
> operation to permit a client to check if the full archive operation 
> has finished...
Which is the case with LTAP.
The protocol does not necessarily be mapped to HTTP, you
can map the second ack to a mail based service.
The abstract protocol allows to 'poll for a response' in several ways:
After having received the initial response or even before, you can 
repeat the archive
operation using the hash of the data as reference or the reference 
return by the initial ack.
You do this until you get the final response.

What this means is that a client does have to do some housekeeping in 
some 'spooling server'
similar to email or to a tcp stack.

Even the initial ack is conceptually asynchronous allow a client API 
implementation
to be completely non-blocking, etc.
> Finally about the information called "Complementary data" in the 
> article "Long-term trusted preservation service using service 
> interaction protocol and evidence records", does it include only 
> timestamping certificates?, or does it include timestamps' certificates
> and user signer´s certificates?. Are they obtain by SCVP and save up 
> as complementary data in the archive operation?
I let Aljosa answer this.
> Thanks and Happy Christmas
Happy new year.
Peter

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature