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

From: Peter Sylvester <[email-masked]>
Date: Mon, 3 Nov 2003 17:39:00 +0100 (MET)

Here some comments:

For the German collegues, I use a rather "French style" of writing

The difference is essentially:

Pb: a German and a French person talk about the first initial
draft and the goal is that it is a starting point and one needs 
to continue.

- The French would say: "This draft is a completely unacceptable way
  to solve the problem." ==> The German would stop working
  (believing that everything is bad).

- The German  would say: "This is already a good starting point." 
  ==> The French would stop working 'believing that everything is ok).

:-)

So now, a bit of brain storming:

>   It is anticipated that a timestamp containing a digital signature 
>   will be obtained for data submitted to a long-term archive service.  
>   Thus, for all types of data, i.e. signed and unsigned, one or more 
>   digital signatures will exist that require preservation by the long-
>   term archive service.   

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. 

>   This document aims to identify the technical requirements for a long-
>   term archive service charged with preservation of digitally signed 
>   data in an X.509 certificate-based PKI. 

I disagree with this definition, i.e. with the second part staring
with 'charged with ...'  

>   Operational requirements, such as storage media concerns, individual 
>   legal requirements and questions dealing with accountability are not 
>   addressed by this document. 

I disagree that questions concerning accountability are not addressed.
At least clients should be probperly identifiable.
There may be just wording problem 'accountability" vs "accounting
and billing techniques". 

At least a requeirement must be: "The transaction data and protocols
must allow to carry either directly or indirectly information that
allow to associate each transaction to some accounting and billing
meachnism, examples are identifiers for individual clients and/or
large customers. 

Some raw requirements (oops, I saw that some of them are already in),
soory I didn't read all while I was writing. 

- 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.

- 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.

I think the previous can be deduced from several of the existing
text, in particular, about evidence for groups etc.  

- The archive service MUST be able to provide evidence about the
  policies that have been used at any time. 

- The format for the evidence/acknowledgements MUST allow to
  identify the archiving provider. 

- The format for the evidence/acknowledgements MUST allow (at least
  the creating the archiving provider) to identify the participating
  client.

- A client or other relying parties MUST be able to prove that a
  particular acknowledgement (attestation) belongs to a request
  may by the client. I an simple case, a gloabl identifier of the
  client is used, for example.

- It MUST be possible to include metadata concerning the data, for
  example a mime type, a short description in clear in the acknowlegments
  (attestations). 

- A broker style service provider should be able to relay requests to 
  back end service providers.

- 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. 

- A client may obtain final acknoledgements either by an asynch
  method, e.g. mail, or by a polling technique (maybe combined
  with a notification), cf. SAML

- An acknowledgement/attestion is a verifyable statement from the
  archive provider confirming the acceptance and (maybe partial) 
  fulfillment of the requested action. Short term verifiability needs 
  to be ensured for the requesting client but also for other relying 
  parties (e.g. signature shared secret authentication, ...) 
  Long term authenticity can be ensured by a particular service.  

 Comment about: 
   - The protocol MUST define interactions with a Long-term Archive 
   Service including, at a minimum: submission of data or groups of data 
   for preservation, retrieval of archive packages and deletion of 
   archived data and associated evidence records. 

I think the protocol should allow the validation of a acknowledge. Or,
this would be a "confirm existence" vs "retrieval" of archive packages.

- The protocol must allow that a "confirm existance" may return a 
  reference of another archive provider. 
 
Chapter 3:

- The model should allow for relays. 

- 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), 

- 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.   

to resumee: Good start :-) 

Regards

Peter

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 5 Nov 2003 09:13:36 -0500

Thanks for the comments and additional requirements.  A few comments are
inline below...

<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 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.
 
<snip>
 
>   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.
 
>   Deleting may becontrolled by a policy, but needs exceptions.

Perhaps we need a section addressing operational requirements.

<snip>

>   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.  
 
<snip>

>   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.  
 
>   against undetected loss of archived data, or against false 

Are there any timestamp formats that should be considered that don't feature
digital signatures?  RFC3161 and ATS both feature signatures.