-- Denis Pinkas -- a dit, - le 28/10/2004 15:39:
Paul-André,
(text deleted)
This is another proof of the sound approach of LTANS which links "data certs" and "secure archived". Any "data cert" must not only be signed, but a detailed log entry must be archived in a secure way (non rewritable medium, hash linking). This mandatory combination was a major rationale of the openevidence project (the technical solution by then was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)
There is no such mandatory comnbination for LTANS: data needs to be signed (and time-stamped) by the archive service, but the log is not intended to be used as an evidence.
I am exactly suggesting that it be.
We are preparing a requirements document and not some "a posteriori" rationale for a given protocol or service. My strong suggestion, based on several years activities for several customers, is indeed that the "certified archival" of "detailed and signed" log is a "must" for a large majority of actual applications and uses cases.
What the most "educated" or aware customers do require is a complete set of "evidence management" services. (What they call in France "Gestion de la Preuve" or "Administration de la Preuve"; what they will be able to exhibit in order to dissuade "others" to initiate a litigation, or whenever unsuccessfull, what they will be able to exhibit as evidence elements in a court).
My personal view of the whole justification of LTANS context is, as I am convinced that this type of requirements will be generalized, that the IETF succeeds in proposing and establishing standards that wil enable :
1. technical interop between business partners 2. technical interop between solution providers 3. the judges and their expert to master the e-material (because it conforms to standard and because there exist tools enbling to manipulate them) 4. the possibility of mutual recognition within a business community
And I have no longer any doubt that "certified archived logs" (more or less equivalent of the certified archival of requests and receipts) will be one of, if not, the most usefull component.
Denis