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

["HOUSSIER Loic RD-MAPS-ISS" <loic.houssier@xxxxxxxxxxxxxxxxx>]

 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 : owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] De la part de Ernst G Giessmann
Envoyé : vendredi 10 décembre 2004 14:56
À : Peter Sylvester
Cc : ietf-ltans@xxxxxxx
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.