Subject: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks

From: "HOUSSIER Loic RD-MAPS-ISS" <[email-masked]>
Date: Mon, 13 Dec 2004 16:32:12 +0100

Hello,
I am pretty new to ltans subjets.
I read the Requirements draft and have some questions. Don't worry if some looks stupid, please let me know if it's the case.

§4.1.1 
You talk about "acknowledgment" that have to be provided by a LTA.
I think these must be signed by the LTA in order to give submitter an evidence that he sent data to LTA.
What the need of unsigned acknowledgment?

For the question asked at the end of the chapter, I believe that many acknowledgement must be provided. The final one must be a summary of all precedents.

Nearly End of duration period of archive must be provided to submitter, in order to let him change the duration if needed.

§4.2.1
Why lta MUST permit the specify of metadata ?
Can it be possible for a LTA services not to propose this permission ?
Has metadata to be outside the data ?
Couldn't it be inside a group of data  --> [[data][metadata]], in order not to be dealed by LTA ?

§4.5.1
The confidentiality might be not necessary. By example, let's think about a service that propose to archive patent. What the need of confidentiality ?
So I propose to change "A long term archive MUST provide means to ensure..." by "A long term archive MAY..."

Well I think that's all.

Regards,

Loïc HOUSSIER

Loïc HOUSSIER
France Telecom/Division R&D/MAPS/NSS 
Ingénieur recherche et développement
38-40, rue du Général Leclerc 
92794 Issy Moulineaux Cedex 9 
Tel: +33 (0)1 45 29 58 08 
Fax: +33 (0)1 45 29 65 19

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ernst G Giessmann
Envoyé : vendredi 10 décembre 2004 14:56
À : Peter Sylvester
Cc : [email-masked]
Objet : Re: WG LAST CALL: draft-ietf-ltans-reqs-02.txt

Peter Sylvester wrote:

> During a telephone call Denis informed me that he had missed the 
> following message. For convenience (of Denis), I resend it. Sorry to
> bother the others again with the content. :-)
> 
> Peter
...
>> In fact the main constituents of an archive policy still need to be
>> defined. The following comments focus on one of the components of
>> an archiving policy, i.e. the cryptographic maintenance policy, so
>> the work still needs to be done.

The technical problem of maintaining the security status as it was at
the time of deposit is that algorithms become weaker and that
certificates binding a service or name to a public key may go
out-of-date. The service provider can stop her operation after the
latest NotAfter indication of all issued certificates is over and then
you loose the outside trust anchor of the archive.

So it is not document specific, but you must be able to determine
starting from the document which service-specific policy was active as
the document was deposed.

Certainly we can consider different possiblities for maintenance but
first we must think on crypto solutions.

Regards,
Ernst.

---

From: <[email-masked]>
Date: Mon, 13 Dec 2004 17:56:15 +0100

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von HOUSSIER Loic RD-MAPS-ISS
> Gesendet: Montag, 13. Dezember 2004 16:32
> An: [email-masked]
> Betreff: [draft-ietf-ltans-reqs-03.txt] Questions & Remarks
> 
> 
>  Hello,
> I read the Requirements draft and have some questions. Don't worry if some
> looks stupid, please let me know if it's the case.
> 
Be welcome. Your Questions are not new, but not stupid.
> What the need of unsigned acknowledgment?

In an inhouse environment LTA is a service for an application system. E.g.
inhouse environment is a hospital, LTA is document management or archive
system and application system is a medical system used for generation of
medical documents and signing them by doctors. 
In this case only evidence records are needed to verify, that archived
documents existed at a certain point in past - e.g. before signature and
hash-algorithms used in it got weak or certificates in it were revoked.
Acknoledgement is useful to have an indication, that storing was accepted
and successful. But no proof for document delivery is needed, therefore no
signed acknoledgements are needed.

If archive service is an external by a service provider, proof of delivery
using a signed acknowledgement might be helpful. Problem is, that signed
acknowledgement is valid only a relatively short time. It will loose its
value of evidence over long periods of time (up to 10 or more years),
because hash- and signature algorithms in it will get weak and certificates
expire. Archive service provider possibly could therefore repudiate this
acknowledgement after lets say 20 or 30 years if he wants to. 
Sending signed acknowledgement to another service provider who has to
archive it would leed us to recursive and in effect very complex solutions.
Therefore we prefer other strategies like protocols and external audits of
archive service providers to avoid successful repudiation of delivery.
 
Last but not least it would not be acceptable for users that he must store
signed acknoledgements for every (maybe little) document he delivered to an
archive service provider. If he wants to avoid to store documents by using
an archive provider and has to store signed acknoledgements - were is the
benefit?
Storing a little index like a hash value or an integer should be sufficient
to retrieve archived documents.