Subject: RE: Initial requirements for long-term archive I-D - coments fro m aleksej

From: Tobias Gondrom <[email-masked]>
Date: Tue, 27 Jan 2004 18:11:47 +0100

Dear Aleksej,

Dear Tobias and others
 
First of all, I am pleased LTANS did produce one of the first discussable
drafts.

Thanks. The same for me.

In the first place I do have some views on the general document structure,
which is very "Trusted Archive Protocol" oriented. In my view, one has to
distinguish two main logical parts of the archive, which is protocol
interaction mechanisms, i.e. trusted archive protocol or a point of user's
interaction with an archive. The other is archive itself and integrated
mechanisms for assuring object validity over defined or undefined period of
time  (I do distinguish at least two measures of archiving period, although
e-archiving is tightly related to needs/requirements/obligations on content
archiving, so many "time-frame" definitions are possible) in combination
with archived object "management".  

Here I fully agree. That is why Carl and I voted for two RFCs that will be
devloped on the requirements paper. One concerning the protocol and one
concerning the Data structure (which naturally is bound to the archive
itself).

I guess data structures are trying to focus on later but conservation
mechanisms seems like missing or at least no indirect linkage to additional
specifications are mentioned, of course if there are some (XAdES??).... 

For conservation mechanisms traditional timestamps shall be used and
aggregated in a defined way so that complete chains of timestamps are
generated for the whole time the data is stored.

Next, in the document (page 4) redundant storage, disaster recovery, etc.
are mentioned. Data storage mechanisms should be out of the scope of the
e-archive, since back-up mechanisms and systems are something which one can
find on, let's say, "lower" infrastructure layer and should be dealt as is. 

Fully agree. We don't have to specify this in the protocol or data
structures. Of course there must not be a contradiction to these
requirements from the planned specifications. For this reason its included
in the requirements paper. (as far as I understand)

User authentication is another problem in wide scale deployment of archive
services. Bearing in mind that privacy is one of the (more and more)
important factor in open infrastructure, confidentiality is even more
important in case of formal content handling (contracts, invoices!!).
Furthermore, DVCS exposes the content to authority at least, and has serious
confidentiality problems...

I see the authentication problem quite similar and have at the moment not
the optimal solution for it. :(
On the one side you have to be able to store data and with this the
retrieval has to authenticated and access control has somehow to be applied.

On the other hand how can one achieve authentication across very long times
spans of decades ?
 
Confidentiality is something that will be probably one of the very important
issues when independent Archive Providers want to offe this service to end
users and smaller companies. (One mechanism I could imagine is that the
users are submitting encrypted data/documents and solve most of there urgent
problems with that.)
[see also page 9 bottom: "protocol should permit encryption of data before
submission..." ]

 On page 5 and 6, TAA is presented as a document storage service, which in
certain case doesn't have to. My personal view is, that archiving does not
mean only archiving service but extended functionality of existing document
warehouses or management systems. In this case, TAA is a service maintaining
only archiving related data and not content by itself, i.e. timestamps,
CRLs, DVCS responses, etc. Also the same service means single point of
interaction for many content related services. Do we really need such
content redundancy?

It depends. As long as the content is always accessible by the service (what
is necessary when a Hash-Algorithm fails - until then you can mostly work
with hash values). But it is dependent on the use case not necessary that
the archive Service is also functioning as a document store from which you
can later also retrive the data - not only the evidence. [see also "pure
long-term non-repudiation service" on page 5]

Hope this will trigger some discussion...

Hoping the same and thank you. (and please forgive me that my answer came so
late - I was for some days on winter holiday....)
 
For further discussion I encourage anyone to feel free and isolate any topic
he wants from the conversation and discuss it on the mailing-list.
 
Regards
 
    Tobias

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 27 Jan 2004 19:33:50 +0100 (MET)

As suggested, I just take a subpart of the messages and add some centimes
in a brain storming way.

> confidentiality problems...

If you think about a chain of a notary that validates formal content and
then needs to store the data at some external service, there is no
formal way to ensure either encryption or splitting so that the assertions
from the backend service can be matched with the statement from the
notary. Needs some work ...   

> the optimal solution for it. :(

 User authentication doesn't seem for me a particular problem for
 the archive service, it may or may not be a problem for any
 large scale service. 

 That's why I think we should not try and mandate a particular way
 but allow for different techniques, including:

 - Access control on the transport level (e.g. SSL).
 - Signatures in order to keep some proof.
 - asynchronous staged processing for certain operations
   where requests need to be confirmed by someone else.

 The meaning of 'Optimal' depends on the goals. 

> On the other hand how can one achieve authentication across very long times

Isn't Authentication 'at distance' but not 'in time'. But we talk about
authorisation? It may be necessary to handle in some way particular roles 
like 'a judge/relevant authority' and then the access control may require
some 'entitlement'. This entity from the fiscal service is entitled to access
to data from company identified by XXX'. how these meachnisms are implement
now or in future is not in our scope, I think what remains is that the
exchanged and stored information contain sufficient 'metadata' indicating 
to whom the belong using good identifiers. 
Either a client should explicitely set some identifiers in requests, which
need then matched against the authenticated client id, or they are
added by the server based on the client id or maybe additional parameters
in the request.  
 
> users are submitting encrypted data/documents and solve most of there urgent

To what degree do you trust your provider of the operating system
and the machine processor to not have a backdoor in the system which will
be activated when things happen in a environment of a 'competitor'.

Encryption may be a solution for short term, otherwise in real
paranoia you need to physically split the data and store then
at places where you are reasonably sure that the operators cannot
cheat together without leaving some trace. There are also various
possible combinations of in/out-sourcing. what seems important
is that the provider/operator of the service has an auditable system
in a very large sense.