Subject: draft minutes

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 Nov 2003 15:48:24 +0100 (MET)

The draft minutes of the IETF58 meeting are avialable in the web server.

Since I was not able to participate, here some comments concerning
several items mentioned in the minutes.

It is really nice to see comments and questions in a raw form,
this gives a better impression of the discusson, and allows to
better ask for clarifications than with a 'summary by the chairman'
approach. 

Thus: 

Agenda 1) : 
> Stated that the group is concerned with signed data as opposed to unsigned, general purpose archive.

What exactly is meant by 'signed data'. I think the purpose
is to
 
'archive and/or notarize authentifiable representations of information'.

If signed data means that the data to be archived need to have
some characteristics that can be considered as an equivalent of
all aspects of what is called 'signature' for a paper document, 
then ok. 

The difference between archive and notoarize may be floating. If
the archive provider cares a little bit of the semnatics of the document,
for example when seome future conversion may be planned, then this
can be considered as the first step of a notarisation operation;
A real notarisation (depending on which culture you think about)
can just end here (public notary) or continue to validate and assert
the conformance to some legal procedure (EU continent).

Agenda 3) : 

Having siad the previous, I don't think that one should even try to address 
the long term validaty of digital signature chains by using any cryptographic 
approach that includes secrets. Digital signatures are for
strong authentication (IMHO) and not a sufficintly stable means for
long term. 
It seems important to me that the underlying service model
assumes that there is at least one additional redundant mechanism that
can be used to prove the "existance" of some data at:before a certain
time, e.g. physical protection with strong ordering of the storage media.   

> "Complicated problem of establishing validity of a chain of signatures over 100 years."

Can someone give a paper equvalent example? 

5) The requireemnts doc is a first attempt. 

 "deleting data from archive without detection" : The requirement is
not that one must not be able to delete without detecting, but
rather that the archiver may be interested to prove at any time the
global integrity of the data he has, or that if some data
are not there, then they had never been there. 
This can be done in different ways, in a simple way by never deleting anything.

> Hillary: You can't force archiving service to really archive, i.e. the bits can always be lost.  Deletion requires authentication.
I am not sure what is meant here. 

> Ulrich: Format conversion was considered - signature format, document format, etc.  Considered it as a separate service distinct from archive services and notary services.  It is not necessary to bundle such service as part of an archive.

> Larry: General question raised, in favor or against, including some support for formats (i.e. format conversion history).  

> Tobias: Is this work useful?  1 person yes.  No people no.  Everyone else no answer.

For whatever type of document, the inclusion of metadata describing the actual format
(like a mime type, or oid, or schema, ...) should not be excluded as part of the input.
Some of these metadata may provide sufficient redundancy information concerning
the 'information structure' allowing a conversion in the future. Such a conversion
can occur either on request of some client, or by some global service action,
in this case the service provider can convert the data, and keep a history of the
actions. The service provider is able to return the archived information in
a representation which is 'state of the art' plus, optionally traces about the
orginal formats and the conversions that had been done (like copied from
hand written paper to machine written paper and signed by some authority).   

regards
Peter

Date: Thu, 20 Nov 2003 15:48:24 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: draft minutes
Sender: [email-masked]

The draft minutes of the IETF58 meeting are avialable in the web server.

Since I was not able to participate, here some comments concerning
several items mentioned in the minutes.

It is really nice to see comments and questions in a raw form,
this gives a better impression of the discusson, and allows to
better ask for clarifications than with a 'summary by the chairman'
approach. 

Thus: 

Agenda 1) : 
> Stated that the group is concerned with signed data as opposed to unsigned, general purpose archive.

What exactly is meant by 'signed data'. I think the purpose
is to
 
'archive and/or notarize authentifiable representations of information'.

If signed data means that the data to be archived need to have
some characteristics that can be considered as an equivalent of
all aspects of what is called 'signature' for a paper document, 
then ok. 

The difference between archive and notoarize may be floating. If
the archive provider cares a little bit of the semnatics of the document,
for example when seome future conversion may be planned, then this
can be considered as the first step of a notarisation operation;
A real notarisation (depending on which culture you think about)
can just end here (public notary) or continue to validate and assert
the conformance to some legal procedure (EU continent).

Agenda 3) : 

Having siad the previous, I don't think that one should even try to address 
the long term validaty of digital signature chains by using any cryptographic 
approach that includes secrets. Digital signatures are for
strong authentication (IMHO) and not a sufficintly stable means for
long term. 
It seems important to me that the underlying service model
assumes that there is at least one additional redundant mechanism that
can be used to prove the "existance" of some data at:before a certain
time, e.g. physical protection with strong ordering of the storage media.   

> "Complicated problem of establishing validity of a chain of signatures over 100 years."

Can someone give a paper equvalent example? 

5) The requireemnts doc is a first attempt. 

 "deleting data from archive without detection" : The requirement is
not that one must not be able to delete without detecting, but
rather that the archiver may be interested to prove at any time the
global integrity of the data he has, or that if some data
are not there, then they had never been there. 
This can be done in different ways, in a simple way by never deleting anything.

> Hillary: You can't force archiving service to really archive, i.e. the bits can always be lost.  Deletion requires authentication.
I am not sure what is meant here. 

> Ulrich: Format conversion was considered - signature format, document format, etc.  Considered it as a separate service distinct from archive services and notary services.  It is not necessary to bundle such service as part of an archive.

> Larry: General question raised, in favor or against, including some support for formats (i.e. format conversion history).  

> Tobias: Is this work useful?  1 person yes.  No people no.  Everyone else no answer.

For whatever type of document, the inclusion of metadata describing the actual format
(like a mime type, or oid, or schema, ...) should not be excluded as part of the input.
Some of these metadata may provide sufficient redundancy information concerning
the 'information structure' allowing a conversion in the future. Such a conversion
can occur either on request of some client, or by some global service action,
in this case the service provider can convert the data, and keep a history of the
actions. The service provider is able to return the archived information in
a representation which is 'state of the art' plus, optionally traces about the
orginal formats and the conversions that had been done (like copied from
hand written paper to machine written paper and signed by some authority).   

regards
Peter

Date: Wed, 5 Nov 2003 16:40:17 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: draft-ietf-ltans-reqs-00.txt
Sender: [email-masked]

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

From: "Carl Wallace" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: draft-ietf-ltans-reqs-00.txt
Date: Wed, 5 Nov 2003 09:13:36 -0500
Importance: Normal
Sender: [email-masked]

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

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

Date: Mon, 3 Nov 2003 18:56:39 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: long term Archive Architecture
Sender: [email-masked]

Hi, I have received a docuiment from two colleagues 
Libor and Marta in the Czech republic. So far, awaiting
some comment from the chairmen, I have put the
document in the ltans web server into the "related
documents" section. 

--- forwarded message : 
From: "[email-masked]" <[email-masked]>
Date: Mon, 3 Nov 2003 18:13:15 +0100

Dear Peter,
I am very glad that I can send you the Long-term archiving - draft proposal which we (Libor Dostalek and Marta Vohnoutova) have made. You can see that we worked hard to help our ietf-ltans-arch group to progress. We put there our experiences with the "special world" of real archivists who will unavoidably talk to the long-term archiving project.
This is a draft proposal and we expect and we would be very glad if other authors thing over our material. But we think it could be a very good starting point.
Please bo so kind - read the attached material throroughly, put it on your web site and announce to the conference participants that new draft proposal exists.

Looking forward to any comments 
Best regards 
Cordially Libor and Marta

P.S. Because of necessary pictures we transformed the file into the PDF form (because of the rastr - the best view is if the scale is 100%.

Date: Mon, 3 Nov 2003 17:39:00 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: draft-ietf-ltans-reqs-00.txt
Cc: [email-masked]
Sender: [email-masked]

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: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Subject: 
Date: Sat, 1 Nov 2003 13:27:43 +0100
Importance: Normal
Sender: [email-masked]

subscribe