Subject: Re: My objections to the submitted draft

From: Aleksej Blazic <[email-masked]>
Date: Sun, 1 Feb 2004 18:25:26 +0100 (CET)

On Sat, 31 Jan 2004 [email-masked] wrote:

Libor,

what we should try to avoid in the first place, is try to map an analogue
archive to an e-archive, so the opinion of "real" archivist does not seem
to be always of major importance while defining standards for TAS. It is
also not the intention of LTANS to define document storage structures, but
in my opinion to introduce mechanisms on how to assure the integrity of a
record and validity of security attributes. Document storage is something
that belongs to DMS systems or OAIS and it should be kept that way. TAS
should focus on how to assemble the needed information and data to support
the stored record for a defined period in time.. However I do agree and
support the statement that several standards should come out within the
LTANS initiative. So far we faced an approach of how to define an
interaction with an archive and what is critically missing in the next 
step are archival data structures. TAS might always operate as a stand 
alone entity, mainly dealing with archival complementary data (not 
archived documents!!). And most importantly: why do we need data 
structures? To assure transparency and existence of an archive over 
undefined period of time. And finally, archivists play their general role 
in archiving records, but does a stand alone company need an archivist? 
Not really. Although laws dictates the archiving time of a document, a 
closet does perform more than perfect. So, before we are discussing 
further the main question remains: what is the purpose of the archive we 
are trying to define?

Best regards

Aleksej

> Hi, 
> 
> I have several things in the submitted draft which are unclear to me. To
> have a Berger orientation I put here also the unclear parts of the draft
> marked with the leading >. 
> 
>  
> 
> > 2. Terminology
> 
> > .
> 
> >    Timestamp: A signed confirmation generated by a Time Stamping 
> 
> >    Authority (TSA) that a data item existed at a certain time.  
> 
> >    [RFC3161] specifies a good structure for timestamps and a protocol 
> 
> >    for communicating with a Timestamp Authority (TSA).  
> 
>  
> 
> It is a bit foolish to build everything on the "classical" time stamp.
> Realize that the time stamp is also only a digitally signed structure. I
> do not understand why this draft does not mention the time stamp acc. to
> RFC3161 only as eventuality and why it is not more open to time stamps
> based on the linking hash principle. If we bind time stamp based on
> linking hash to the archived document, we could give to the court not
> one but two independent evidences of the document validity.
> 
>  
> 
> I.e. digital signatures of archived documents would be added with
> nonsigned  attribute - the enhanced time stamp based on other
> cryptographical principle - the linking hash.   
> 
>  
> 
> The base difference between time stamps based on linking hashes and
> those acc. to the RFC3161 is the fact that the time stamps based on the
> RFC3161 expire with the expiration of their Time Stamping Authority
> certificate which issued them (see that we face exactly the same problem
> we faced in case of digital signature, what this draft should solve),
> while time stamps based on linking hashes expire when the used hash
> algorithm proves to be too week, which represents incomparably longer
> time.  
> 
> .    
> 
> > 3.2    Long-term Archive Service 
> 
> >     
> 
> >    A Long-term Archive Service is to be designed to solve essential 
> 
> >    parts of these problems by providing a specialized service: 
> 
> >     
> 
> >   - The Long-term Archive Service is to store archived data objects 
> 
> >    over a long, optionally undefined, period of time. .
> 
>  
> 
> No reasonable company or organization will not archive its documents for
> undefined time period. Every organization has its archiving and
> canceling order which exactly defines the archiving time for every
> particular document type. (In most countries, it has been already
> legislated in 19th century.)
> 
>  
> 
> But many of documents are archived permanently. This is the most
> complicated problem and the main aim of LTANS should be to solve
> problems of permanent archiving of digitally signed or timestamped
> documents.  
> 
>  
> 
> >    - The Long-term Archive Service provides material needed to prove
> the 
> 
> >    existence and integrity of data objects for users as well as in 
> 
> >    court.  
> 
>  
> 
> The preceding sentence is not consistent with the following sentence:
> 
>  
> 
> >    A Long-term Archive Service is to not be designed to solve all 
> 
> >    thinkable problems of long-term-verification of digital signatures.
> 
> 
> >    It does not provide data necessary to verify signatures which are 
> 
> >    part of the archived data object itself.  This has to be done by 
> 
> >    verifiers using PKI-Services like SCVP (Simple Certificate
> Validation 
> 
> >    Protocol) or DVCS (Data Validation and Certification Server). 
> 
>  
> 
> How could the TAA give the evidence about the existence and integrity of
> a document without the data necessary for the verification of such
> evidence!? I think that we can discuss many things which the TAA
> standard should order or recommend, but it is no doubt that the TAA is
> obliged to give to a user all the required data necessary for existence
> and integrity proof of the appropriate document. Without this function
> the TAA would be only some type of data store.
> 
>  
> 
> >    This is done, in part, so the archive service can operate without 
> 
> >    knowledge of numerous signed data formats, document formats, etc.
> It 
> 
> >    also does not provide any means to integrate verification data in 
> 
> >   data objects and verify embedded signatures.  This has to be done on
> 
> 
> >    the basis of other specifications, like RFC 3029 and with regard to
> 
> 
> >    specifications of document formats.  Of course it is recommended to
> 
> 
> >    use such specifications together with a Long-term Archive Service. 
> 
>  
> 
> In this article of the draft, we can see that it is necessary to
> separate the draft work into several parallel standards. I.g. it is
> necessary either to make the RFC3029 into a form of an official standard
> or to define formats of archiving data.
> 
>  
> 
> We cannot run the TAA without format specifications. The archive can
> accept only data it can guarantee to be able to view them in undistorted
> form during the whole archiving time. It is not possible for the TAA not
> to take care for the archived data formats.  
> 
>  
> 
> Let us have the following example: we have a record of important
> government meeting stored in the MS Word 3.0. Such document should be
> archived permanently, but what to do with the document in MS Word 3.0
> format (even now you probably will have a trouble to view it without
> distortion!) Obviously, the TAA could not accept such document!  
> 
>  
> 
> The suggested draft does not take care about migration and emulation of
> archived documents.
> 
>  
> 
> ------
> 
>  
> 
> The lifetime of the archived document is also not solved in this draft.
> According to this draft, the archive only accepts and returns documents.
> It does not take care for document cataloging, searching of documents,
> viewing of documents in undistorted form and document canceling.
> 
>  
> 
> But document canceling seems to be very important archive functionality
> - it does not mean only destroying of the particular document but in
> some cases also export of the canceled document into another archive.  
> 
>  
> 
> ----
> 
> I am afraid that the submitted draft is only the idea of IT people how
> to archive documents and it should be discussed with real archivists
> which have their own idea about archiving. The archivists have a
> different approach and to create a useful digital archive we should
> listen to them. 
> 
>  
> 
> We must always keep in mind that the digital archive should offer al
> least the same services as the paper or parchment archive. 
> 
>  
> 
> Unfortunately the real archivist will decide about law and orders which
> will enable to replace paper archives with digital ones.
> 
>  
> 
> Libor
> 
>

---

From: "A. Jerman Blazic" <[email-masked]>
Date: Mon, 2 Feb 2004 12:56:34 +0100

> I have several things in the submitted draft which are unclear to me.
To have a
> Berger orientation I put here also the unclear parts of the draft
marked with the 
> leading >. 

>It is a bit foolish to build everything on the "classical" time stamp.
Realize 
>that the time stamp is also only a digitally signed structure. I do not
understand 
>why this draft does not mention the time stamp acc. to RFC3161 only as
eventuality 
>and why it is not more open to time stamps based on the linking hash
principle. If 
>we bind time stamp based on linking hash to the archived document, we
could give to 
>the court not one but two independent evidences of the document
validity.
>I.e. digital signatures of archived documents would be added with
nonsigned  
>attribute - the enhanced time stamp based on other cryptographical
principle - the 
>linking hash.   
those acc. to 
>the RFC3161 is the fact that the time stamps based on the RFC3161
expire with the 
>expiration of their Time Stamping Authority certificate which issued
them (see that >we face exactly the same problem we faced in case of
digital signature, what this 
>draft should solve), while time stamps based on linking hashes expire
when the used 
>hash algorithm proves to be too week, which represents incomparably
longer time.  

You can achieve the same evidence presented to the court when using
redundant timestamps, which is what any archive is suppose to do in any
case (also bare in mind that if you want to keep "machine readable data"
archived a backup and disaster recovery functions must be supported
using redundancy mechanisms, which is again not the intention to be
solved by LTANS). Also, as Santosh stated, trusted archive must ensure
the use of long(er) keys and most importantly do the re-timestamping, so
no problem with expired timestamps should foreseen.

Regards

aleksej

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 2 Feb 2004 08:10:07 -0500

comments inline...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, January 31, 2004 2:35 PM
To: [email-masked]
Subject: My objections to the submitted draft

It is a bit foolish to build everything on the "classical" time stamp.
Realize that the time stamp is also only a digitally signed structure. I do
not understand why this draft does not mention the time stamp acc. to
RFC3161 only as eventuality and why it is not more open to time stamps based
on the linking hash principle. If we bind time stamp based on linking hash
to the archived document, we could give to the court not one but two
independent evidences of the document validity.

I.e. digital signatures of archived documents would be added with nonsigned
attribute - the enhanced time stamp based on other cryptographical principle
- the linking hash.   

The base difference between time stamps based on linking hashes and those
acc. to the RFC3161 is the fact that the time stamps based on the RFC3161
expire with the expiration of their Time Stamping Authority certificate
which issued them (see that we face exactly the same problem we faced in
case of digital signature, what this draft should solve), while time stamps
based on linking hashes expire when the used hash algorithm proves to be too
week, which represents incomparably longer time.  

[CW] The structures should be defined to accommodate different types of
timestamps.  Folks who had needs that could be met with RFC3161 or ATS have
those options available.  Folks who want to use a linking hash approach
without digital signatures could use such structures.    

.    

How could the TAA give the evidence about the existence and integrity of a
document without the data necessary for the verification of such evidence!?
I think that we can discuss many things which the TAA standard should order
or recommend, but it is no doubt that the TAA is obliged to give to a user
all the required data necessary for existence and integrity proof of the
appropriate document. Without this function the TAA would be only some type
of data store.

[CW]  This is another case where the specs must be flexible.  In all cases,
the TAA must provide evidence that data has not changed while it was in the
care of the TAA.  In some cases, upon acceptance, it may be necessary for a
TAA to collect or generate evidence about the integrity of the archived data
(possibly including a review of the content of the data).  In other cases,
privacy concerns may dictate that the TAA may either never handle the data
directly or only handle the data in encrypted form.  In some cases, the data
may not be signed at all and the act of archiving is the first step in
generating integrity proof.

>    knowledge of numerous signed data formats, document formats, etc.  It 

>    use such specifications together with a Long-term Archive Service. 

In this article of the draft, we can see that it is necessary to separate
the draft work into several parallel standards. I.g. it is necessary either
to make the RFC3029 into a form of an official standard or to define formats
of archiving data.

We cannot run the TAA without format specifications. The archive can accept
only data it can guarantee to be able to view them in undistorted form
during the whole archiving time. It is not possible for the TAA not to take
care for the archived data formats.  

Let us have the following example: we have a record of important government
meeting stored in the MS Word 3.0. Such document should be archived
permanently, but what to do with the document in MS Word 3.0 format (even
now you probably will have a trouble to view it without distortion!)
Obviously, the TAA could not accept such document!  

[CW] Maybe the TAA provides a 486 running MS Word 3.0 right next to the
microfiche machine:-) 

------

The lifetime of the archived document is also not solved in this draft.
According to this draft, the archive only accepts and returns documents. It
does not take care for document cataloging, searching of documents, viewing
of documents in undistorted form and document canceling.

[CW] The focus is on extending the means to demonstrate integrity.  A TAA
may provide very rich cataloging and searching capabilities but these
capabilities are not related to the integrity preservation mechanisms.

Format migration is a related problem but not one we should try to solve
initially.

---

From: Jeff Williams <[email-masked]>
Date: Mon, 02 Feb 2004 17:53:09 -0800

Carl and all,

Carl Wallace wrote:

> based

  I like your idea here Carl.

> principle
> those

 I agree here.  And this in different terms was one of my objections
as well.  You stated better than I, however.

> appropriate document. Without this function the TAA would be only some

Yes.

> generating integrity proof.

  Good idea here as well...

> separate

  I believe that defining the expectable formats would be the better
route to take.

> Format migration is a related problem but not one we should try to

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827

---

From: <[email-masked]>
Date: Tue, 3 Feb 2004 12:29:16 +0100

Aleksej,

> So far we faced an 
> approach of how to define an interaction with an archive and 
> what is critically missing in the next 

We need to realize that the two archiving worlds exists:
- stand-alone company archive - it does not need archivists, do not
archive documents for more than 20years and it is sufficient for it to
either create long term signatures or simply to use some existing
commercial archiving product 
- long-term archives. Each document of permanent value finally ends in
some archive of this type. We already have such archives for paper
documents, films, audio and video. LTANS (if I understood well) aims to
create mechanisms for archiving of digitally signed documents.

Libor

---

From: "A. Jerman Blazic" <[email-masked]>
Date: Tue, 3 Feb 2004 12:46:27 +0100

> - stand-alone company archive - it does not need archivists, 
> do not archive documents for more than 20years and it is 
> sufficient for it to either create long term signatures or 
> simply to use some existing commercial archiving product 
> - long-term archives. Each document of permanent value 
> finally ends in some archive of this type. We already have 
> such archives for paper documents, films, audio and video. 
> LTANS (if I understood well) aims to create mechanisms for 
> archiving of digitally signed documents.

Agree (see my previous post!). LTANS should give partial (or
incremental) solutions to solve both problems (and not only digitally
signed documents)... A nice example to this approach rfc3126 or XAdES.

Regards

aleksej