Subject: My objections to the submitted draft

From: <[email-masked]>
Date: Sat, 31 Jan 2004 20:35:25 +0100

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: "Santosh Chokhani" <[email-masked]>
Date: Sat, 31 Jan 2004 21:19:35 -0500

Libor:
 
See my responses in line

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

Hi, 

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.
[Santosh Chokhani] There may be some patent related concerns regarding the
linked time stamp (Surety in US). 

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.  

.    

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.  
[Santosh Chokhani] I think LTANS is trying to solve that problem 

>    - The Long-term Archive Service provides material needed to prove the 

>    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!?
[Santosh Chokhani] The party who archives the data is responsible for
providing all the evidence that it might need.  Thus, if some one wants to
archive digital signatures or digital signatures and SCVP responses, they
need to include the signed document, signed SCVP responses and SCVP trust
anchor in order to obtain these from the TAA at a later time and demonstrate
the signature was valid at some time in the past.

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.
[Santosh Chokhani] I think TAA needs to play back what the user submitted
and ensure the integrity of the user submission.  If the data happens to be
signed data, the user can submit relevant trust anchors, certificates, and
revocation information to demonstrate the signature was valid when applied.
But, TAA need not gather all this; neither does TAA need to be limited to
archive signed data. 

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

------

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: <[email-masked]>
Date: Sun, 1 Feb 2004 07:34:38 +0100

[Santosh Chokhani] There may be some patent related concerns regarding
the linked time stamp (Surety in US). 

Why uses the submitted draft only time stmps based on RFC-3161?

.    

I am afraid it is not fully true. See the following example:
Let us have a signed documnet archived for 200 yers. All signatures 
of this document are based on RSA algortithm with 1K keys. It means
that every two years all the signatures are renewed. The problem is 
that I have chain of 100 timestamps (based on RFC-3161).    

Libor

---

From: Jeff Williams <[email-masked]>
Date: Sun, 01 Feb 2004 01:53:15 -0800

Libor and all,

  Your point below is well taken and has been and is being discussed
on other venues/forums regarding legal documents or those that
may be of some legal interest.  Many have very long term life.

RFC 3161 failed to recognize these factors, even though they were
discussed at the time RFC 3161 was under consideration.  Hence
it's revision would seem to be in order...

> that I have chain of 100 timestamps (based on RFC-3161).

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

Date: Sun, 01 Feb 2004 01:53:15 -0800
From: Jeff Williams <[email-masked]>
Organization: INEGroup Spokesman
To: [email-masked]
CC: [email-masked], Mark milone <[email-masked]>
Subject: Re: My objections to the submitted draft
Sender: [email-masked]

Libor and all,

  Your point below is well taken and has been and is being discussed
on other venues/forums regarding legal documents or those that
may be of some legal interest.  Many have very long term life.

RFC 3161 failed to recognize these factors, even though they were
discussed at the time RFC 3161 was under consideration.  Hence
it's revision would seem to be in order...

> that I have chain of 100 timestamps (based on RFC-3161).

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]>
To: <[email-masked]>
Subject: RE: Role of attribute certificates in long-term archiving
Date: Sun, 1 Feb 2004 07:53:53 +0100
Importance: Normal
Sender: [email-masked]

> Marta:
>
> There does not seem to be any benefit gained by using the attribute
certificate format 
> for archived data.

I think the digital archive must have at least the same features as
classical stone archive. My personal expirience is if you want to
explore some old documents in archive  you must first prove your
identity, explain your purpose why you need these documents, and based
on this the appropriate permitions for the specific part of archive is
given to you.

Analogically in digital world, you can prove your identity with
certificate and attributte certificate represents appropriate permitions
given to you.

Identity of person who put document into archive 50 years ago could be
irrelevant.

Marta    

From: <[email-masked]>
To: <[email-masked]>
Subject: RE: My objections to the submitted draft
Date: Sun, 1 Feb 2004 07:34:38 +0100
Importance: Normal
Sender: [email-masked]

.    

Libor

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: My objections to the submitted draft
Date: Sat, 31 Jan 2004 21:19:35 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C3E83F.F2461A10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Libor:
=20
See my responses in line

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

Hi,=20

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

=20

>    Timestamp: A signed confirmation generated by a Time Stamping=20

>    Authority (TSA) that a data item existed at a certain time. =20

>    [RFC3161] specifies a good structure for timestamps and a protocol=20

>    for communicating with a Timestamp Authority (TSA). =20

=20

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.
[Santosh Chokhani] There may be some patent related concerns regarding =
the
linked time stamp (Surety in US).=20

=20

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

=20

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

.   =20

> 3.2    Long-term Archive Service=20

>    =20

>    A Long-term Archive Service is to be designed to solve essential=20

>    parts of these problems by providing a specialized service:=20

>    =20

>   - The Long-term Archive Service is to store archived data objects=20

>    over a long, optionally undefined, period of time. .

=20

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

=20

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. =20
[Santosh Chokhani] I think LTANS is trying to solve that problem=20

=20

>    - The Long-term Archive Service provides material needed to prove =
the=20

>    existence and integrity of data objects for users as well as in=20

>    court. =20

=20

=20

>    A Long-term Archive Service is to not be designed to solve all=20

>    thinkable problems of long-term-verification of digital signatures. =
=20

>    It does not provide data necessary to verify signatures which are=20

>    part of the archived data object itself.  This has to be done by=20

>    verifiers using PKI-Services like SCVP (Simple Certificate =
Validation=20

>    Protocol) or DVCS (Data Validation and Certification Server).=20

=20

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!?
[Santosh Chokhani] The party who archives the data is responsible for
providing all the evidence that it might need.  Thus, if some one wants =
to
archive digital signatures or digital signatures and SCVP responses, =
they
need to include the signed document, signed SCVP responses and SCVP =
trust
anchor in order to obtain these from the TAA at a later time and =
demonstrate
the signature was valid at some time in the past.

=20

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.
[Santosh Chokhani] I think TAA needs to play back what the user =
submitted
and ensure the integrity of the user submission.  If the data happens to =
be
signed data, the user can submit relevant trust anchors, certificates, =
and
revocation information to demonstrate the signature was valid when =
applied.
But, TAA need not gather all this; neither does TAA need to be limited =
to
archive signed data.=20

=20

>    This is done, in part, so the archive service can operate without=20

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

>    also does not provide any means to integrate verification data in=20

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

=20

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.

=20

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

=20

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! =20

=20

=20

------

=20

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.

=20

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

=20

----

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

=20

We must always keep in mind that the digital archive should offer al =
least
the same services as the paper or parchment archive.=20

=20

Unfortunately the real archivist will decide about law and orders which =
will
enable to replace paper archives with digital ones.

=20

Libor

------=_NextPart_000_000F_01C3E83F.F2461A10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D400010723-31012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Libor:</FONT></SPAN></DIV>
<DIV><SPAN class=3D400010723-31012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D400010723-31012004><FONT face=3DArial color=3D#0000ff =
size=3D2>See my=20
responses in line</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>[email-masked]<BR><B>Sent:</B> Saturday, January =
31, 2004=20
  2:35 PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> My =
objections to=20
  the submitted draft<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D785372319-31012004><FONT=20
  face=3D"Times New Roman" size=3D3>Hi,&nbsp;</FONT></SPAN></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US">I have several things in the =
submitted draft=20
  which are unclear to me. To have a Berger orientation I put here also =
the=20
  unclear parts of the draft marked with the leading &gt;.=20
<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt; 2. =
Terminology<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt; =
&#8230;<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>Timestamp: A signed confirmation generated by a Time Stamping=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>Authority (TSA) that a data item existed at a certain =
time.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>[RFC3161] specifies a good structure for timestamps and a =
protocol=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>for communicating with a Timestamp Authority (TSA).<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">It=20
  is a bit foolish to build everything on the &#8220;classical&#8220; =
time stamp. <SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>Realize that the time stamp =
is also=20
  only a digitally signed structure&#8230; I do not understand why this =
draft does not=20
  mention the time stamp acc. to RFC3161 only as eventuality and why it =
is not=20
  more open to time stamps based on the linking hash principle. If we =
bind time=20
  stamp based on linking hash to the archived document, we could give to =
the=20
  court not one but two independent evidences of the document=20
  validity.<BR></FONT></FONT><FONT size=3D2><FONT face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D400010723-31012004>[Santosh =
Chokhani]&nbsp;There may=20
  be some patent related concerns regarding the linked time stamp =
(Surety in=20
  US).&nbsp;</SPAN><o:p></o:p></FONT></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">I.e. digital signatures of archived documents =
would be=20
  added with nonsigned<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>attribute &#8211;=20
  the enhanced time stamp based on other cryptographical principle =
&#8211; the linking=20
  hash.<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
  base difference between time stamps based on linking hashes and those =
acc. to=20
  the RFC3161 is the fact that the time stamps based on the RFC3161 =
expire with=20
  the expiration of their Time Stamping Authority certificate which =
issued them=20
  (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=20
  hashes expire when the used hash algorithm proves to be too week, =
which=20
  represents incomparably longer time. <SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&#8230;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt; 3.2<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>Long-term =
Archive Service=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>A Long-term Archive Service is to be designed to solve =
essential=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>parts of these problems by providing a specialized service:=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
  </SPAN>- The Long-term Archive Service is to store archived data =
objects=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>over a long, optionally undefined, period of time&#8230;=20
  .<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">No=20
  reasonable company or organization will not archive its documents for=20
  undefined time period. Every organization has its archiving and =
canceling=20
  order which exactly defines the archiving time for every particular =
document=20
  type. (In most countries, it has been already legislated in =
19<SUP>th</SUP>=20
  century.)<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">But=20
  many of documents are archived permanently. This is the most =
complicated=20
  problem and the main aim of LTANS should be to solve problems of =
permanent=20
  archiving of digitally signed or timestamped documents.&nbsp;<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;<BR><SPAN =
class=3D400010723-31012004><FONT=20
  face=3DArial color=3D#0000ff size=3D2>[Santosh Chokhani]&nbsp;I think =
LTANS is=20
  trying to solve that=20
  problem&nbsp;</FONT></SPAN></SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>- The Long-term Archive Service provides material needed to =
prove the=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>existence and integrity of data objects for users as well as in =

  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>court.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
  preceding sentence is not consistent with the following=20
  sentence:<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>A Long-term Archive Service is to not be designed to solve all=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>thinkable problems of long-term-verification of digital=20
  signatures.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>It does not provide data necessary to verify signatures which =
are=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>part of the archived data object itself.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>This has to be done by=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>verifiers using PKI-Services like SCVP (Simple Certificate =
Validation=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>Protocol) or DVCS (Data Validation and Certification Server).=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">How=20
  could the TAA give the evidence about the existence and integrity of a =

  document without the data necessary for the verification of such=20
  evidence!?<BR><SPAN class=3D400010723-31012004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>[Santosh Chokhani]&nbsp;The party who archives the data is =
responsible=20
  for providing all the evidence that it might need.&nbsp; Thus, if some =
one=20
  wants to archive digital signatures or digital signatures and SCVP =
responses,=20
  they need to include the signed document, signed SCVP responses and =
SCVP trust=20
  anchor in order to obtain these from the TAA at a later time and =
demonstrate=20
  the signature was valid at some time in the=20
  past.</FONT></SPAN></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2><SPAN =
class=3D400010723-31012004></SPAN></FONT></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">I=20
  think that we can discuss many things which the TAA standard should =
order or=20
  recommend, but it is no doubt that the TAA is obliged to give to a =
user all=20
  the required data necessary for existence and integrity proof of the=20
  appropriate document. Without this function the TAA would be only some =
type of=20
  data store.<BR></FONT></FONT><FONT size=3D2><FONT face=3DArial><FONT=20
  color=3D#0000ff><SPAN class=3D400010723-31012004>[Santosh =
Chokhani]&nbsp;I think=20
  TAA needs to play back what the user submitted and ensure the =
integrity of the=20
  user submission.&nbsp; If the data happens to be signed data, the user =
can=20
  submit relevant trust anchors, certificates, and revocation =
information to=20
  demonstrate the signature was valid&nbsp;when applied.&nbsp; But, TAA =
need not=20
  gather all this; neither does TAA need to be limited to archive signed =

  data.&nbsp;</SPAN><o:p></o:p></FONT></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman"><SPAN=20
  style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>This is done, in part, so the archive service can operate =
without=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>knowledge of numerous signed data formats, document formats, =
etc.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>It=20
<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>also does not provide any means to integrate verification data =
in=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
  </SPAN>data objects and verify embedded signatures.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>This has to be done on=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>the basis of other specifications, like RFC 3029 and with =
regard to=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>specifications of document formats.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Of course it is recommended =
to=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
  </SPAN>use such specifications together with a Long-term Archive =
Service.=20
  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">In=20
  this article of the draft, we can see that it is necessary to separate =
the=20
  draft work into several parallel standards. I.g. it is necessary =
either to=20
  make the RFC3029 into a form of an official standard or to define =
formats of=20
  archiving data.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">We=20
  cannot run the TAA without format specifications. The archive can =
accept only=20
  data it can guarantee to be able to view them in undistorted form =
during the=20
  whole archiving time. It is not possible for the TAA not to take care =
for the=20
  archived data formats.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">Let=20
  us have the following example: we have a record of important =
government=20
  meeting stored in the MS Word 3.0. Such document should be archived=20
  permanently, but what to do with the document in MS Word 3.0 format =
(even now=20
  you probably will have a trouble to view it without distortion!) =
Obviously,=20
  the TAA could not accept such document!<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
  suggested draft does not take care about migration and emulation of =
archived=20
  documents.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">------<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
  lifetime of the archived document is also not solved in this draft. =
According=20
  to this draft, the archive only accepts and returns documents. It does =
not=20
  take care for document cataloging, searching of documents, viewing of=20
  documents in undistorted form and document=20
  canceling.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">But=20
  document canceling seems to be very important archive functionality =
&#8211; it does=20
  not mean only destroying of the particular document but in some cases =
also=20
  export of the canceled document into another archive.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">----<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New =
Roman"><FONT size=3D3>I=20
  am afraid that the submitted draft is only the idea of IT people how =
to=20
  archive documents and it should be discussed with real archivists =
which have=20
  their own idea about archiving. The archivists have a different =
approach and=20
  to create a useful digital archive we should listen to them.<SPAN=20
  class=3D785372319-31012004> </SPAN></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New =
Roman"><FONT=20
  size=3D3><SPAN =
class=3D785372319-31012004></SPAN></FONT></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New =
Roman"><FONT=20
  size=3D3><SPAN class=3D785372319-31012004>We must always keep in mind =
that the=20
  digital archive should offer al least the same services as the paper =
or=20
  parchment archive. </SPAN></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New =
Roman"><FONT=20
  size=3D3><SPAN =
class=3D785372319-31012004></SPAN></FONT></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New =
Roman"><FONT=20
  size=3D3><SPAN class=3D785372319-31012004>Unfortunately the real =
archivist will=20
  decide about law and orders which will enable to replace paper =
archives with=20
  digital ones.</SPAN></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman"></FONT></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D+0><FONT=20
  face=3D"Times New Roman"><FONT size=3D3><SPAN=20
  =
class=3D785372319-31012004>Libor</SPAN></FONT></FONT></FONT></SPAN></P></=
FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000F_01C3E83F.F2461A10--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Role of attribute certificates in long-term archiving
Date: Sat, 31 Jan 2004 21:19:35 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C3E83F.EEF911F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Marta:
=20
There does not seem to be any benefit gained by using the attribute
certificate format for archived data.

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, January 31, 2004 4:11 PM
To: [email-masked]
Subject: Role of attribute certificates in long-term archiving

Hi all,
I am reading the archiving conference very carefuly and I hope that my =
idea
abou attribute certification usage could be useful for your long term
archiving standard creation.
=20
Identification of  a user accessing the archive is interesting problem. =
But
I think it is solved in the RFC-3281 and it is not necessary to specify =
it
more. We should use the RFC-3281 which is of "Standard Track" category. =
It
would be enough to solve the structure of archived documents because the
attribute certificates (RFC-3281) will be always bound to some subtree =
of
this structure.

=20

It would be difficult to find out something what is more suitable for
attribute certificate usage than the long-term archiving. Any archive =
will
be different (third party archiving service, specialized archive for =
company
or for notaries etc.) Realize that the person storing the document into =
the
archive is rarely the real document owner.

One example: invoice. According to the company internal orders, an
accountant marks the archiving time in the invoice and stores the =
document
into an archive. The archived invoice is owned not by the accountant but =
by
the company. The accountant cannot e.g. delete the invoice in the =
archive.=20

=20

During the archiving lifetime of the document, an inspection of a state =
tax
office can come. Another company employee must pick up the invoice copy =
from
the archive and submit it for the inspection.=20

=20

When the archived invoice lifetime is over, the invoice must be =
cancelled
(destroyed) from the archive. And again another person of the company is
responsible for canceling. This person must decide whether to cancel
document or whether to archive it later (for example, if the company is =
in
bankruptcy, it is required to archive documents later) or put the =
document
for the permanent archiving (e.g. invoice for crown jewelry.)

=20

Attribute certificate can vary in time according to e.g. changes in some
database of clients of archive. They are bound with the user's =
certificate.
The conclusion is: we can issue attribute certificates for (in this =
case):

-         Accountant (rights for invoice archiving)

-         Manager (rights for picking invoices up from the archive to
inspect them)

-         Officer responsible for document canceling

-         In case of open document we can have also an attribute =
certificate
(view right) for all who sign the commitment not to abuse the document

Attribute certificate are very flexible and can be issued for e.g. one =
day
because the people roles and access rights can change quickly. The =
permanent
bind of a concrete role to a concrete person does not exist.

=20

Cordially Marta

=20

Marta Vohnoutova PVT a.s. Czech Republic

[email-masked]

------=_NextPart_000_000A_01C3E83F.EEF911F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D469221802-01022004>Marta:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D469221802-01022004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D469221802-01022004>There=20
does not seem to be any benefit gained by using the attribute =
certificate format=20
for archived data.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>[email-masked]<BR><B>Sent:</B> Saturday, =
January 31,=20
  2004 4:11 PM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Role =
of=20
  attribute certificates in long-term archiving<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>Hi=20
  all,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>I am =
reading the=20
  archiving conference very carefuly and I hope that my idea abou =
attribute=20
  certification usage could be useful for your long term archiving =
standard=20
  creation.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D011465320-31012004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">Identification of<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>a user accessing the archive is interesting problem. But I =
think it is=20
  solved in the RFC-3281 and it is not necessary to specify it more. We =
should=20
  use the RFC-3281 which is of &#8222;Standard Track&#8220; category. It =
would be enough to=20
  solve the structure of archived documents because the attribute =
certificates=20
  (RFC-3281) will be always bound to some subtree of this=20
  structure.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">It=20
  would be difficult to find out something what is more suitable for =
attribute=20
  certificate usage than the long-term archiving. Any archive will be =
different=20
  (third party archiving service, specialized archive for company or for =

  notaries etc.) Realize that the person storing the document into the =
archive=20
  is rarely the real document owner.<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">One=20
  example: invoice. According to the company internal orders, an =
accountant=20
  marks the archiving time in the invoice and stores the document into =
an=20
  archive. The archived invoice is owned not by the accountant but by =
the=20
  company. The accountant cannot e.g. delete the invoice in the archive. =

  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">During the archiving lifetime of the =
document, an=20
  inspection of a state tax office can come. Another company employee =
must pick=20
  up the invoice copy from the archive and submit it for the inspection. =

  <o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">When the archived invoice lifetime is over, =
the invoice=20
  must be cancelled (destroyed) from the archive. And again another =
person of=20
  the company is responsible for canceling. This person must decide =
whether to=20
  cancel document or whether to archive it later (for example, if the =
company is=20
  in bankruptcy, it is required to archive documents later) or put the =
document=20
  for the permanent archiving (e.g. invoice for crown=20
  jewelry&#8230;)<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman" =

  size=3D3>&nbsp;</FONT></o:p></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
  face=3D"Times New Roman">Attribute certificate can vary in time =
according to=20
  e.g. changes in some database of clients of archive. They are bound =
with the=20
  user&#8217;s certificate. The conclusion is: we can issue attribute =
certificates for=20
  (in this case):<o:p></o:p></FONT></FONT></SPAN></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN lang=3DEN-US =
style=3D"mso-ansi-language: EN-US"><SPAN=20
  style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
  size=3D3>Accountant (rights for invoice=20
  archiving)<o:p></o:p></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN lang=3DEN-US =
style=3D"mso-ansi-language: EN-US"><SPAN=20
  style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
  size=3D3>Manager (rights for picking invoices up from the archive to =
inspect=20
  them)<o:p></o:p></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN lang=3DEN-US =
style=3D"mso-ansi-language: EN-US"><SPAN=20
  style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
  size=3D3>Officer responsible for document=20
  canceling<o:p></o:p></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
  face=3D"Times New Roman"><SPAN lang=3DEN-US =
style=3D"mso-ansi-language: EN-US"><SPAN=20
  style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
  size=3D3>In case of open document we can have also an attribute =
certificate=20
  (view right) for all who sign the commitment not to abuse the=20
  document<o:p></o:p></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman" =
size=3D3>Attribute=20
  certificate are very flexible and can be issued for e.g. one day =
because the=20
  people roles and access rights can change quickly. The permanent bind =
of a=20
  concrete role to a concrete person does not exist.</FONT></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"=20
  size=3D3></FONT></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D011465320-31012004>Cordially=20
  Marta</SPAN></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><SPAN=20
  class=3D011465320-31012004></SPAN></SPAN>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D011465320-31012004>Marta=20
  Vohnoutova PVT a.s. Czech Republic</SPAN></SPAN></P>
  <P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
  style=3D"mso-ansi-language: EN-US"><SPAN=20
  =
class=3D011465320-31012004>[email-masked]</SPAN></SPAN></P></SPA=
N></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000A_01C3E83F.EEF911F0--

From: "[email-masked]" <[email-masked]>
To: <[email-masked]>
Subject: Role of attribute certificates in long-term archiving
Date: Sat, 31 Jan 2004 22:11:00 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C3E847.226C49B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,
I am reading the archiving conference very carefuly and I hope that my
idea abou attribute certification usage could be useful for your long
term archiving standard creation.
 
Identification of  a user accessing the archive is interesting problem.
But I think it is solved in the RFC-3281 and it is not necessary to
specify it more. We should use the RFC-3281 which is of "Standard Track"
category. It would be enough to solve the structure of archived
documents because the attribute certificates (RFC-3281) will be always
bound to some subtree of this structure.

It would be difficult to find out something what is more suitable for
attribute certificate usage than the long-term archiving. Any archive
will be different (third party archiving service, specialized archive
for company or for notaries etc.) Realize that the person storing the
document into the archive is rarely the real document owner.

One example: invoice. According to the company internal orders, an
accountant marks the archiving time in the invoice and stores the
document into an archive. The archived invoice is owned not by the
accountant but by the company. The accountant cannot e.g. delete the
invoice in the archive. 

During the archiving lifetime of the document, an inspection of a state
tax office can come. Another company employee must pick up the invoice
copy from the archive and submit it for the inspection. 

When the archived invoice lifetime is over, the invoice must be
cancelled (destroyed) from the archive. And again another person of the
company is responsible for canceling. This person must decide whether to
cancel document or whether to archive it later (for example, if the
company is in bankruptcy, it is required to archive documents later) or
put the document for the permanent archiving (e.g. invoice for crown
jewelry.)

Attribute certificate can vary in time according to e.g. changes in some
database of clients of archive. They are bound with the user's
certificate. The conclusion is: we can issue attribute certificates for
(in this case):

-         Accountant (rights for invoice archiving)

-         Manager (rights for picking invoices up from the archive to
inspect them)

-         Officer responsible for document canceling

-         In case of open document we can have also an attribute
certificate (view right) for all who sign the commitment not to abuse
the document

Attribute certificate are very flexible and can be issued for e.g. one
day because the people roles and access rights can change quickly. The
permanent bind of a concrete role to a concrete person does not exist.

Cordially Marta

Marta Vohnoutova PVT a.s. Czech Republic

[email-masked]

------=_NextPart_000_0001_01C3E847.226C49B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Zpr&aacute;va</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>Hi=20
all,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>I am =
reading the=20
archiving conference very carefuly and I hope that my idea abou =
attribute=20
certification usage could be useful for your long term archiving =
standard=20
creation.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D011465320-31012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D011465320-31012004>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">Identification of<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>a user accessing the archive is interesting problem. But I think =
it is=20
solved in the RFC-3281 and it is not necessary to specify it more. We =
should use=20
the RFC-3281 which is of &#8222;Standard Track&#8220; category. It would =
be enough to solve=20
the structure of archived documents because the attribute certificates=20
(RFC-3281) will be always bound to some subtree of this=20
structure.<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">It=20
would be difficult to find out something what is more suitable for =
attribute=20
certificate usage than the long-term archiving. Any archive will be =
different=20
(third party archiving service, specialized archive for company or for =
notaries=20
etc.) Realize that the person storing the document into the archive is =
rarely=20
the real document owner.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">One=20
example: invoice. According to the company internal orders, an =
accountant marks=20
the archiving time in the invoice and stores the document into an =
archive. The=20
archived invoice is owned not by the accountant but by the company. The=20
accountant cannot e.g. delete the invoice in the archive.=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">During the archiving lifetime of the document, =
an=20
inspection of a state tax office can come. Another company employee must =
pick up=20
the invoice copy from the archive and submit it for the inspection.=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">When=20
the archived invoice lifetime is over, the invoice must be cancelled =
(destroyed)=20
from the archive. And again another person of the company is responsible =
for=20
canceling. This person must decide whether to cancel document or whether =
to=20
archive it later (for example, if the company is in bankruptcy, it is =
required=20
to archive documents later) or put the document for the permanent =
archiving=20
(e.g. invoice for crown =
jewelry&#8230;)<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">Attribute certificate can vary in time =
according to e.g.=20
changes in some database of clients of archive. They are bound with the =
user&#8217;s=20
certificate. The conclusion is: we can issue attribute certificates for =
(in this=20
case):<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
face=3D"Times New Roman"><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
size=3D3>Accountant (rights for invoice=20
archiving)<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
face=3D"Times New Roman"><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
size=3D3>Manager (rights for picking invoices up from the archive to =
inspect=20
them)<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
face=3D"Times New Roman"><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
size=3D3>Officer responsible for document=20
canceling<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18pt; mso-list: l0 =
level1 lfo1; tab-stops: list 36.0pt"><FONT=20
face=3D"Times New Roman"><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>-</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DEN-US style=3D"mso-ansi-language: =
EN-US"><FONT=20
size=3D3>In case of open document we can have also an attribute =
certificate (view=20
right) for all who sign the commitment not to abuse the=20
document<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman" =
size=3D3>Attribute=20
certificate are very flexible and can be issued for e.g. one day because =
the=20
people roles and access rights can change quickly. The permanent bind of =
a=20
concrete role to a concrete person does not exist.</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"=20
size=3D3></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D011465320-31012004>Cordially=20
Marta</SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><SPAN=20
class=3D011465320-31012004></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D011465320-31012004>Marta Vohnoutova=20
PVT a.s. Czech Republic</SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><SPAN=20
class=3D011465320-31012004>[email-masked]</SPAN></SPAN></P></SPA=
N></FONT></DIV></BODY></HTML>

------=_NextPart_000_0001_01C3E847.226C49B0--

From: <[email-masked]>
To: <[email-masked]>
Subject: My objections to the submitted draft
Date: Sat, 31 Jan 2004 20:35:25 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0046_01C3E839.CF120370
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi, 

.    

the 

Validation 

It 

------

----

Libor

------=_NextPart_000_0046_01C3E839.CF120370
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Zpr&aacute;va</TITLE>

<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><SPAN =
class=3D785372319-31012004><FONT=20
face=3D"Times New Roman" size=3D3>Hi,&nbsp;</FONT></SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US">I have several things in the =
submitted draft=20
which are unclear to me. To have a Berger orientation I put here also =
the=20
unclear parts of the draft marked with the leading &gt;. <?xml:namespace =
prefix=20
=3D o ns =3D "urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">&gt;=20
2. Terminology<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">&gt;=20
&#8230;<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Timestamp: A signed confirmation generated by a Time Stamping=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Authority (TSA) that a data item existed at a certain time.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>[RFC3161] specifies a good structure for timestamps and a =
protocol=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>for communicating with a Timestamp Authority (TSA).<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">It is=20
a bit foolish to build everything on the &#8220;classical&#8220; time =
stamp. <SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Realize that the time stamp is =
also only=20
a digitally signed structure&#8230; I do not understand why this draft =
does not=20
mention the time stamp acc. to RFC3161 only as eventuality and why it is =
not=20
more open to time stamps based on the linking hash principle. If we bind =
time=20
stamp based on linking hash to the archived document, we could give to =
the court=20
not one but two independent evidences of the document=20
validity.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">I.e.=20
digital signatures of archived documents would be added with =
nonsigned<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>attribute &#8211; the enhanced =
time stamp=20
based on other cryptographical principle &#8211; the linking hash.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
base difference between time stamps based on linking hashes and those =
acc. to=20
the RFC3161 is the fact that the time stamps based on the RFC3161 expire =
with=20
the expiration of their Time Stamping Authority certificate which issued =
them=20
(see that we face exactly the same problem we faced in case of digital=20
signature, what this draft should solve), while time stamps based on =
linking=20
hashes expire when the used hash algorithm proves to be too week, which=20
represents incomparably longer time. <SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&#8230;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">&gt;=20
3.2<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>Long-term =
Archive=20
Service <o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>A Long-term Archive Service is to be designed to solve essential=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>parts of these problems by providing a specialized service:=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp; </SPAN>-=20
The Long-term Archive Service is to store archived data objects=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>over a long, optionally undefined, period of time&#8230;=20
.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">No=20
reasonable company or organization will not archive its documents for =
undefined=20
time period. Every organization has its archiving and canceling order =
which=20
exactly defines the archiving time for every particular document type. =
(In most=20
countries, it has been already legislated in 19<SUP>th</SUP>=20
century.)<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">But=20
many of documents are archived permanently. This is the most complicated =
problem=20
and the main aim of LTANS should be to solve problems of permanent =
archiving of=20
digitally signed or timestamped documents. <SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>- The Long-term Archive Service provides material needed to prove =
the=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>existence and integrity of data objects for users as well as in=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>court.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
preceding sentence is not consistent with the following=20
sentence:<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>A Long-term Archive Service is to not be designed to solve all=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>thinkable problems of long-term-verification of digital =
signatures.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>It does not provide data necessary to verify signatures which are =

<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>part of the archived data object itself.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>This has to be done by=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>verifiers using PKI-Services like SCVP (Simple Certificate =
Validation=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>Protocol) or DVCS (Data Validation and Certification Server).=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">How=20
could the TAA give the evidence about the existence and integrity of a =
document=20
without the data necessary for the verification of such evidence!? I =
think that=20
we can discuss many things which the TAA standard should order or =
recommend, but=20
it is no doubt that the TAA is obliged to give to a user all the =
required data=20
necessary for existence and integrity proof of the appropriate document. =
Without=20
this function the TAA would be only some type of data=20
store.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>This is done, in part, so the archive service can operate without =

<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>knowledge of numerous signed data formats, document formats, =
etc.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>It =
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>also does not provide any means to integrate verification data in =

<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>data objects and verify embedded signatures.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>This has to be done on=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>the basis of other specifications, like RFC 3029 and with regard =
to=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>specifications of document formats.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
</SPAN>Of course it is recommended to =
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">&gt;<SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;=20
</SPAN>use such specifications together with a Long-term Archive =
Service.=20
<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">In=20
this article of the draft, we can see that it is necessary to separate =
the draft=20
work into several parallel standards. I.g. it is necessary either to =
make the=20
RFC3029 into a form of an official standard or to define formats of =
archiving=20
data.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">We=20
cannot run the TAA without format specifications. The archive can accept =
only=20
data it can guarantee to be able to view them in undistorted form during =
the=20
whole archiving time. It is not possible for the TAA not to take care =
for the=20
archived data formats.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">Let=20
us have the following example: we have a record of important government =
meeting=20
stored in the MS Word 3.0. Such document should be archived permanently, =
but=20
what to do with the document in MS Word 3.0 format (even now you =
probably will=20
have a trouble to view it without distortion!) Obviously, the TAA could =
not=20
accept such document!<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
suggested draft does not take care about migration and emulation of =
archived=20
documents.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">------<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">The=20
lifetime of the archived document is also not solved in this draft. =
According to=20
this draft, the archive only accepts and returns documents. It does not =
take=20
care for document cataloging, searching of documents, viewing of =
documents in=20
undistorted form and document =
canceling.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT face=3D"Times =
New Roman">But=20
document canceling seems to be very important archive functionality =
&#8211; it does=20
not mean only destroying of the particular document but in some cases =
also=20
export of the canceled document into another archive.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; =
</SPAN><o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman">----<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"><FONT =
size=3D3>I am=20
afraid that the submitted draft is only the idea of IT people how to =
archive=20
documents and it should be discussed with real archivists which have =
their own=20
idea about archiving. The archivists have a different approach and to =
create a=20
useful digital archive we should listen to them.<SPAN =
class=3D785372319-31012004>=20
</SPAN></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"><FONT =
size=3D3><SPAN=20
class=3D785372319-31012004></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"><FONT =
size=3D3><SPAN=20
class=3D785372319-31012004>We must always keep in mind that the digital =
archive=20
should offer al least the same services as the paper or parchment =
archive.=20
</SPAN></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"><FONT =
size=3D3><SPAN=20
class=3D785372319-31012004></SPAN></FONT></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT face=3D"Times New Roman"><FONT =
size=3D3><SPAN=20
class=3D785372319-31012004>Unfortunately the real archivist will decide =
about law=20
and orders which will enable to replace paper archives with digital=20
ones.</SPAN></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><FONT><FONT face=3D"Times New =
Roman"><FONT=20
size=3D3><SPAN=20
class=3D785372319-31012004>Libor</SPAN></FONT></FONT></FONT></SPAN></P></=
FONT></DIV></BODY></HTML>

------=_NextPart_000_0046_01C3E839.CF120370--

Date: Thu, 29 Jan 2004 13:08:34 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - authentication
Cc: [email-masked]
Sender: [email-masked]

> 
> I agree with peter completely. I also think one needs to clarify what
> procedures are we discussing about. Authorization is something that
> gives you power (or not) to access or use something. While
> identification is something else. So in case of archival services
> authorization is seen through rights to use the service or not (and of
> course the level of usage). However we still must keep the fact in mind
> that whatever we are archiving always belongs to somebody (something??).

Yes, and it seems that the question is to what degree the payload data
are ... let's labelled or tainted with identification, types, roles,
locations, etc. 

Such information need to be grouped in several categories depending
on at least three interested parties:

- the client itself, delegation of rights to employees or roles
- the service (to distinguish groups of users, accounting, etc
- other relying parties and external authorities
  (fiscal identification, locality, jurisdiction, ...)
 
> So the major question is: who has the rights to access the archived
> item? And after that: how do we identify the person with the acess
> rights? I think this should be clarified before we can even discuss the
> operational steages of the service.

There are many things which seems out of scope of this group. I
am not sure whether one has to develop more than containers and
type indications for identification data can be provided by/for a requester
and for information can be associated to the request and response payloads
so that these can be input for some decision making service using
things like XACML SAML ... 
 
> My wiev is, that this two main functions might be separated (although
> tightly corelated to the service), i.e. an authority identifying
> subjects in an open environment or mapping the rights to a subject. For
> example, as Peter stated, if I put something in the archive on behalf of
> my company, who will access the same archive once I change my job? Where
> are the connections between former and present employee? 

Just to remind another point: The authorition decision may not be possible
'on line' (as in many real life cases), thus a request to retrieve
or validate cannot necessarily be answered immediately and may need
manual intervention.
Such a delay is not a problem, since it may be necessary to retrieve
some disk from a bunker or else.  

Peter

Date: Thu, 29 Jan 2004 12:39:01 +0100 (CET)
From: Alexandre Dulaunoy <[email-masked]>
To: "A. Jerman Blazic" <[email-masked]>
Cc: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - authentication
Sender: [email-masked]

On Thu, 29 Jan 2004, A. Jerman Blazic wrote:

> > This identification (potentially in an anonymous form) is then 
> > associated by the provider with some authentication method: 
> > You get a user/password.  20 years later (and even earlier) you 
> > should be able to provide the same identification information 
> > (or better, the the id of your grandparents) to access.
> 
> I agree with peter completely. I also think one needs to clarify what
> procedures are we discussing about. Authorization is something that
> gives you power (or not) to access or use something. While
> identification is something else. So in case of archival services
> authorization is seen through rights to use the service or not (and of
> course the level of usage). However we still must keep the fact in mind
> that whatever we are archiving always belongs to somebody (something??).
> So the major question is: who has the rights to access the archived
> item? And after that: how do we identify the person with the acess
> rights? I think this should be clarified before we can even discuss the
> operational steages of the service.

Yes,  you are  right.  Just  for  an example,  the freearchive.org  is
setting up and the authorization is working on two methods :

- An  open  approach   (as  we  gather  free  works)   with  a  manual
  verification of  the work (on  the legal (if  the work is  free) and
  technical side (if the work permits a long-term storage)). 

- An authenticated approach where  the manual verification is bypassed
  as the submission  is coming from trusted sources  (can be people or
  other digital repositories with an OAI or alike interface). 

On the  two methods, an unique  ID is generated by  the repository for
tracking the life of the digital work. 

Freearchive is  a specific case  where all work  are frees and  can be
distributed  without  any restrictions.   I  think,  this approach  is
well-known in various public domain digital libraries. I don't know if
you can take this easily in the draft document. 

For the operational stages that seem more complicated to explain.

Thanks a lot for your work,

adulau

-- 
-- 	  	     Alexandre Dulaunoy (adulau) -- http://www.foo.be/
-- 	   http://pgp.ael.be:11371/pks/lookup?op=get&search=0x44E6CBCD
-- 	   "Knowledge can create problems, it is not through ignorance
-- 				  that we can solve them" Isaac Asimov

From: "A. Jerman Blazic" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - authentication
Date: Thu, 29 Jan 2004 11:21:58 +0100
Importance: Normal
Sender: [email-masked]

> > > 
> > > Isn't Authentication 'at distance' but not 'in time'.
> > 
> > Basically I see a problem concerning the time too. The methods of 
> > authentification may change during the lifetime of a document (even 
> > more than once). And with that you might get problems. 
> Let's e.g. say 
> > you archived a contract about your newly bought house or 
> something and 
> > used at the beginning user/password authentication. For the next 20 
> > years you are basically probably not interested in the document and 
> > might even forget your password, although you still have the URL of 
> > the document with all the evidence records. In the future 
> maybe even 
> > user/password authentication is no longer accepted by the server so 
> > you need something different
> > - but what is important for the system: are you the same 
> person that 
> > stored the document 20 years ago ?
> 
> Even with user/password you don't make a proof that you are 
> the person that stored, only that some accesses who knows 
> these values. 
> 
> There is a difference betwenn identification and authentication.
> 
> The 'user' is not your 'identification', but an means for 
> authentication. You long term identification are the data on 
> your birth certificate; thus, when you register to such a 
> service, you have probably always to provide some information 
> about who you are, a copy of your national id card or whatever. 
> 
> This identification (potentially in an anonymous form) is then 
> associated by the provider with some authentication method: 
> You get a user/password.  20 years later (and even earlier) you 
> should be able to provide the same identification information 
> (or better, the the id of your grandparents) to access.

I agree with peter completely. I also think one needs to clarify what
procedures are we discussing about. Authorization is something that
gives you power (or not) to access or use something. While
identification is something else. So in case of archival services
authorization is seen through rights to use the service or not (and of
course the level of usage). However we still must keep the fact in mind
that whatever we are archiving always belongs to somebody (something??).
So the major question is: who has the rights to access the archived
item? And after that: how do we identify the person with the acess
rights? I think this should be clarified before we can even discuss the
operational steages of the service.

My wiev is, that this two main functions might be separated (although
tightly corelated to the service), i.e. an authority identifying
subjects in an open environment or mapping the rights to a subject. For
example, as Peter stated, if I put something in the archive on behalf of
my company, who will access the same archive once I change my job? Where
are the connections between former and present employee?

Aleksej

> > 
> > Authorisation:
> > In my understanding authorisation comes after some kind of 
> authentication
> > (i.e. at first you know the identity of the other and then 
> you think about
> > to allow him access to the data).
> 
> > A role based access control seems feasable and hopefully not to 
> > complicated. (Maybe added with some sercret (document id ?) 
> generated 
> > at the time of
> > storage.) 
> > 
> > The "judge/relevant authority" is of course on.
> > A second one will be the user who stored the data. (Of 
> course he wants to be
> > able to receive the evidence and maybe even the data he stored.)
> 
> You almost never have the situation that some data only 
> belongs to one person durng a long period in time. The most 
> simplistic authorisation model which just has a 1=1 
> correspondance is not sufficient. You can die at any moment, 
> you can delegate your power to someone else at any time etc. 
>   
> > Small remark: If the trusted archive does not provide the 
> data itself 
> > to normal requests, the authorisation topic might be easy, 
> as I think 
> > the retrieval of evidence to a document might not be a 
> security issue. 
> > The request for evidence could contain either the data or a 
> hash-value 
> > of the data (as long as the hash-algorithm is still secure).
> 
> A not so small response :-)
> 
> A request to an archiver may live the following way:
> 
> - someone has archived data and received an attestions that
>   contains the relevant metadata like:
>   "Person XYZ has archived a contract between A, B, C concerning xxx 
>   at date D in the city of L conforming to law ZZZ and application
>   degree GGG etc. The concerned parties are fiscally related to FFF.
>   
>   The content of the document has the hash H1 with hashes h2 to Hn
>   for the chapters 2 to n", 
>   all that (most likely), digitally signed by the archive provider
>   at the moment you receive it.
> 
> - the digital signature can be confirmed with a hash link to
>   a published daily hash next day or there is an ability to present
>   the attestation to the archive provider asking whether this 
> attestation 
>   is a good one by looking at his archive log.  
> 
> - If the relying parties can't agree,
>   or when this is a fiscal control, etc
>   a service needs to return the data. For this case
>   one cannot depend on the good will of the initial
>   client if the archived data are not in favor of his
>   claim. Thus, a judge or even the other party may
>   access. This may bring us to a requieremnt where
>   the initial archiver should be able to indicate 
>   "identification information" of all the
>   potential concerned relying parties. This
>   identification information can be persons or
>   companies, but also "done at Paris" in order
>   to indicate that a judge in some court in Paris
>   may access.
> 
> (If hash algs are not secure, you still have physical copies 
> that are dated.)
> 
>    
> 
> 
> 

Date: Wed, 28 Jan 2004 15:52:22 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - authentication
Cc: [email-masked]
Sender: [email-masked]

> > 
> > Isn't Authentication 'at distance' but not 'in time'. 
> 
> Basically I see a problem concerning the time too. The methods of
> authentification may change during the lifetime of a document (even more
> than once). And with that you might get problems.
> Let's e.g. say you archived a contract about your newly bought house or
> something and used at the beginning user/password authentication. For the
> next 20 years you are basically probably not interested in the document and
> might even forget your password, although you still have the URL of the
> document with all the evidence records. In the future maybe even
> user/password authentication is no longer accepted by the server so you need
> something different 
> - but what is important for the system: are you the same person that stored
> the document 20 years ago ?

Even with user/password you don't make a proof that you are the person
that stored, only that some accesses who knows these values. 

There is a difference betwenn identification and authentication.

The 'user' is not your 'identification', but an means for authentication.
You long term identification are the data on your birth certificate;
thus, when you register to such a service, you have probably always
to provide some information about who you are, a copy of your
national id card or whatever. 

This identification (potentially in an anonymous form) is then 
associated by the provider with some authentication method: 
You get a user/password.  20 years later (and even earlier) you 
should be able to provide the same identification information
(or better, the the id of your grandparents) to access.

> 
> Authorisation: 
> In my understanding authorisation comes after some kind of authentication
> (i.e. at first you know the identity of the other and then you think about
> to allow him access to the data).

> A role based access control seems feasable and hopefully not to complicated.
> (Maybe added with some sercret (document id ?) generated at the time of
> storage.) 
> 
> The "judge/relevant authority" is of course on. 
> A second one will be the user who stored the data. (Of course he wants to be
> able to receive the evidence and maybe even the data he stored.)

You almost never have the situation that some data only belongs to
one person durng a long period in time. The most simplistic
authorisation model which just has a 1=1 correspondance is not
sufficient. You can die at any moment, you can delegate your
power to someone else at any time etc. 
  
> Small remark: If the trusted archive does not provide the data itself to
> normal requests, the authorisation topic might be easy, as I think the
> retrieval of evidence to a document might not be a security issue. The
> request for evidence could contain either the data or a hash-value of the
> data (as long as the hash-algorithm is still secure).

A not so small response :-)

A request to an archiver may live the following way:

- someone has archived data and received an attestions that
  contains the relevant metadata like:
  "Person XYZ has archived a contract between A, B, C concerning xxx 
  at date D in the city of L conforming to law ZZZ and application
  degree GGG etc. The concerned parties are fiscally related to FFF.
  
  The content of the document has the hash H1 with hashes h2 to Hn
  for the chapters 2 to n", 
  all that (most likely), digitally signed by the archive provider
  at the moment you receive it.

- the digital signature can be confirmed with a hash link to
  a published daily hash next day or there is an ability to present
  the attestation to the archive provider asking whether this attestation 
  is a good one by looking at his archive log.  

- If the relying parties can't agree,
  or when this is a fiscal control, etc
  a service needs to return the data. For this case
  one cannot depend on the good will of the initial
  client if the archived data are not in favor of his
  claim. Thus, a judge or even the other party may
  access. This may bring us to a requieremnt where
  the initial archiver should be able to indicate 
  "identification information" of all the
  potential concerned relying parties. This
  identification information can be persons or
  companies, but also "done at Paris" in order
  to indicate that a judge in some court in Paris
  may access.

(If hash algs are not secure, you still have physical copies
that are dated.)

From: "Carl Wallace" <[email-masked]>
To: "'Brian Hunter'" <[email-masked]>
Cc: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ?
Date: Wed, 28 Jan 2004 09:15:59 -0500
Importance: Normal
Sender: [email-masked]

> 
>  > Archive Authority must be trusted if it is providing trust 
> anchor  > information.
> 
> I am not sure I follow this point.  What would this trust anchor 
> information be?

When verifying signatures that accrue over time, trust anchors may be
necessary that are not active at the time of verification.  An archive could
serve as a repository for past trust anchors.  An archive acting in this
capacity would need to be trusted.

From: Tobias Gondrom <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - authentication
Date: Wed, 28 Jan 2004 14:54:02 +0100
Importance: low
Sender: [email-masked]

> As suggested, I just take a subpart of the messages and add 
> some centimes in a brain storming way.
> 
> > 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...
> 
> 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 ...   
> 
> > I see the authentication problem quite similar and have at the moment 
> > not 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. 

I agree with you Peter. Seems to be better to allow authentication but we
don't need to specify the used technique so that different services are free
to implement what fits best.

> > 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 ?
> 
> Isn't Authentication 'at distance' but not 'in time'. 

Basically I see a problem concerning the time too. The methods of
authentification may change during the lifetime of a document (even more
than once). And with that you might get problems.
Let's e.g. say you archived a contract about your newly bought house or
something and used at the beginning user/password authentication. For the
next 20 years you are basically probably not interested in the document and
might even forget your password, although you still have the URL of the
document with all the evidence records. In the future maybe even
user/password authentication is no longer accepted by the server so you need
something different 
- but what is important for the system: are you the same person that stored
the document 20 years ago ?

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

Authorisation: 
In my understanding authorisation comes after some kind of authentication
(i.e. at first you know the identity of the other and then you think about
to allow him access to the data).

A role based access control seems feasable and hopefully not to complicated.
(Maybe added with some sercret (document id ?) generated at the time of
storage.) 

The "judge/relevant authority" is of course on. 
A second one will be the user who stored the data. (Of course he wants to be
able to receive the evidence and maybe even the data he stored.)

Small remark: If the trusted archive does not provide the data itself to
normal requests, the authorisation topic might be easy, as I think the
retrieval of evidence to a document might not be a security issue. The
request for evidence could contain either the data or a hash-value of the
data (as long as the hash-algorithm is still secure).

From: Tobias Gondrom <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej - Confidentiality
Date: Wed, 28 Jan 2004 14:41:20 +0100
Sender: [email-masked]

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

My personal answer would be to trust only things that can be evaluated and
that are actually evaluated (e.g. source from LINUX, large community working
with Windows and ISV-Firewalls). In general I would say that customers rely
on the reputation of a system, on results of independent tests (including
hackers and audits) and some of the promises of the provider.

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

Maybe Peter is right and you simply have to trust your provider. :-/
(at least you have a contract and probably pay your provider for the service
and the provider could gain some additional trust by independent audits)

Still I am very sure we have to provide the ability to store (and provide
evidence for) encrypted data. For many people this will be the first way to
trust an external provider.
(And in some countries it might also be forbidden to let the data even only
theoretically be accessible to other persons)

Date: Wed, 28 Jan 2004 14:26:54 +0100
From: Brian Hunter <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: "'Tobias Gondrom'" <[email-masked]>, [email-masked]
Subject: Re: Initial requirements for long-term archive I-D - wording: Trusted archiving ?
Sender: [email-masked]

Carl Wallace wrote:
>>For that I would prefer if we could change the names from : 
>>"Trusted Archiving" to "Archiving" 
>>And from: "Trusted Archive Authority" to "Archive Authority" or "Archive
> 
> Service" 
> 
> The word "trusted" provides a hint that something more than simple storage
> of the data is going on (even if the actual trust is in the TSA).  Also, an

I agree.  The differentiation between a simple archive service (only 
document storage) and an archive service that obtains evidence of 
document existence is important.

 > Archive Authority must be trusted if it is providing trust anchor
 > information.

I am not sure I follow this point.  What would this trust anchor 
information be?

Regards,
Brian

From: "Carl Wallace" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: Initial requirements for long-term archive I-D - wording: Trusted archiving ?
Date: Tue, 27 Jan 2004 14:22:40 -0500
Importance: Normal
Sender: [email-masked]

> For that I would prefer if we could change the names from : 
> "Trusted Archiving" to "Archiving" 
> And from: "Trusted Archive Authority" to "Archive Authority" or "Archive
Service" 

The word "trusted" provides a hint that something more than simple storage
of the data is going on (even if the actual trust is in the TSA).  Also, an
Archive Authority must be trusted if it is providing trust anchor
information.    

Date: Tue, 27 Jan 2004 20:10:43 +0100
From: =?ISO-8859-1?Q?Paul-Andr=E9_PAYS?= <[email-masked]>
Organization: Edelweb - Groupe ON-X
To: Tobias Gondrom <[email-masked]>
CC: [email-masked]
Subject: Re: Initial requirements for long-term archive I-D - wording: Tru sted archiving ?
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070309030606060405030308
Content-Type: multipart/alternative;
 boundary="------------080302060304000808090501"

This is a multi-part message in MIME format.
--------------080302060304000808090501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

My 2 cts,

    * on one hand I agree with you the archive need not (in all cases)
      be operated by a third party (a separate legal entity with
      official gov'tal evaluation and possibly certification), it only
      requires the level of "separation of power" appropriate for the
      specific evidence creation context and requirements. When I say it
      only requires the appropriate independance, this should be
      understood as a very strong statement in many environments. For
      example in B2C transactions, because i) you can't expect the
      C(onsumer) side to reliably "archive" its own documents or "data
      certificates" on its Information System made of a single home PC,
      and ii) the "entity" owning the archive has the technical ability
      and power to "delete" these "evidences" and pretend these never
      existed; in this case it really has to be an independant party=20
      (no capital letters, but 100% independant from B).
    * on the other hand -my understanding- this archive service must be
      completely reliable so that the concerned entities can "trust" it.
      Thus for me, "*trusted archiving*" is i) equivalent to "reliable
      archival service" (in a given context) and does not mean
      (necessarily) "Third Party".

In short, I feel confortable with today terminology as long as a=20
glossary is provided which explains the semantic attached to each of=20
these terms (for example along the line of my above understanding), and=20
pinpoints the fact that the actual official nature (appropriately=20
separate archival service in some cases, effective trusted third party=20
in others) is completely context dependant. The context is the legal=20
context with the requirements for "evidence creation".
LTANS should focus on technical solutions and not on these "legal"=20
environments.
I you consider that the term "trusted" conveys too much third party=20
meening, I would accept "reliable archive" as long as it is explained=20
that reliable is not only related technical reliability but also=20
includes the appropriate independance (buwinesswise and legaly wise)

-- PAP

Tobias Gondrom wrote:

> Hello,
>
> I would like to discuss in section 2 "Terminology" the name "Trusted=20
> Archiving" and TAA:
>
> This name "Trusted" is somehow confusing for me. For me "Trusted"=20
> implies that the archive is a somehow trusted third party that needs=20
> some evalutions by some government authority. I don't think that such=20
> is necessary. All the mechanisms to ensure the integrity of the data=20
> can be based on the trustworthyness of the TSP (that has to be a=20
> trusted third party as changing e.g. the time of the server would be=20
> disasterous).
>
> Of course the documents have to be stored and it has to be taken care=20
> that the needed steps of resigning are taken but all this is normal=20
> business.
>
> For that I would prefer if we could change the names from :
>
> "Trusted Archiving" to "Archiving"
> And from: "Trusted Archive Authority" to "Archive Authority" or=20
> "Archive Service"
>
> Best regards
>
>         Tobias
>
>
>
>
> Tobias Gondrom
> Senior Software Architect
> Engineering
>
> *IXOS Software AG*
> Technopark Neukeferloh
> Bretonischer Ring 12
> D-85630 Grasbrunn/M=FCnchen
>
> E-Mail:_ [email-masked]
> WWW:_ __http://www.ixos.com_
> Tel: +49-89-4629-1816
> Fax: +49-89-4629-33-1816
>
> This eMail may contain confidential and/or privileged information. If=20
> you are not the intended recipient or have received this eMail in=20
> error, please notify the sender immediately and destroy this eMail.=20
> Any use, disclosure or distribution of the material in this eMail is=20
> strictly forbidden.
>
> Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte=20
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese=20
> eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den=20
> Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung,=20
> Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.
>

--=20
Paul-Andr=E9 PAYS                 [email-masked]   ou  [email-masked]
Directeur 			EdelWeb & P=F4le S=E9curit=E9 Groupe ON-X
http://www.edelweb.fr/          http://www.on-x.com/
tel: +33 1 40 99 29 55          fax : +33 1 40 99 03 30
-----
Pour v=E9rifier la signature : https://www.openevidence.org/OEROOT-ca.der=

--------------080302060304000808090501
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
My 2 cts,<br>
<br>
<ul>
  <li>on one hand I agree with you the archive need not (in all cases)
be operated by a third party (a separate legal entity with official
gov'tal evaluation and possibly certification), it only requires the
level of "separation of power" appropriate for the specific evidence
creation context and requirements. When I say it only requires the
appropriate independance, this should be understood as a very strong
statement in many environments. For example in B2C transactions,
because i) you can't expect the C(onsumer) side to reliably "archive"
its own documents or "data certificates" on its Information System made
of a single home PC, and ii) the "entity" owning the archive has the
technical ability and power to "delete" these "evidences" and pretend
these never existed; in this case it really has to be an independant
party&nbsp; (no capital letters, but 100% independant from B).<br>
  </li>
  <li>on the other hand -my understanding- this archive service must be
completely reliable so that the concerned entities can "trust" it. Thus
for me, "<b>trusted archiving</b>" is i) equivalent to "reliable
archival service" (in a given context) and does not mean (necessarily)
"Third Party".</li>
</ul>
In short, I feel confortable with today terminology as long as a
glossary is provided which explains the semantic attached to each of
these terms (for example along the line of my above understanding), and
pinpoints the fact that the actual official nature (appropriately
separate archival service in some cases, effective trusted third party
in others) is completely context dependant. The context is the legal
context with the requirements for "evidence creation".<br>
LTANS should focus on technical solutions and not on these "legal"
environments.<br>
I you consider that the term "trusted" conveys too much third party
meening, I would accept "reliable archive" as long as it is explained
that reliable is not only related technical reliability but also
includes the appropriate independance (buwinesswise and legaly wise)<br>
<br>
-- PAP<br>
<br>
<br>
Tobias Gondrom wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <meta content="text/html; " http-equiv="Content-Type">
  <meta content="MS Exchange Server version 5.5.2653.12"
 name="Generator">
  <title>RE: Initial requirements for long-term archive I-D - wording:
Trusted archiving ?</title>
  <p><font face="Arial" size="2">Hello, </font>
  </p>
  <p><font face="Arial" size="2">I would like to discuss in section 2
"Terminology" the name "Trusted Archiving" and TAA:</font>
  </p>
  <p><font face="Arial" size="2">This name "Trusted" is somehow
confusing for me. For me "Trusted" implies that the archive is a
somehow trusted third party that needs some evalutions by some
government authority. I don't think that such is necessary. All the
mechanisms to ensure the integrity of the data can be based on the
trustworthyness of the TSP (that has to be a trusted third party as
changing e.g. the time of the server would be disasterous).</font></p>
  <p><font face="Arial" size="2">Of course the documents have to be
stored and it has to be taken care that the needed steps of resigning
are taken but all this is normal business.</font></p>
  <p><font face="Arial" size="2">For that I would prefer if we could
change the names from :</font>
  </p>
  <p><font face="Arial" size="2">"Trusted Archiving" to "Archiving" </font>
  <br>
  <font face="Arial" size="2">And from: "Trusted Archive Authority" to
"Archive Authority" or "Archive Service"</font>
  </p>
  <p><font face="Arial" size="2">Best regards</font>
  </p>
  <p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial" size="2">Tobias</font>
  </p>
  <br>
  <br>
  <br>
  <p><font face="Arial" size="1">Tobias Gondrom</font>
  <br>
  <font face="Arial" size="1">Senior Software Architect</font>
  <br>
  <font face="Arial" size="1">Engineering</font>
  </p>
  <p><b><font face="Arial" size="1">IXOS Software AG</font></b>
  <br>
  <font face="Arial" size="1">Technopark Neukeferloh</font>
  <br>
  <font face="Arial" size="1">Bretonischer Ring 12</font>
  <br>
  <font face="Arial" size="1">D-85630 Grasbrunn/M&uuml;nchen</font>
  </p>
  <p><font face="Arial" size="1">E-Mail:<u> </u></font><u><font
 face="Arial" size="1" color="#0000ff"><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></font></u>
  <br>
  <font face="Arial" size="1">WWW:</font><u> </u><a
 href="http://www.ixos.com"><u><font face="Arial" size="1"
 color="#0000ff">http://www.ixos.com</font></u></a>
  <br>
  <font face="Arial" size="1">Tel: +49-89-4629-1816</font>
  <br>
  <font face="Arial" size="1">Fax: +49-89-4629-33-1816</font>
  </p>
  <p><font face="Arial" size="1" color="#000000">This eMail may contain
confidential and/or privileged information. If you are not the intended
recipient or have received this eMail in error, please notify the
sender immediately and destroy this eMail. Any use, disclosure or
distribution of the material in this eMail is strictly forbidden.</font></p>
  <p><font face="Arial" size="1">Diese eMail enth&auml;lt vertrauliche
und/oder rechtlich gesch&uuml;tzte Informationen. Wenn Sie nicht der
richtige Adressat sind oder diese eMail irrt&uuml;mlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
eMail. Jegliche Art der Verwendung, Vervielf&auml;ltigung oder Weitergabe
ist nicht gestattet.</font></p>
</blockquote>
<br>
<pre cols="72" class="moz-signature">-- 
Paul-Andr&eacute; PAYS                 <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>   ou  <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Directeur 			EdelWeb &amp; P&ocirc;le S&eacute;curit&eacute; Groupe ON-X
<a class="moz-txt-link-freetext" href="http://www.edelweb.fr/">http://www.edelweb.fr/</a>          <a class="moz-txt-link-freetext" href="http://www.on-x.com/">http://www.on-x.com/</a>
tel: +33 1 40 99 29 55          fax : +33 1 40 99 03 30
-----
Pour v&eacute;rifier la signature : <a class="moz-txt-link-freetext" href="https://www.openevidence.org/OEROOT-ca.der">https://www.openevidence.org/OEROOT-ca.der</a></pre>
</body>
</html>

--------------080302060304000808090501--

--------------ms070309030606060405030308
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070309030606060405030308--

Date: Tue, 27 Jan 2004 19:41:57 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ?
Sender: [email-masked]

> 
> This name "Trusted" is somehow confusing for me. For me "Trusted" implies
> that the archive is a somehow trusted third party that needs some evalutions
> by some government authority. I don't think that such is necessary. All the
> mechanisms to ensure the integrity of the data can be based on the
> trustworthyness of the TSP (that has to be a trusted third party as changing
> e.g. the time of the server would be disasterous).

You loose integrity of data when you loose the data. I guess you need
to trust that the archive service 'does its best'.    

Date: Tue, 27 Jan 2004 19:33:50 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej
Cc: [email-masked]
Sender: [email-masked]

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

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

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

> I see the authentication problem quite similar and have at the moment not
> 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 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 ?

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

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.  

From: Tobias Gondrom <[email-masked]>
To: [email-masked]
Subject: RE: Initial requirements for long-term archive I-D - wording: Tru sted archiving ?
Date: Tue, 27 Jan 2004 19:20:33 +0100
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3E502.40D91650
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,=20

I would like to discuss in section 2 "Terminology" the name "Trusted
Archiving" and TAA:

This name "Trusted" is somehow confusing for me. For me "Trusted" =
implies
that the archive is a somehow trusted third party that needs some =
evalutions
by some government authority. I don't think that such is necessary. All =
the
mechanisms to ensure the integrity of the data can be based on the
trustworthyness of the TSP (that has to be a trusted third party as =
changing
e.g. the time of the server would be disasterous).

Of course the documents have to be stored and it has to be taken care =
that
the needed steps of resigning are taken but all this is normal =
business.

For that I would prefer if we could change the names from :

"Trusted Archiving" to "Archiving"=20
And from: "Trusted Archive Authority" to "Archive Authority" or =
"Archive
Service"

Best regards

	Tobias

Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: [email-masked]
WWW: http://www.ixos.com <http://www.ixos.com>=20
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain confidential and/or privileged information. If =
you
are not the intended recipient or have received this eMail in error, =
please
notify the sender immediately and destroy this eMail. Any use, =
disclosure or
distribution of the material in this eMail is strictly forbidden.
Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung
oder Weitergabe ist nicht gestattet.

------_=_NextPart_001_01C3E502.40D91650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Initial requirements for long-term archive I-D - wording: =
Trusted archiving ?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello, </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to discuss in section 2 =
&quot;Terminology&quot; the name &quot;Trusted Archiving&quot; and =
TAA:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This name &quot;Trusted&quot; is =
somehow confusing for me. For me &quot;Trusted&quot; implies that the =
archive is a somehow trusted third party that needs some evalutions by =
some government authority. I don't think that such is necessary. All =
the mechanisms to ensure the integrity of the data can be based on the =
trustworthyness of the TSP (that has to be a trusted third party as =
changing e.g. the time of the server would be disasterous).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Of course the documents have to be =
stored and it has to be taken care that the needed steps of resigning =
are taken but all this is normal business.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For that I would prefer if we could =
change the names from :</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Trusted Archiving&quot; to =
&quot;Archiving&quot; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">And from: &quot;Trusted Archive =
Authority&quot; to &quot;Archive Authority&quot; or &quot;Archive =
Service&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best regards</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Tobias</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">Tobias Gondrom</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Senior Software Architect</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Engineering</FONT>
</P>

<P><B><FONT SIZE=3D1 FACE=3D"Arial">IXOS Software AG</FONT></B>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Technopark Neukeferloh</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Bretonischer Ring 12</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">D-85630 Grasbrunn/M=FCnchen</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">E-Mail:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Arial">[email-masked]</FONT></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">WWW:</FONT><U> </U><A =
HREF=3D"http://www.ixos.com"><U></U><U></U><U><FONT COLOR=3D"#0000FF" =
SIZE=3D1 =
FACE=3D"Arial">http://www.ixos.com</FONT></U><U></U></A><U></U><U></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Tel: +49-89-4629-1816</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Fax: +49-89-4629-33-1816</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">This eMail may =
contain confidential and/or privileged information. If you are not the =
intended recipient or have received this eMail in error, please notify =
the sender immediately and destroy this eMail. Any use, disclosure or =
distribution of the material in this eMail is strictly =
forbidden.</FONT></P>

<P><FONT SIZE=3D1 FACE=3D"Arial">Diese eMail enth=E4lt vertrauliche =
und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der =
richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, =
informieren Sie bitte sofort den Absender und vernichten Sie diese =
eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe =
ist nicht gestattet.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C3E502.40D91650--

From: Tobias Gondrom <[email-masked]>
To: "'A. Jerman Blazic'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Initial requirements for long-term archive I-D  - coments fro m aleksej
Date: Tue, 27 Jan 2004 18:11:47 +0100
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3E4F8.A54F3600
Content-Type: text/plain

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

------_=_NextPart_001_01C3E4F8.A54F3600
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=859054016-27012004><FONT face=Arial color=#0000ff size=2>Dear 
<SPAN class=164022216-13012004><FONT 
face="Courier New">Aleksej,</FONT></SPAN></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New" color=#0000ff 
  size=2>Dear Tobias and others</FONT></SPAN></DIV>
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New" color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New" color=#0000ff 
  size=2>First of all, I am pleased LTANS did produce one of the first 
  discussable drafts.</FONT></SPAN></DIV>
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New" color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=ltr><SPAN class=164022216-13012004><SPAN class=859054016-27012004><FONT 
face="Courier New" color=#0000ff size=2>Thanks. The same for 
me.</FONT></SPAN></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New" color=#0000ff 
  size=2>In the first place I do have some&nbsp;views&nbsp;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&nbsp;<SPAN class=859054016-27012004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></SPAN><SPAN 
  class=164022216-13012004><FONT face="Courier New"><FONT color=#0000ff><FONT 
  size=2>(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".&nbsp;<SPAN class=859054016-27012004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=ltr><SPAN class=164022216-13012004><FONT face="Courier New"><FONT 
color=#0000ff><FONT size=2><SPAN 
class=859054016-27012004></SPAN></FONT></FONT></FONT></SPAN><SPAN 
class=164022216-13012004><FONT face="Courier New"><FONT><FONT 
color=#0000ff><FONT size=2><SPAN class=859054016-27012004><FONT face=Arial>
<DIV dir=ltr><SPAN class=164022216-13012004><FONT face="Courier New" 
color=#0000ff size=2><SPAN class=859054016-27012004>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).</SPAN></FONT></SPAN></FONT></SPAN></FONT></FONT></FONT></FONT></SPAN></DIV></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=164022216-13012004><FONT face="Courier New"><FONT><FONT 
  color=#0000ff><FONT size=2>I guess data structures are trying to focus on 
  later but conservation mechanisms seems&nbsp;like missing or at least no 
  indirect linkage to additional specifications are mentioned, of course if 
  there are&nbsp;some (XAdES??)....<SPAN class=859054016-27012004><FONT 
  face=Arial>&nbsp;</FONT></SPAN></FONT></FONT></FONT></FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=ltr><SPAN class=164022216-13012004><FONT face="Courier New"><FONT 
color=#0000ff><FONT size=2><SPAN class=859054016-27012004>
<DIV dir=ltr><SPAN class=164022216-13012004><FONT face=Arial color=#0000ff 
size=2><SPAN class=859054016-27012004>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.</SPAN></FONT></SPAN></DIV>
<DIV dir=ltr><SPAN class=164022216-13012004><FONT face=Arial color=#0000ff 
size=2><SPAN 
class=859054016-27012004></SPAN></FONT></SPAN>&nbsp;</DIV></SPAN></FONT></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face="Courier New"><FONT size=2><SPAN 
  class=164022216-13012004><FONT size=+0><FONT color=#0000ff>Next, in the 
  document (page 4) redundant storage, disaster recovery, etc. are 
  mentioned.&nbsp;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&nbsp;and should be dealt as 
  is.<SPAN class=859054016-27012004><FONT face=Arial 
  size=2>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face="Courier New"><FONT size=2><SPAN 
  class=164022216-13012004><FONT size=+0><FONT color=#0000ff><SPAN 
  class=859054016-27012004></SPAN></FONT></FONT></SPAN></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face="Courier New"><FONT size=2><SPAN 
class=164022216-13012004><FONT size=+0><FONT color=#0000ff><SPAN 
class=859054016-27012004>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)</SPAN></FONT></FONT></SPAN></FONT></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face="Courier New"><FONT size=2><FONT color=#0000ff><SPAN 
  class=164022216-13012004>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...</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face="Courier New"><FONT size=2><FONT color=#0000ff><SPAN 
  class=164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>I see the authentication 
problem quite similar and have at the moment not the optimal solution for it. 
:(</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>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. </SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>On the other hand how 
can one achieve authentication across very long times spans of decades 
?</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN 
class=859054016-27012004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>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.)</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>[see also page 9 bottom: 
"protocol should permit encryption of data before submission..." 
]</SPAN></SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face="Courier New"><SPAN class=164022216-13012004><FONT 
  color=#0000ff><FONT size=2><SPAN class=859054016-27012004><FONT 
  face=Arial>&nbsp;</FONT></SPAN>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&nbsp;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?</FONT></FONT></SPAN></FONT></DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>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]</SPAN></SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face="Courier New"><FONT size=2><FONT color=#0000ff><SPAN 
  class=164022216-13012004>Hope this will trigger some 
  discussion...</SPAN></FONT></FONT></FONT></DIV>
  <DIV><FONT face="Courier New"><FONT size=2><FONT color=#0000ff><SPAN 
  class=164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV></BLOCKQUOTE>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>Hoping the same and 
thank you. (and please forgive me that my answer came so late - I was for some 
days on winter holiday....)</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN 
class=859054016-27012004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>For further discussion 
I&nbsp;encourage&nbsp;anyone to feel free and isolate any topic he wants from 
the conversation and discuss it on the mailing-list.</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN 
class=859054016-27012004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN 
class=859054016-27012004>Regards</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN 
class=859054016-27012004></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face="Courier New" color=#0000ff size=2><SPAN 
class=164022216-13012004><SPAN class=859054016-27012004>&nbsp;&nbsp;&nbsp; 
Tobias</SPAN></SPAN></FONT></DIV>
<DIV dir=ltr><FONT face=Arial><FONT size=2><SPAN class=859054016-27012004><FONT 
color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C3E4F8.A54F3600--

From: "A. Jerman Blazic" <[email-masked]>
To: "'Tobias Gondrom'" <[email-masked]>, <[email-masked]>
Subject: RE: Initial requirements for long-term archive I-D 
Date: Tue, 13 Jan 2004 17:59:14 +0100
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear Tobias and others
=20
First of all, I am pleased LTANS did produce one of the first
discussable drafts.
=20
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". 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??)....
=20
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.
=20
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...
=20
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?
=20
Hope this will trigger some discussion...
=20
Regards
=20
Aleksej

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tobias Gondrom
Sent: Monday, January 12, 2004 6:41 PM
To: [email-masked]'
Subject: Initial requirements for long-term archive I-D=20
Importance: High

Hello,=20

Thanks to Carl, Uli and Ralf we finished the=20
"Initial requirements for long-term archive I-D "=20
(first milestone, unfortunately 6 weeks behind schedule)=20
<<draft-ietf-ltans-reqs-01.txt>>=20

I would like to encourage now the discussion for this draft on the
mailing-list as fast as possible as the following standards (data
structures and protocol)  will be targeting to fulfill the discussed
requirements. The initial drafts for these 2 documents are also behind
schedule but initial documents shall be available for discussion end of
january.

Please keep best practices for the discussion in mind:=20
- discuss the different sections for the document individually=20
- if possible list the chapter you want to change and the old and the
new text to make it easier for the others to follow the discussion and
for the editor.

At the moment there are even topics for dicusiion open from the writing
of the initial paper.=20

Best regards=20

        Tobias=20

Tobias Gondrom=20
Senior Software Architect=20
Engineering=20

IXOS Software AG=20
Technopark Neukeferloh=20
Bretonischer Ring 12=20
D-85630 Grasbrunn/M=FCnchen=20

E-Mail: [email-masked]=20
WWW:  <http://www.ixos.com> http://www.ixos.com=20
Tel: +49-89-4629-1816=20
Fax: +49-89-4629-33-1816=20

This eMail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this eMail in error,
please notify the sender immediately and destroy this eMail. Any use,
disclosure or distribution of the material in this eMail is strictly
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung,
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D164022216-13012004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>Dear Tobias and others</FONT></SPAN></DIV>
<DIV><SPAN class=3D164022216-13012004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D164022216-13012004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>First of all, I am pleased LTANS did produce one of the first =
discussable=20
drafts.</FONT></SPAN></DIV>
<DIV><SPAN class=3D164022216-13012004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D164022216-13012004><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>In the first place I do have some&nbsp;views&nbsp;on the =
general document=20
structure, which is very "Trusted Archive Protocol" oriented. In my =
view, one=20
has to distinguish two main logical parts of the archive, which is =
protocol=20
interaction mechanisms, i.e. trusted archive protocol or a point of =
user's=20
interaction with an archive. The other is archive itself and integrated=20
mechanisms for assuring object validity over defined or undefined period =
of time=20
(I do distinguish at least two measures of archiving period, although=20
e-archiving is tightly related to needs/requirements/obligations on =
content=20
archiving, so many "time-frame" definitions are possible) in combination =
with=20
archived object "management". I guess data structures are trying to =
focus on=20
later but conservation mechanisms seems&nbsp;like missing or at least no =

indirect linkage to additional specifications are mentioned, of course =
if there=20
are&nbsp;some (XAdES??)....</FONT></SPAN></DIV>
<DIV><SPAN class=3D164022216-13012004></SPAN>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004><FONT>Next, in the document (page 4) =
redundant storage,=20
disaster recovery, etc. are mentioned.&nbsp;Data storage mechanisms =
should be=20
out of the scope of the e-archive, since back-up mechanisms and systems =
are=20
something which one can find on, let's say, "lower" infrastructure=20
layer&nbsp;and should be dealt as =
is.</FONT></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004>User authentication is another problem in =
wide scale=20
deployment of archive services. Bearing in mind that privacy is one of =
the (more=20
and more) important factor in open infrastructure, confidentiality is =
even more=20
important in case of formal content handling (contracts, invoices!!).=20
Furthermore, DVCS exposes the content to authority at least, and has =
serious=20
confidentiality problems...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004>On page 5 and 6, TAA is presented as a =
document storage=20
service, which in certain case doesn't have to. My personal view is, =
that=20
archiving does not mean only archiving service but extended =
functionality of=20
existing document warehouses or management systems. In this case, TAA is =
a=20
service maintaining only archiving&nbsp;related data and not content by =
itself,=20
i.e. timestamps, CRLs, DVCS responses, etc. Also the same service means =
single=20
point of interaction for many content related services. Do we really =
need such=20
content redundancy?</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004>Hope this will trigger some=20
discussion...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004>Regards</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D164022216-13012004>Aleksej</SPAN></FONT></FONT></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Tobias Gondrom<BR><B>Sent:</B> Monday, January 12, 2004 =
6:41=20
  PM<BR><B>To:</B> [email-masked]'<BR><B>Subject:</B> Initial =
requirements=20
  for long-term archive I-D <BR><B>Importance:</B> =
High<BR><BR></FONT></DIV>
  <P><FONT face=3DArial size=3D2>Hello,</FONT> </P>
  <P><FONT face=3DArial size=3D2>Thanks to Carl, Uli and Ralf we =
finished the=20
  </FONT><BR><FONT face=3DArial size=3D2>"</FONT><FONT=20
  face=3D"Times New Roman">Initial requirements for long-term archive =
I-D</FONT>=20
  <FONT face=3DArial size=3D2>"</FONT> <BR><FONT face=3DArial =
size=3D2>(first milestone,=20
  unfortunately 6 weeks behind schedule)</FONT> <BR><FONT face=3DArial=20
  color=3D#000000 size=3D2>&lt;&lt;draft-ietf-ltans-reqs-01.txt&gt;&gt; =
</FONT></P>
  <P><FONT face=3DArial size=3D2>I would like to encourage now the =
discussion for=20
  this draft on the mailing-list as fast as possible as the following =
standards=20
  (data structures and protocol)&nbsp; will be targeting to fulfill the=20
  discussed requirements. The initial drafts for these 2 documents are =
also=20
  behind schedule but initial documents shall be available for =
discussion end of=20
  january.</FONT></P>
  <P><FONT face=3DArial size=3D2>Please keep best practices for the =
discussion in=20
  mind:</FONT> <BR><FONT face=3DArial size=3D2>- discuss the different =
sections for=20
  the document individually</FONT> <BR><FONT face=3DArial size=3D2>- if =
possible=20
  list the chapter you want to change and the old and the new text to =
make it=20
  easier for the others to follow the discussion and for the =
editor.</FONT></P>
  <P><FONT face=3DArial size=3D2>At the moment there are even topics for =
dicusiion=20
  open from the writing of the initial paper.</FONT> </P>
  <P><FONT face=3DArial size=3D2>Best regards</FONT> </P>
  <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
  size=3D2>Tobias</FONT> </P><BR><BR>
  <P><FONT face=3DArial size=3D1>Tobias Gondrom</FONT> <BR><FONT =
face=3DArial=20
  size=3D1>Senior Software Architect</FONT> <BR><FONT face=3DArial=20
  size=3D1>Engineering</FONT> </P>
  <P><B><FONT face=3DArial size=3D1>IXOS Software AG</FONT></B> =
<BR><FONT face=3DArial=20
  size=3D1>Technopark Neukeferloh</FONT> <BR><FONT face=3DArial =
size=3D1>Bretonischer=20
  Ring 12</FONT> <BR><FONT face=3DArial size=3D1>D-85630 =
Grasbrunn/M=FCnchen</FONT>=20
  </P>
  <P><FONT face=3DArial size=3D1>E-Mail:<U> </U></FONT><U><FONT =
face=3DArial=20
  color=3D#0000ff size=3D1>[email-masked]</FONT></U> <BR><FONT =
face=3DArial=20
  size=3D1>WWW:</FONT><U> </U><A =
href=3D"http://www.ixos.com"><U></U><U></U><U><FONT=20
  face=3DArial color=3D#0000ff=20
  size=3D1>http://www.ixos.com</FONT></U><U></U></A><U></U><U></U> =
<BR><FONT=20
  face=3DArial size=3D1>Tel: +49-89-4629-1816</FONT> <BR><FONT =
face=3DArial=20
  size=3D1>Fax: +49-89-4629-33-1816</FONT> </P>
  <P><FONT face=3DArial color=3D#000000 size=3D1>This eMail may contain =
confidential=20
  and/or privileged information. If you are not the intended recipient =
or have=20
  received this eMail in error, please notify the sender immediately and =
destroy=20
  this eMail. Any use, disclosure or distribution of the material in =
this eMail=20
  is strictly forbidden.</FONT></P>
  <P><FONT face=3DArial size=3D1>Diese eMail enth=E4lt vertrauliche =
und/oder rechtlich=20
  gesch=FCtzte Informationen. Wenn Sie nicht der richtige Adressat sind =
oder diese=20
  eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und=20
  vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder=20
  Weitergabe ist nicht gestattet.</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AD_01C3D9FE.F49FF4B0--

From: Tobias Gondrom <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Initial requirements for long-term archive I-D 
Date: Mon, 12 Jan 2004 18:40:52 +0100
Importance: high
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C3D933.398CBCB0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D933.398CBCB0"

------_=_NextPart_001_01C3D933.398CBCB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

Thanks to Carl, Uli and Ralf we finished the=20
"Initial requirements for long-term archive I-D "
(first milestone, unfortunately 6 weeks behind schedule)
 <<draft-ietf-ltans-reqs-01.txt>>=20

I would like to encourage now the discussion for this draft on the
mailing-list as fast as possible as the following standards (data =
structures
and protocol)  will be targeting to fulfill the discussed requirements. =
The
initial drafts for these 2 documents are also behind schedule but =
initial
documents shall be available for discussion end of january.

Please keep best practices for the discussion in mind:
- discuss the different sections for the document individually
- if possible list the chapter you want to change and the old and the =
new
text to make it easier for the others to follow the discussion and for =
the
editor.

At the moment there are even topics for dicusiion open from the writing =
of
the initial paper.

Best regards

	Tobias

Tobias Gondrom
Senior Software Architect
Engineering

IXOS Software AG
Technopark Neukeferloh
Bretonischer Ring 12
D-85630 Grasbrunn/M=FCnchen

E-Mail: [email-masked]
WWW: http://www.ixos.com <http://www.ixos.com>=20
Tel: +49-89-4629-1816
Fax: +49-89-4629-33-1816

This eMail may contain confidential and/or privileged information. If =
you
are not the intended recipient or have received this eMail in error, =
please
notify the sender immediately and destroy this eMail. Any use, =
disclosure or
distribution of the material in this eMail is strictly forbidden.
Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung
oder Weitergabe ist nicht gestattet.

------_=_NextPart_001_01C3D933.398CBCB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Initial requirements for long-term archive I-D </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks to Carl, Uli and Ralf we =
finished the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;</FONT><FONT FACE=3D"Times New =
Roman">Initial requirements for long-term archive I-D</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(first milestone, unfortunately 6 =
weeks behind schedule)</FONT>
<BR><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;draft-ietf-ltans-reqs-01.txt&gt;&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to encourage now the =
discussion for this draft on the mailing-list as fast as possible as =
the following standards (data structures and protocol)&nbsp; will be =
targeting to fulfill the discussed requirements. The initial drafts for =
these 2 documents are also behind schedule but initial documents shall =
be available for discussion end of january.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please keep best practices for the =
discussion in mind:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- discuss the different sections for =
the document individually</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">- if possible list the chapter you =
want to change and the old and the new text to make it easier for the =
others to follow the discussion and for the editor.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">At the moment there are even topics =
for dicusiion open from the writing of the initial paper.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best regards</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Tobias</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D1 FACE=3D"Arial">Tobias Gondrom</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Senior Software Architect</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Engineering</FONT>
</P>

<P><B><FONT SIZE=3D1 FACE=3D"Arial">IXOS Software AG</FONT></B>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Technopark Neukeferloh</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Bretonischer Ring 12</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">D-85630 Grasbrunn/M=FCnchen</FONT>
</P>

<P><FONT SIZE=3D1 FACE=3D"Arial">E-Mail:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Arial">[email-masked]</FONT></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">WWW:</FONT><U> </U><A =
HREF=3D"http://www.ixos.com"><U></U><U></U><U><FONT COLOR=3D"#0000FF" =
SIZE=3D1 =
FACE=3D"Arial">http://www.ixos.com</FONT></U><U></U></A><U></U><U></U>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Tel: +49-89-4629-1816</FONT>
<BR><FONT SIZE=3D1 FACE=3D"Arial">Fax: +49-89-4629-33-1816</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">This eMail may =
contain confidential and/or privileged information. If you are not the =
intended recipient or have received this eMail in error, please notify =
the sender immediately and destroy this eMail. Any use, disclosure or =
distribution of the material in this eMail is strictly =
forbidden.</FONT></P>

<P><FONT SIZE=3D1 FACE=3D"Arial">Diese eMail enth=E4lt vertrauliche =
und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der =
richtige Adressat sind oder diese eMail irrt=FCmlich erhalten haben, =
informieren Sie bitte sofort den Absender und vernichten Sie diese =
eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung oder Weitergabe =
ist nicht gestattet.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C3D933.398CBCB0--

------_=_NextPart_000_01C3D933.398CBCB0
Content-Type: text/plain;
	name="draft-ietf-ltans-reqs-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ltans-reqs-01.txt"

Internet Draft                                          Carl Wallace=20
draft-ietf-ltans-reqs-01.txt                Orion Security Solutions=20
January 2004                                           Ralf Brandner=20
Expires July 2004                     InterComponentWare AG Walldorf
                                                     Ulrich Pordesch=20
                                                Fraunhofer Institute=20
                                              Secure Telecooperation=20
   =20
   =20
                  Long-term Archive Service Requirements=20
   =20
   =20
Status of this Memo=20
   =20
   This document is an Internet-Draft and is in full conformance with=20
   all provisions of Section 10 of [RFC2026]. =20
   =20
   Internet-Drafts are working documents of the Internet Engineering=20
   Task Force (IETF), its areas, and its working groups.  Note that=20
   other groups may also distribute working documents as Internet-
   Drafts.=20
   =20
   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced or made obsolete by other documents at=20
   any time.  It is inappropriate to use Internet-Drafts as reference=20
   material or to cite them other than as "work in progress."=20
   =20
   The list of current Internet-Drafts can be accessed at=20
        http://www.ietf.org/ietf/1id-abstracts.txt=20
   =20
   The list of Internet-Draft Shadow Directories can be accessed at=20
        http://www.ietf.org/shadow.html.=20
   =20
   =20
Copyright Notice=20
   =20
   Copyright (C) The Internet Society (2004). All Rights Reserved.=20
   =20
Abstract=20
   =20
   In many scenarios, users need to be able to ensure and prove the=20
   existence and integrity of data, especially digitally signed data, =
in
   a common and reproducible way over a long and possibly undetermined=20
   period of time.  This document specifies the technical requirements=20
   for a long-term archive service to support such scenarios.=20
   =20
Conventions used in this document=20
   =20
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in =
this=20
   document are to be interpreted as described in [RFC2119].=20

Wallace                    Expires July 2004                   [Page 1]
=0C
                Long-term archive service requirements   January 2004=20
 =20
Table of Contents=20
   =20
   1. Introduction...................................................2=20
   2. Terminology....................................................3=20
   3. Application scenarios and general requirements.................4=20
      3.1 Long-term archive problems and tasks.......................4=20
      3.2 Long-term Archive Service..................................5=20
      3.3 Instances and overall architecture.........................7=20
   4. Long-term Archive Service functional and quality requirements..8=20
   5. Long-term Archive Service data structure requirements..........9=20
   6. Long-term Archive Service Protocol requirements...............10=20
   7. Security Considerations.......................................11=20
   8. Acknowledgements..............................................11=20
   9. Normative References..........................................11=20
   10. Authors' Addresses...........................................13=20
   =20
   =20
1.   Introduction=20
=20
   Various scenarios require the ability to preserve digital data and=20
   its value as evidence for long periods of time.  If data is =
important=20
   and will be needed in the future, it is necessary to store it in a=20
   highly secure and persistent way. If the data is needed as evidence=20
   in court, it may be necessary to prove that the existed at a certain =

   time in the past and has not been modified since then.  If data is=20
   signed or timestamped it is necessary to prove that it existed =
before=20
   cryptographic algorithms used to generate its signatures became weak =

   or the certificates expired or were revoked. =20
   =20
   A long-term archive service aids in the preservation of data over=20
   long periods of time.  In particular, it periodically performs=20
   activities to preserve the non-repudiation of existence and =
integrity=20
   as well as ensuring the availability of data.=20
   =20
   A variety of technical and operational means are required to achieve =

   this goal and technical issues beyond cryptography, such as storage=20
   media lifetime, disaster planning, changes in processing or software =

   technology, etc., as well as legal issues must be addressed.=20
    =20
   It is anticipated that a timestamp will be obtained for data =
submitted
   to a long-term archive service.  Thus, for all types of data, i.e.=20
   signed and unsigned, will require preservation of evidence value by=20
   the long-term archive service. =20
   =20
   Any digital signature that may need to be verified at points in time =

   well into the future, e.g. past the certificate validity period or=20
   past the cryptoperiod of the signature private key, is a candidate=20
   for preservation using a long-term archive service.  Examples =
include=20
=20
=20

Wallace                    Expires July 2004                   [Page 2]
=0C
                Long-term archive service requirements   January 2004=20

   signed contracts or agreements, wills, property deeds, CRLs and=20
   timestamps over any type of data.  The service will provide means to =

   prove the integrity and time of existence of the data at a given=20
   point in time.  It must be provable that the data is reliable,=20
   because it existed at a point in time in the past when e.g. the=20
   embedded hash and signature algorithms were still strong and the=20
   included certificates were not revoked.=20
   =20
   This document aims to identify the technical requirements for a =
long-
   term archive service.  The=20
   requirements analysis is divided into two parts.=20
   The first part presents several application=20
   scenarios.  The second part addresses more specific requirements for =

   functions of the service, data structures to support preservation of
   data integrity using cryptographic mechanisms and at least protocol=20
   requirements for interacting with a long-term archive service.=20
   =20
   Operational requirements, such as storage media concerns, individual =

   legal requirements and questions dealing with accounting and billing =

   techniques are not addressed by this document. However, the=20
   transaction data and protocols must allow information to be carried=20
   either directly or indirectly to facilitate association of=20
   transactions with some accounting and billing mechanism, e.g.=20
   identifiers for individual clients and/or large customers.=20
=20
=20
2. Terminology=20
   =20
   Arbitrator: Person, who has to be convinced of various aspects of=20
   authenticity (originator, integrity, time of existence) of archived=20
   data objects.=20
    =20
   Archived data object:  Data unit that is archived and has to be=20
   preserved for a long time by the Long-term Archive Service. =20
    =20
   Archive package: Collection of information including archived data=20
   objects and the associated evidence record.=20
    =20
   Evidence:  Information that may be used to resolve a dispute about=20
   various aspects of authenticity of archived data objects. =20
    =20
   Evidence record: Collection of evidence compiled for one or more=20
   given archived data objects over time.  An evidence record may=20
   include timestamps and additional verification data, like=20
   certificates, revocation information, trust anchors, policy details, =

   role information, etc.=20
    =20
   Originator: Role (person or process) who produces, and possibly=20
   signs, a data object that is to be archived.  The Originator does=20
   not necessarily generate or request generation of an evidence record =

   for the data.=20
    =20

=20
 Wallace                    Expires July 2004                   [Page =
3]
=0C
                Long-term archive service requirements   January 2004=20

   Timestamp: A signed confirmation generated by a Time Stamping=20
   Authority (TSA) that a data item existed at a certain time. =20
   [RFC3161] specifies a good structure for timestamps and a protocol=20
   for communicating with a Timestamp Authority (TSA). =20
    =20
   Trusted Archiving:  A process that includes storing of data objects=20
   for long periods of time preserving its integrity, periodic=20
   generation of timestamps and collection of evidence in support of=20
   long-term preservation of data integrity.=20
    =20
   Trusted archive authority (TAA):   A service responsible for=20
   preserving data for long periods of time, including generation and=20
   collection of evidence, storage of archived data objects and=20
   evidence, etc.  A.K.A. Long-term archive service. =20
    =20
   User: Role (person or process), who submit data objects for=20
   archiving, request archive packages and verify the evidence of an=20
   archived data object using the associated evidence record,=20
   optionally including the verification of any signatures within the=20
   archived data object itself. =20
    =20
   =20
3.  Application scenarios and general requirements=20
   =20
   =20
3.1 Long-term archive problems and tasks=20
   =20
   A Long-term Archive Service has to be designed to cover several=20
   problems in the area of long-term archiving of data objects.  The=20
   following sections describe some of these problems.=20
   =20

3.1.1 Availability and integrity of data for long periods of time=20
   =20
   Individuals, companies and organisations are facing the problem of=20
   how to store electronic documents in a safe way for sometimes even=20
   undetermined spans of time.  Examples include digital contracts, tax =

   declarations or electronic birth certificates.  These documents need =

   special care in order to ensure persistent readability, permanent=20
   availability, integrity and proper protection of confidentiality. =20
   While some large organisations may be capable of supporting=20
   appropriate backup, archive and protection mechanisms citizens and=20
   small enterprises lack the technical prerequisites for this task. =20
   Service providers offering external services for such documents are=20
   thus needed.=20
   =20

3.1.2 Demonstration of proof of existence and integrity for court=20
   =20
   Many archived documents are valuable and may be used as evidence in=20
   court at some point in the future, e.g. to prove entitlements to=20

=20
=20
Wallace                    Expires July 2004                   [Page 4]
=0C
                Long-term archive service requirements   January 2004=20

   benefits or damages.  In this case, it might be required to prove=20
   that these documents existed at a certain time in the past and where =

   not modified since that time.  =20
   =20

3.1.3 Preservation of evidence for signed or timestamped data=20
   =20
   Archived data objects may contain digital signatures or time stamps=20
   to be able to prove the origin and the time of existence of these=20
   objects and signatures.  In the course of time the value of evidence =

   of these signatures or timestamps can decrease or can get lost for=20
   many reasons:=20
   =20
      - Revocation information is no longer available due to the=20
   decommissioning of a CA or OCSP responder;=20
   =20
      - Lack of availability of certificates necessary to verify a=20
   digital signature;=20
   =20
      - Expiration or Revocation of a certificate associated with a=20
   digital signature;=20
   =20
      - Cryptanalytic or computational advances make it possible to=20
   forge documents and signatures or to compute secret keys.=20
   =20
   In order to avoid problems in case of disputes in the future it is=20
   necessary to preserve a digitally signed document, as well as=20
   certificates, revocations lists, OCSP responses and time stamps, =
even=20
   if these elements are not included in the signed document itself. =20
   Preservation may be achieved by periodic review of evidence.  Upon=20
   review, updated evidence may be obtained and stored or additional=20
   cryptographic mechanisms may be applied, e.g. a new timestamp=20
   obtained possibly using a stronger algorithm. =20
   =20
   By periodically inspecting and acting upon stored evidence, it is=20
   possible to generate a cryptographically protected history for a =
data
   item that contains no periods of time during which an algorithm was=20
   thought to be weak, an authority thought to be compromised, etc.=20
   =20
   =20
3.2    Long-term Archive Service=20
   =20
   A Long-term Archive Service is to be designed to solve essential=20
   parts of these problems by providing a specialized service:=20
   =20
   - The Long-term Archive Service is to store archived data objects=20
   over a long, optionally undefined, period of time. Recovery methods, =

   redundant storage and disaster management and other measures have to =

   guarantee the availability of the data objects.=20
=20

Wallace                    Expires July 2004                   [Page 5]
=0C
                Long-term archive service requirements   January 2004=20

   - The Long-term Archive Service provides material needed to prove =
the=20
   existence and integrity of data objects for users as well as in=20
   court.  These means especially are time-stamps, periodically=20
   generated during the archiving period of the data objects. =
Additional=20
   verification data, to verify these time-stamps after a long period =
of=20
   time (CRLS, OCSP responses and certificates) need also be provided.  =

   =20
   - The Long-term Archive Service provides means to preserve the value =

   of evidence of the archived data objects that are signed. These =
means=20
   are also time-stamps but with regard to possible special legal=20
   requirements for the use as mechanism for the renewal of signatures. =
=20
   By using these means a signature application can verify that a=20
   document, which contains signatures, existed before algorithms got=20
   weak or certificates got invalid.=20
   =20
   A Long-term Archive Service is to not be designed to solve all=20
   thinkable problems of long-term-verification of digital signatures.  =

   It does not provide data necessary to verify signatures which are=20
   part of the archived data object itself.  This has to be done by=20
   verifiers using PKI-Services like SCVP (Simple Certificate =
Validation=20
   Protocol) or DVCS (Data Validation and Certification Server).  This=20
   is done, in part, so the archive service can operate without=20
   knowledge of numerous signed data formats, document formats, etc.  =
It=20
   also does not provide any means to integrate verification data in=20
   data objects and verify embedded signatures.  This has to be done on =

   the basis of other specifications, like RFC 3029 and with regard to=20
   specifications of document formats.  Of course it is recommended to=20
   use such specifications together with a Long-term Archive Service.=20
   =20
   Several application scenarios providing one or more of these basic=20
   service features are to be supported, including:=20
   =20
   - Archive service assuring long-term Non-Repudiation =20
      =20
      Long-term Archive Service stores data objects like signed or=20
   unsigned documents for identified and authenticated users.  It=20
   generates time stamps for these data objects and obtains necessary=20
   verification data over a given time or until a request of deletion =
by=20
   this authorized user is sent.=20
   =20
   - Pure long-term non-repudiation Service=20
      =20
      Long-term Archive Service only guarantees non-repudiation of=20
   existence of data.  It periodically generates time stamps and =
obtains=20
   additional verification data for a given period of time.  It stores=20
   data objects (e.g. documents, but also relevant parts of documents=20
   containing signatures) locally only for the purpose of non-
   repudiation.  It is not a document-archive for users and therefore=20
   does not provide retrieval of documents and no deletion of data=20
   objects.  Therefore it does not need any access control.=20
=20

Wallace                    Expires July 2004                   [Page 6]
=0C
                Long-term archive service requirements   January 2004=20
   =20
3.3    Instances and overall architecture=20
   =20
   =20
   The basic functions of a Long-term Archive Service are realized by=20
   several instances:=20
   =20
   =20
   +-------------+=20
   |             |=20
   |     User    |=20
   |             |=20
   +-------------+=20
          |=20
     ----------- Long-term Archive Protocol=20
          |=20
   +-------------+=20
   |             |=20
   |    TAA      |=20
   |             |=20
   +-------------+=20
          |=20
     ----------- Time Stamp Protocol=20
          |=20
   +-------------+=20
   |             |=20
   |    TSA      |=20
   |             |=20
   +-------------+=20
=20
   Users transfer the data objects that shall be archived at the =
Trusted=20
   Archive Authority (TAA) using their application of choice.  After=20
   that, the user or application can request archive packages =
containing=20
   the stored data objects and the associated evidence record.  This is =

   done by using the Long-term Archive Service Protocol and the data=20
   format of archive package to be specified.  The TAA stores the=20
   documents, and obtains necessary verification data, especially time=20
   stamps consulting a Time Stamp Authority using a special Protocol,=20
   especially Time Stamp Protocol (RFC 3161).  TAA also uses other=20
   protocols (e.g. SCVP) to get additional verification data necessary=20
   to verify generated time-stamps.=20
   =20
   A TAA may also provide the functions of a TSA, but separation must =
be=20
   possible.  A TAA may store the archived data objects locally or may=20
   use external archive services.=20
  =20
   Long-term Archive Service may allow for relays using Long-term=20
   Archive Protocol. The use of external archive services may be also=20
   possible. But Relaying must be transparent to the client.
=20
=20

Wallace                    Expires July 2004                   [Page 7]
=0C
                Long-term archive service requirements   January 2004=20

   A TAA may be a server within an enterprise network communicating =
with=20
   local archive servers and other applications or an external service=20
   accessible via internet.=20
=20
=20
4.   Long-term Archive Service functional and quality requirements=20
   =20
   A Long-term Archive Service MUST provide following basic functions:=20
   =20
      - Accept data objects or groups of data objects for preservation; =

   =20
      - Store submitted data objects for a given period of time;=20
   =20
      - Generate, store and maintain evidence records (i.e. by=20
   periodically obtaining timestamps) for data objects submitted for=20
   preservation;=20
   =20
      - Collect and store additional verification data necessary to=20
   verify evidence records;=20
   =20
      - Provide archive packages containing archived data, evidence=20
   record or both;=20
   =20
      - Provide service according to a long-term archive policy;=20

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

  =20
      - Be able to provide archive packages even if the storage,=20
   software or processing technology changes during the lifetime of an=20
   archived data object;=20
   =20
      - Be able to provide an acknowledgement that a data object =
existed=20
   at a certain time, as an alternative, if user is not able to=20
   interpret the evidence record;=20
   =20
      - Operate per an archive policy, which at least determines =
quality=20
   of time-stamps and conditions for there renewal and etc;=20
   =20
      - If data objects are not stored by the Long-term-Archive-Service =

   itself, there must exist mechanisms to make these data objects later
   available to the service if necessary in case of renewal of
   time-stamps.

   A long-term archive service must be able to work efficiently even =
for=20
   large amounts of archived data objects.  In order to limit expenses, =

   costs and dependency on high performance, time-stamp services, the=20
   number of necessary time stamps MUST be minimized and a time stamp=20
   should include a large number of signatures and documents;=20
   =20
   =20
=20
=20
Wallace                    Expires July 2004                   [Page 8]
=0C
                Long-term archive service requirements   January 2004=20
   =20
   Necessity to access stored archived data object SHOULD be minimized. =
=20
   It SHOULD only be necessary access to the archived data objects only =

   if the archived data objects are requested by users or if applied=20
   hash algorithms become insecure. =20
   =20
   A Long-term Archive Service may implement additional features, such=20
   as validation of data objects, if they are signed documents.=20

5.   Long-term Archive Service data structure requirements=20
   =20
   Standardization of data structures and processing procedures for an=20
   archive package will simplify the job of TAAs and enable =
verification=20
   by any user.=20
   =20
   The data structure for archive package should include the archived=20
   data objects and the evidence record.  Archived data objects may be=20
   included as part of the archive package so that it is possible to=20
   request only the evidence record.=20
   =20
   The data structure for the evidence record itself should have the=20
   following properties:=20
   =20
      - It MUST be possible to include all timestamps necessary to=20
   verify the existence of the archived data objects.=20
   =20
      - The timestamp data structure SHOULD be defined in such a way=20
   that it is possible to provide evidence for many archived data=20
   objects in an efficient way.=20
 =20
      - It SHOULD be possible to provide evidence for groups of =
archived=20
   data objects.  For example, it should be possible to archive a=20
   document file and a signature file together such that they get the=20
   same evidence record.=20
   =20
      - Where groups of data objects are submitted, non-repudiation=20
   proof MUST still be available for each archived data object=20
   separately.=20
   =20
      - The deletion of archived data objects MUST NOT put the=20
   provability of other archived data at risk.=20
   =20
      - It SHOULD be possible to create timestamps without the need to=20
   access the archived data objects.  The access to the archived data=20
   SHOULD only be necessary if the security suitability of employed =
hash=20
   algorithm is menaced.=20
   =20
      - All hash algorithms applied to archived data over time SHOULD =
be=20
   identified in a single location to facilitate single pass=20
   verification.=20
   =20
      - It SHOULD be possible to package all evidence along with the=20
   archived data objects in a single data item or to package evidence=20
=20
Wallace                    Expires July 2004                   [Page 9]
=0C
                Long-term archive service requirements   January 2004=20

   and archived data objects in separate items.=20
   =20
      - It SHOULD be possible to provide evidence for encrypted =
archived=20
   data objects.  It SHOULD be possible to integrate information for =
the=20
   reconstruction of the archived data objects of the unencrypted data=20
   objects (key, algorithm, etc.).=20
   =20
      - It SHOULD be possible to integrate additional information for=20
   the verification of timestamps within the evidence record or the=20
   archived data object itself such as certificates and revocation=20
   information, the security suitability of applied algorithms and =
trust=20
   anchors. =20
   =20
=20
6.   Long-term Archive Service Protocol requirements=20
=20
   Standardization of a protocol for interactions with a Long-term=20
   Archive Service is desirable.  The protocol should have the =
following=20
   properties:=20
   =20
      - The protocol MUST define interactions with a Long-term Archive=20
   Service including, at a minimum: submission of data or groups of=20
   data for preservation, retrieval of archive packages and deletion=20
   of archived data and associated evidence records.
  =20
      - The protocol MUST provide a response indicating successful=20
   submission or deletion of data.  The acknowledgement of successful=20
   submission SHOULD permit a submitter to verify that the correct data =

   was received by the service for preservation, e.g. the=20
   acknowledgement could include an index, a signature or a timestamp=20
   obtained for the archived data object.=20
   =20
      - The protocol MUST response an index to retrieve the archive=20
   package.  It also should be possible to retrieve archive packages by =

   using hash values of the archived data objects.=20

      - The protocol SHOULD support some basic Metadata (Mime-Type, key =

   words,etc.), i.e. the client should be able to provide metadata=20
   along with the archived data to facilitate future search operations=20
   based on the metadata.=20
   =20
      - If a Long-term Archive Service does not support a client-
   requested long-term archive policy, the service MUST return an =
error.=20
   =20
      - A Long-term Archive Service MUST provide an indication of the=20
   long-term archive policy under which the service operates.=20
   =20
      - The protocol MUST prevent replay attacks.
   =20
      - The protocol SHOULD permit encryption of data before submission =

   in such a way that there exists non-repudiation evidence for the=20
   unencrypted data.=20
   =20

Wallace                    Expires July 2004                  [Page 10]
=0C
                Long-term archive service requirements   January 2004=20

      - The protocol SHOULD provide means of associating submitted data =

   objects with previously submitted data objects, i.e. to facilitate=20
   retrieval based on aggregation of objects over time.=20

      - The protocol SHOULD provide means for specifying a point in =
time=20
   at which an archived data object need no longer be preserved.  It=20
   also should be possible to extend the archiving period.=20
   =20
      - The protocol SHOULD provide the submission of evidence records=20
   previously generated by a different TAA.=20

      - The format for the acknowledgements MUST allow the=20
   identification of the archiving provider.=20

      - The format for the acknowledgements MUST allow (at least from
   the creating archiving provider) the identification of the=20
   participating client.

      - Responses must uniquely reference corresponding requests

      - It should be possible to sign requests and responses. It is=20
   recommended that in particular acknowledgements are signed.

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

      - The protocol SHOULD be as simple to use as possible.=20
   =20
   Means to enable accountability, access control, confidentiality of=20
   communication between applications and TAA need additional=20
   precautions (like SSL) that are outside the scope of these=20
   requirements.=20

7.   Security Considerations=20
   =20
   Where non-standard formats are used or proprietary processing is=20
   employed, verification of signatures on or in archived data may=20
   require the availability of specific applications or tools.=20
   =20
   Certificate revocation could retroactively invalidate previously=20
   verified signatures.  Measures may be implemented to support such=20
   claims by an alleged signer, e.g. collection of revocation=20
   information after a grace period during which compromise can be=20
   reported or preservation of subsequent revocation information.  =20
   =20
   Access control mechanisms associated with data stored by a TAA =
should=20
   consider the lifespan of the data object.  For example, the=20
   credentials of an entity that submitted data to an archive may not =
be=20
   available or valid when the data needs to be retrieved.=20

Wallace                    Expires July 2004                  [Page 11]
=0C
                Long-term archive service requirements   January 2004=20

   To achieve accountability, local means should be employed to ensure
   that all data is inserted in chronological order, e.g. by using
   write-once media.  Similarly, methods should be deployed to ensure
   that all deletions are detectable.
   =20
   =20
8.   Acknowledgements=20
   =20
   Thanks to Peter Sylvester for sharing information from the=20
   OpenEvidence project.=20
   =20
   =20
9.   Normative References=20
   =20
   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision=20
              3", BCP 9, RFC 2026, October 1996.=20
   =20
   [RFC2028]  Bradner, S. and R. Hovey, "The Organizations Involved in=20
              the IETF Standards Process", BCP 11, RFC 2028, October=20
              1996.=20
   =20
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate=20
              Requirement Levels", BCP 14, RFC 2119, March 1997.=20
   =20
   [RFC3029]  Adams, C., Sylvester, P., Zolotarev, M. and R.=20
              Zuccherato, "Internet X.509 Public Key Infrastructure=20
              Data Validation and Certification Server Protocols", RFC=20
              3029, August 2001.=20
   =20
   [RFC3161]  Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,=20
              "Internet X.509 Public Key Infrastructure Time-Stamp=20
              Protocol (TSP)", RFC 3161, August 2001.=20
   =20
   =20

Wallace                    Expires July 2004                  [Page 12] =

=0C
                Long-term archive service requirements   January 2004=20

10.    Authors' Addresses=20
   =20
   Carl Wallace=20
   Orion Security Solutions=20
   Suite 300=20
   1489 Chain Bridge Road=20
   McLean, VA 22101=20
   E-Mail : [email-masked]=20
   =20
   Ralf Brandner=20
   Otto-Hahn-Str. 3 =20
   D-69190 Walldorf, Germany=20
   E-Mail: [email-masked]=20

   Ulrich Pordesch=20
   Fraunhofer Gesellschaft=20
   Institute Secure Telecooperation=20
   Dolivostrasse 15=20
   D-64293 Darmstadt, Germany=20
   E-Mail: [email-masked]=20

Wallace                    Expires July 2004                  [Page 13]

------_=_NextPart_000_01C3D933.398CBCB0--

From: Zuka <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: MR.MUDIWA ZUKA 
Date: Sat, 03 Jan 2004 08:02:30 +0100

This is a multi-part message in MIME format
--5009bf94-5f1f-4a2f-b67a-faef2ea52bf7
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

DEAR SIR.
HAPPY NEW YEAR .I AM A GIRL OF 25  YEARS OLD AND I AM LOOKING FOR INVESTMENT =
OPPORTUNITY.
I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS  =
INHERITED BY MY LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE =
NETHERLANDS (EUROPE) AT THE MOMENT FOR MORE INFORMATION REACH ME  THROUGH =
THIS  EMAIL    [email-masked] 
 
BEST REGARDS
MS. MUDIWA ZUKA 
   
--5009bf94-5f1f-4a2f-b67a-faef2ea52bf7--