Subject: RE: draft-ietf-ltans-reqs-00.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 5 Nov 2003 16:40:17 +0100 (MET)

> 
> <snip>
> > I do not think that this phrase is good in the introduction,
> > in particular the wording of 'time stamp containing a digital 
> > signature'. Why do 'signatures require preservation'? The 
> > data itself need it. 
> 
> I agree the wording is a little awkward and in general the draft may be
> overly prescriptive w.r.t. to timestamps as a mechanism, though this is
> based on previous work - RFC3126, DVCS, ATS, TAP.  The notion that there
> will always be one or more digital signatures present is based on
> assumptions that data submitted to an archive will be timestamped and that
> timestamps include a signature.  Signatures require preservation due to the
> decreasing value of the objects used to verify the signature, etc., etc.  

I think we are able to find a wording which is sufficiently neutral.

>  
> > I disagree with this definition, i.e. with the second part
> > staring with 'charged with ...'  
> 
> OK.  We can strike the reference to the environment and leave that to the
> mechanism specs.
Ok. 

>  
> <snip>
>  
> > - An archive service provider MUST NOT be able to insert data in a
> >   non chronological way, i.e., if some data are archived and
> > time stamped,
> >   no data with a older time stamp can be inserted.
> 
> I not sure I agree with this.  If I have a document with timestamp 1 and you
> have a document with timestamp 2, I shouldn't be prevented from archiving my
> document because you submitted your doc first.  If you mean that the archive
> itself must never apply a timestamp older than a previously applied
> timestamp, then I agree.

the usage of the overloaded word time stamp (as you mention,
the client data may already have one in some way, and the server may
add another) is perhaps a problem. Indeed I mean basically the second
thing. In fact, I am not sure whether strict linear order is required
in the global sense, if you have trees of hashes. 

indeed, a client may have obtained some time stamp or "file seal"
much earlier in order to have a proof of the existance, and this is
not related to the time of archiving. 

>  
> > - An archive service MUST NOt be able to delete data from the
> > archive with
> >   detecting, or in other words, the service must be able to prove that
> >   nothing has been deleted.  
> > 
> > - An archive service MUST allow to transfer completely or partially, 
> >   archived data to another services provider without loss of the
> >   global integrity property defined above.
> > 
> > - An archive service MUST allow to delete completely or partially, 
> >   archived data to another services provider without loss of the
> >   global integrity property defined above. (This can for example
> >   be accomplished by transfering data to a fictious "archiver").
> >   Deleting may becontrolled by a policy, but needs exceptions.
> 
> Perhaps we need a section addressing operational requirements.

I think input from some real archiving providers may be helpful.
  
> <snip>
> 
> > - A provider should be able to provide the service in a staged way,
> >   i.e. provide initial acknowledgements for by final ones. This is
> >   important in order to avoid a simgle point of failure.
> 
> This may also be important if there is to be support for a grace period to
> accommodate compromise declaration after submission.  
Yes. 

>  
> <snip>
> 
> > - If I understand it right, the TSA is used as a security
> >   mechanism by the TAA. I think one should not restrict this
> >   and open this to other mechanisms, e.g. an service
> >   provider can use another backend archive, can archive just
> >   all its transaction logs (or acknowledgements),
> 
> In this case the TAA is acting as a client to another TAA.  There's nothing
> in the draft to restrict this type of interaction.  
Right

> > - The text makes a lot of assumption about
> >   timestamps, in particular that a time stamp has a signature. I think
> >   one should weaken this. time stamping using hash linking is
> > a technique
> >   that allows independance of secrets, and also, as a side effect, 
> >   links all time stamps together, thus, is a good mesure to protect
> >   against undetected loss of archived data, or against false 
> > inclusions etc.   
> 
> Are there any timestamp formats that should be considered that don't feature
> digital signatures?  RFC3161 and ATS both feature signatures. 

Yes. At least in a second step:

A client only needs a strong authentication method to validate
a server when the time stamp is obtained. This is in general done by
a signature. If you use hash linking, and if you publish in regular
intervals the last hash, a client can ask for an extended time stamp
which includes a hash chain up to the published one.  This extended
time stamp no longer depends on the security of keys, only on the
hash function.    

See: http://ltans.edelweb.fr/Cybernetica-OpenEvidence-TimeStamping.pdf
or at the http://www.cyber.ee

Peter

----- End Included Message -----