Subject: Our objections to draft ERS

From: <[email-masked]>
Date: Wed, 31 Mar 2004 18:29:50 +0200

>From my point of view the complex impression of this draft is very good.
I was really pleased to see that this is already the proposal standard. 

I could not cope with this sentence: "A time-stamp is requested only for
the root hash of the hash-tree" for a long time. But after some time, I
consider it to be a good idea. If I think it over, the publishing of the
root hash-tree in newspapers every week is interesting, but the
"classical" time stamp acc. to  RFC-3161 can easily temporarily replace
it if containing the week hash.

1. Objections

-  I do not understand, how documents with long-term signatures will be
archived (RFC-3126). When archiving long-term signed document to the
TAA, the renew of particular digital signatures acc. to RFC-3126 will be
finished and the whole structure will be stored as data (as Archived
data object)? And after this, it will be renewed as the Archive Time
Stamp Chain? I would like this solution!

-   Or only digital signatures will enter the Archive Time-stamp
calculation as it is in RFC-3126? I would invite some examples, which
will make clear the meaning (for example in appendix). 

-  Evidence record: this structure does not contain the identification
data of the archived document. How could you find such document in the
archive? 

- Archive Time-stamp, 3.1 Syntax: If I understand well: if the
reducedHashtree item misses, there is the time stamp from the document
instead of from the root-hash tree. If it is true, it should be
described here.   

2. Little objections
- "Archive Time-Stamp" collides with the same expression with different
meaning in the RFC-3126. I would recommend to adjust the name slightly.
- chap. 1.2, paragraph 2: Instead of the ETS chain it should be ERS
- chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal the ..."
Change to "In the case of simple Time-Stamp Renewal the ..."
- chap. 1.2, paragraph 6: "Time-Stamp renewal is not sufficient ..."
Change to "The simple Time-Stamp renewal is not sufficient ..."
- chap. 1.4, paragraph 2: "A multitude of data objects.." change to "A
multitude of archived data objects.."
- chap. 4.2 from paragraph:
"   4. Concatenate each h(i) with ha(i) and generate hash values 
      h(i)' = H (h(i)+ ha(i)). For multi-document groups, this is:
        h(i_a)Ć = H (h(i_a)+ ha(i))
        h(i_b)Ć = H (h(i_b)+ ha(i)) etc"

There is the non-ASCII character "Ć", which various readers could view
in a different way. I would recommend to change it for some other ascii
character (e.g. for " ' ").

Libor & Marta

---

From: "A. Jerman Blazic" <[email-masked]>
Date: Wed, 31 Mar 2004 21:27:58 +0200

Libor,

See comments inline

> I could not cope with this sentence: "A time-stamp is 
> requested only for the root hash of the hash-tree" for a long 
> time. But after some time, I consider it to be a good idea. 
> If I think it over, the publishing of the root hash-tree in 
> newspapers every week is interesting, but the "classical" 
> time stamp acc. to  RFC-3161 can easily temporarily replace 
> -  I do not understand, how documents with long-term 
> signatures will be archived (RFC-3126). When archiving 
> long-term signed document to the TAA, the renew of particular 
> digital signatures acc. to RFC-3126 will be finished and the 
> whole structure will be stored as data (as Archived data 
> object)? And after this, it will be renewed as the Archive 
> Time Stamp Chain? I would like this solution!

I do not really understand your point but as far as I know LTANS or TAA
is not suppose to deal with digital signatures. It's meant to conserve
electronic records only, which means mainly integrity and time
reference. Not even validation of signatures is under concern. I
personally do not see such scenario evolving but i think complementary
procedures will take place to handle digital signatures and their
validity over time.
 
> calculation as it is in RFC-3126? I would invite some 
> examples, which will make clear the meaning (for example in 
> appendix). 

Again, TAA is not suppose to deal with signatures. And also, digital
signatures are not timestamping objects alone. Whole document must get
stamped to achieve proper archiving.
 
> -  Evidence record: this structure does not contain the 
> identification data of the archived document. How could you 
> find such document in the archive? 

This is a major problem and is addressed to management of archived
records (and not really LTANS). You might consider OAIS or relevant
standards to do the management. I have proposed to have metadata
standard for archiving attributes, which would include also other
security attributes and their refreshment. Actually the step we took in
the designing phase of archival solutions deal with collecting archival,
security and management attributes. Whether this is standardized and not
is another issue.

Regards

Aleksej
 
> - Archive Time-stamp, 3.1 Syntax: If I understand well: if 
> the reducedHashtree item misses, there is the time stamp from 
> the document instead of from the root-hash tree. If it is 
> true, it should be
> described here.   
> 
> 2. Little objections
> - "Archive Time-Stamp" collides with the same expression with 
> different meaning in the RFC-3126. I would recommend to 
> adjust the name slightly.
> - chap. 1.2, paragraph 5: "In the case of Time-Stamp Renewal 
> the ..." Change to "In the case of simple Time-Stamp Renewal the ..."
> - chap. 1.2, paragraph 6: "Time-Stamp renewal is not 
> sufficient ..." Change to "The simple Time-Stamp renewal is 
> not sufficient ..."
> - chap. 1.4, paragraph 2: "A multitude of data objects.." 
> change to "A multitude of archived data objects.."
> There is the non-ASCII character "Ć", which various readers 
> could view in a different way. I would recommend to change it 
> for some other ascii character (e.g. for " ' ").
> 
> 
> Libor & Marta
>  
> 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 31 Mar 2004 14:52:31 -0500

Aleksej:

For the most part, I agree with you.  Two points:

1.  While TAA does not care about digital signatures, if the submitted
archive document is signed and/or time stamped and all applicable
certificates, roots, and revocation information are included, the TAA data
can be retrieved and used as long term non-repudiation evidence.

2.  The TAA will have to provide some hints when a document is submitted in
order to ease the burden of retrieval (i.e., finding a needle in a
haystack).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of A. Jerman Blazic
Sent: Wednesday, March 31, 2004 2:28 PM
To: [email-masked]
Subject: RE: Our objections to draft ERS

Libor,

See comments inline

> Time Stamp Chain? I would like this solution!

I do not really understand your point but as far as I know LTANS or TAA is
not suppose to deal with digital signatures. It's meant to conserve
electronic records only, which means mainly integrity and time reference.
Not even validation of signatures is under concern. I personally do not see
such scenario evolving but i think complementary procedures will take place
to handle digital signatures and their validity over time.

 
> find such document in the archive? 

This is a major problem and is addressed to management of archived records
(and not really LTANS). You might consider OAIS or relevant standards to do
the management. I have proposed to have metadata standard for archiving
attributes, which would include also other security attributes and their
refreshment. Actually the step we took in the designing phase of archival
solutions deal with collecting archival, security and management attributes.
Whether this is standardized and not is another issue.

Regards

Aleksej
 
> for some other ascii character (e.g. for " ' ").

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Our objections to draft ERS
Date: Wed, 31 Mar 2004 14:52:31 -0500
Importance: Normal
Sender: [email-masked]

Aleksej:

For the most part, I agree with you.  Two points:

1.  While TAA does not care about digital signatures, if the submitted
archive document is signed and/or time stamped and all applicable
certificates, roots, and revocation information are included, the TAA data
can be retrieved and used as long term non-repudiation evidence.

2.  The TAA will have to provide some hints when a document is submitted in
order to ease the burden of retrieval (i.e., finding a needle in a
haystack).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of A. Jerman Blazic
Sent: Wednesday, March 31, 2004 2:28 PM
To: [email-masked]
Subject: RE: Our objections to draft ERS

Libor,

See comments inline

> Time Stamp Chain? I would like this solution!

I do not really understand your point but as far as I know LTANS or TAA is
not suppose to deal with digital signatures. It's meant to conserve
electronic records only, which means mainly integrity and time reference.
Not even validation of signatures is under concern. I personally do not see
such scenario evolving but i think complementary procedures will take place
to handle digital signatures and their validity over time.

 
> find such document in the archive? 

This is a major problem and is addressed to management of archived records
(and not really LTANS). You might consider OAIS or relevant standards to do
the management. I have proposed to have metadata standard for archiving
attributes, which would include also other security attributes and their
refreshment. Actually the step we took in the designing phase of archival
solutions deal with collecting archival, security and management attributes.
Whether this is standardized and not is another issue.

Regards

Aleksej
 
> for some other ascii character (e.g. for " ' ").

From: "A. Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Subject: RE: Our objections to draft ERS
Date: Wed, 31 Mar 2004 21:27:58 +0200
Importance: Normal
Sender: [email-masked]

Libor,

See comments inline

 

Regards

Aleksej
 
> for some other ascii character (e.g. for " ' ").

From: <[email-masked]>
To: <[email-masked]>
Subject: Our objections to draft ERS
Date: Wed, 31 Mar 2004 18:29:50 +0200
Importance: Normal
Sender: [email-masked]

1. Objections

2. Little objections

Libor & Marta

Date: Wed, 31 Mar 2004 13:40:58 +0200
From: Brian Hunter <[email-masked]>
To: Larry Masinter <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Alternatives for Long Term Archiving
Sender: [email-masked]

Larry or Santosh,

Could someone tell me how the n of m scheme replaces the need of an 
(accredited) time-stamping or time-marking service, when the date of 
document existance must be proved?  Is it assumed that each TAA simply 
states (and signs) when the document existed and when n TAAs state the 
same date, this date is correct and trustworthy?

Regards,
Brian

Date: Mon, 29 Mar 2004 12:18:25 -0800
From: Larry Masinter <[email-masked]>
Subject: RE: Alternatives for Long Term Archiving
To: [email-masked]
Sender: [email-masked]

I think my main point is that the standard for
the network protocol for accessing and interacting
with a long term archive and notary (distributed)
service should not be tied to the mechanism that
the service uses for insuring long term archives
and non-repudiation.

The current requirements document seems to be too
tightly tied to the architecture of the underlying
repository and the nature of the mechanisms by
which it supplies services.

Personally, I think that we should look for
"long term archives" solutions that do not
rely on algorithmic complexity and one-way
functions as the mechanism for insuring privacy,
integrity, etc.

Larry

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Alternatives for Long Term Archiving
Date: Mon, 29 Mar 2004 09:08:26 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

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

Larry:
=20
I have reviewed this paper.  Here are some of my observations:
=20

.         The paper is oriented towards confidentiality

.         Paper deals with multiple archive servers and what do do if =
some
are decommissioned or corrupted and  others need to be commissioned.  We
currently do not address the need for multiple servers and we do not =
handle
decommissioning and commissioning.  While the work done to date in LTANS
does not address this as a requirement or solution, I think having n of =
m
and then redistributing shares to create n' of m' should be part of our
standard.

.         The paper deals with integrity of share broadcast that Micali,
Feldman etc have provided.  This should not be of concern to us since we =
can
use TLS for secrecy and integrity of current data.  My concern largely =
here
is that of patent

.         Speaking of patents, I hope the redistribution scheme by =
Jajodia
or this work are not under patent.

=20
I also did not see any outstanding issues with us going forward with =
many of
the features of n of m.  I would suggest that we move out with this =
work.

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Larry Masinter
Sent: Wednesday, March 24, 2004 5:21 PM
To: 'Santosh Chokhani'
Cc: [email-masked]
Subject: RE: Alternatives for Long Term Archiving

There seems to be quite a bit of research in this area. For example, see
http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are =
still
open issues about how to manage trust over the long term, and even =
identity.

=20
Larry
=20

------=_NextPart_000_000C_01C4156D.65174960
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>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D743232213-29032004>Larry:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D743232213-29032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D743232213-29032004>I have=20
reviewed this paper.&nbsp; Here are some of my =
observations:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN =
class=3D743232213-29032004><?xml:namespace prefix =3D=20
o ns =3D "urn:schemas-microsoft-com:office:office" /><o:p><FONT =
face=3DArial=20
color=3D#000000 size=3D2>&nbsp;</FONT></o:p></DIV>
<DIV>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3DArial><FONT size=3D2><FONT color=3D#000000><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D743232213-29032004><FONT face=3DArial size=3D2>The=20
p</FONT></SPAN></SPAN></SPAN></SPAN>aper&nbsp;<SPAN =
class=3D743232213-29032004>is=20
</SPAN>oriented towards confidentiality</FONT></FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3DArial><FONT size=3D2><FONT color=3D#000000><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN>Paper deals with&nbsp;<SPAN=20
class=3D743232213-29032004>multiple archive </SPAN>servers&nbsp;<SPAN=20
class=3D743232213-29032004>and what do do if some are</SPAN> =
decommissioned or=20
corrupted&nbsp;<SPAN class=3D743232213-29032004>and&nbsp; others need to =
be=20
commissioned.&nbsp; We currently do not address the need for multiple =
servers=20
and we do not handle decommissioning and commissioning.&nbsp; While the =
work=20
done to date in LTANS does not address this as a requirement or =
solution, I=20
think having n of m</SPAN><SPAN class=3D743232213-29032004> and then=20
redistributing shares to create n' of m' should be part of our=20
standard.</SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
color=3D#000000><FONT face=3DArial><FONT size=3D2><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore">&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D743232213-29032004><FONT face=3DArial size=3D2>The paper=20
d</FONT></SPAN></SPAN></SPAN></SPAN>eals with integrity of share =
broadcast that=20
Micali, Feldman etc have provided.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN><SPAN =
class=3D743232213-29032004>This=20
should </SPAN>not&nbsp;<SPAN class=3D743232213-29032004>be </SPAN>of =
concern to us=20
since we can use TLS for&nbsp;secrecy and integrity&nbsp;<SPAN=20
class=3D743232213-29032004>of current data.&nbsp; My concern largely =
here is that=20
of patent</SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3DArial><FONT size=3D2><SPAN=20
class=3D743232213-29032004></SPAN></FONT></FONT><FONT face=3DArial><FONT =

size=3D2><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000>&middot;<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D743232213-29032004><FONT face=3DArial size=3D2>Speaking of =
patents, I hope the=20
redistribution scheme by Jajodia or this work are not under=20
patent.</FONT></SPAN></SPAN></FONT></SPAN></SPAN></FONT></FONT></P></DIV>=

<DIV class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3DArial><FONT size=3D2><FONT color=3D#000000><FONT =
face=3DArial><FONT size=3D2><SPAN=20
style=3D"FONT-FAMILY: Symbol; mso-fareast-font-family: Symbol; =
mso-bidi-font-family: Symbol"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3DArial color=3D#000000 =
size=3D2><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'"><SPAN=20
class=3D743232213-29032004></SPAN></SPAN></FONT></SPAN></SPAN></FONT></FO=
NT></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D743232213-29032004><FONT face=3DArial color=3D#000000 =
size=3D2>I also=20
did not see any outstanding issues with us going forward with many of =
the=20
features of n of m.&nbsp; I would suggest that we move out with this=20
work.</FONT></SPAN></SPAN></FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma><FONT size=3D2><FONT face=3DArial>-----Original=20
  Message-----<BR></FONT><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Larry=20
  Masinter<BR><B>Sent:</B> Wednesday, March 24, 2004 5:21 =
PM<BR><B>To:</B>=20
  'Santosh Chokhani'<BR><B>Cc:</B> [email-masked]<BR><B>Subject:</B> =
RE:=20
  Alternatives for Long Term Archiving<BR><BR></FONT></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D979542619-24032004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>There seems to be quite a bit of research in =
this area.=20
  For example, see&nbsp;&nbsp;<A=20
  =
href=3D"http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf">http://www.pdl=
.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf</A>.=20
  I think there are still open issues about how to manage trust over the =
long=20
  term, and even identity. </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D979542619-24032004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D979542619-24032004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Larry</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D979542619-24032004><FONT =
face=3DArial=20
  color=3D#0000ff =
size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000C_01C4156D.65174960--

Date: Sat, 27 Mar 2004 13:34:53 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Alternatives for Long Term Archiving
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Sorry for that strange attachment. It doesn't contain anything
important. 

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: Alternatives for Long Term Archiving
Date: Fri, 26 Mar 2004 08:54:00 -0500
Importance: Normal
Sender: [email-masked]

Brian:

See responses in-line in [].

-----Original Message-----
From: Brian Hunter [mailto:[email-masked]] 
Sent: Friday, March 26, 2004 4:37 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: Alternatives for Long Term Archiving

I think that a keyless approach could be an ideal approach, however, I 
don't see Shamir's scheme as solving all of our problems.  First, the 
complexity of the system would increase.

[I think the complexity of the client will increase.  But, the TAAs will
become very, very simply.  In my judgment the overall system complexity will
reduce since there is no encryption, signature, timestamp, time refresh
etc., but a simply n of m split only one time]

This starts with the 
distribution of the original document, and then the possible 
redistribution of the document as TAAs are removed or added.  Such 
functionality would add to the complexity of the (server-server) protocols.

[Actually, when TAAs are removed or added, n of m scheme may be better
suited to handle this.  I have not fully grasped Shamir's technique, but it
lets you add new shares if some properties hold.  Removal on the other hand
can be handled in two ways.  n of m gives you some margin for removing some
TAs (may be up to m-n).  Alternatively, since there are no keys involved it
will be easier to move to a newly created TAA.  In the current proposal, the
whole stuff has to be with another TAA]

Furthermore, stricter access control must be ensured, such that an 
attacker can't simply retrieve n parts of the document from the TAAs. 
Using the current encryption scheme, an attacker would first have to 
bypass the access control of the (single) TAA, and then have to break 
the encryption of the document.  Thus, the security focus of the systems 
are different, one is strictly based upon access control, the other on 
access control and encryption.  One could even argue that no access 
control is needed for the evidence records, since they only contain a 
hash of the document and reveal nothing about its content.

[n of m does not prevent you from encrypting the document.  I just wanted to
point out that confidentiality against TAAs and against an eavesdropper can
be easily achieved.  If you think all TAAs' access controls can be bypassed
(not just one TAA's), which I doubt, you can encrypt the document a la
current proposal.

The cost to archive a document would increase, likely linearly based on 
the size of m.  How many clients want to pay m times more for a service? 
(unless the alternatives are shown to be insufficient)  Furthermore, 
each TAA would probably have to be, at least in Germany, accredited, 
since it is attesting for the document insertion time (and integrity). 
Accreditation is not needed by the TAAs in the ERS solution, only 
accredited TSA(s) are needed.

[Cost may be a concern.  But, hopefully even 2 of 2 might suffice.  Also,
since TAAs are simple, cost per archival should offset some of the costs.
This is one of the reasons, I do not want to standardize on current proposal
alone or n of m alone, but see if there is a way to accommodate both and
have most aspects of transactions and storage record common.]

I believe that this distribution approach could be useful, for at least 
particular cases, but am unsure if it is suitable today for a generic 
archive service that needs to be efficient and cost effective for large 
volumes of documents.  Thus, I still think (based on what has been 
presented so far) that ERS should be continued, in order to get a 
needed, standard, viable solution in the near future, and the 
distribution approach could be further investigated, refined and then in 
the future be evaluated whether it is added to the LTANS approach as the 
new recommended method, or as an optional method recommended for 
specific use cases.

[I would like to read the paper Larry pointed to and then make a judgment if
ERS or both ERS and n of m should be considered.  I am not proposing that
ERS be not part of the approach.].

Brian

Date: Fri, 26 Mar 2004 10:36:31 +0100
From: Brian Hunter <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: Alternatives for Long Term Archiving
Sender: [email-masked]

I think that a keyless approach could be an ideal approach, however, I 
don't see Shamir's scheme as solving all of our problems.  First, the 
complexity of the system would increase.  This starts with the 
distribution of the original document, and then the possible 
redistribution of the document as TAAs are removed or added.  Such 
functionality would add to the complexity of the (server-server) protocols.

Furthermore, stricter access control must be ensured, such that an 
attacker can't simply retrieve n parts of the document from the TAAs. 
Using the current encryption scheme, an attacker would first have to 
bypass the access control of the (single) TAA, and then have to break 
the encryption of the document.  Thus, the security focus of the systems 
are different, one is strictly based upon access control, the other on 
access control and encryption.  One could even argue that no access 
control is needed for the evidence records, since they only contain a 
hash of the document and reveal nothing about its content.

The cost to archive a document would increase, likely linearly based on 
the size of m.  How many clients want to pay m times more for a service? 
(unless the alternatives are shown to be insufficient)  Furthermore, 
each TAA would probably have to be, at least in Germany, accredited, 
since it is attesting for the document insertion time (and integrity). 
Accreditation is not needed by the TAAs in the ERS solution, only 
accredited TSA(s) are needed.

I believe that this distribution approach could be useful, for at least 
particular cases, but am unsure if it is suitable today for a generic 
archive service that needs to be efficient and cost effective for large 
volumes of documents.  Thus, I still think (based on what has been 
presented so far) that ERS should be continued, in order to get a 
needed, standard, viable solution in the near future, and the 
distribution approach could be further investigated, refined and then in 
the future be evaluated whether it is added to the LTANS approach as the 
new recommended method, or as an optional method recommended for 
specific use cases.

Brian

Date: Thu, 25 Mar 2004 13:35:13 -0800
From: kent crispin <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Alternatives for Long Term Archiving
Mail-Followup-To: Peter Sylvester <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, Mar 25, 2004 at 10:08:15PM +0100, Peter Sylvester wrote:

Hi Peter -- your mail client is sending strange attachments:

[-- application/x-X-sun-attachment is unsupported (use 'v' to view this part) --]

-- 
Kent Crispin 
[email-masked]    p: +1 310 823 9358  f: +1 310 823 8649
[email-masked] SIP: [email-masked]

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: FW: April 12-14: 3rd Annual PKI R&D Workshop
Date: Thu, 25 Mar 2004 16:10:08 -0500
Importance: Normal
Sender: [email-masked]

FYI.

-------------

The 3rd Annual PKI R&D Workshop is almost here: April 12-14 2004 at NIST in
Gaithersburg, MD.  Registrations should be in by Monday March 29.

The program features a broad variety of perspectives, results and new ideas
on the use of Public Key technology for security decision making, not just
traditional "PKI".  There are talks and panel sessions on the dynamic
delegation of rights, application-specific PKI designs, document signatures,
certificate path discovery, experience papers and panels on where to go from
here.

Speakers include Peter Gutmann, Carlisle Adams, Stefan Brands, Ken
Klingenstein, John Linn, Tim Polk, Von Welch and many other experts. The
intimate workshop atmosphere provides ample opportunities to interact with
others working on the issues you're facing, including Work-In-Progress and
Birds-of-a-Feather sessions.

802.11b Wireless access points will be available for SSH, IPSEC, HTTP, DNS,
FTP, POP, IMAP, and SMTP connectivity.  At only $105 for registration, it's
a bargain.

More information at
 http://middleware.internet2.edu/pki04/ 

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Preliminary Program - Subject to change

Monday, April 12

12:00 - 12:15
Opening Remarks
Program Committee
Susan Zevin Director, Information Technology Laboratory, NIST

12:15 - 1:15
KEYNOTE ADDRESS
Non-Intrusive Cross-Domain Identity Management
Stefan Brands Credentica

2:00 - 3:30
Role Sharing in Password-Enabled PKI
Xunhua Wang James Madison University

Greenpass: Decentralized, PKI-based Authorization for Wireless LANs Nicholas
C. Goffee Dartmouth College

X.509 Proxy Certificates for Dynamic Delegation
Von Welch National Center for Supercomputing Applications, University of
Illinois

4:00 - 5:30
Panel: Controlled and Dynamic Delegation of Rights
Moderator: Frank Siebenlist Argonne National Laboratory

6:15 - 8:00
Social Gathering and Workshop Dinner
Gaithersburg Holiday Inn

8:00 - 9:00
Work in Progress Session
Gaithersburg Holiday Inn
Contact Krishna Sankar if you would like to present some Work in Progress

Tuesday, April 13

9:00 - 10:00
KEYNOTE ADDRESS
Simple, Straightforward, Functional PKI
Peter Gutmann University of Auckland

10:00 - 10:30
Experiences of establishing trust in a distributed system operated by
mutually distrusting parties David Chadwick University of Salford

11:00 - 12:00
Panel: An update on Phase Three of the PKI Interop Project with EDUCAUSE
Moderator: Peter Alterman National Institutes of Health

Deb Blanchard Digital Signature Trust
Russ Weiser Betrusted

12:00 - 12:30
Trusted Archiving
Santosh Chokhani Orion Security Solutions

12:30 - 2:00: Lunch - NIST Cafeteria

2:00 - 3:00
Panel: Document Signatures
Moderator: Randy Sabett, Cooley Godward LLP & Tim Polk NIST

3:00 - 3:30
PKI: Ten Years Later
Carlisle Adams University of Ottawa

4:00 - 4:30
An Examination of Asserted PKI Issues and Proposed Alternatives John Linn
RSA Laboratories

4:30 - 5:30
Panel: Which PKI Approach for Which Application Domain?
Moderator: Peter Alterman National Institutes of Health

Carl Ellison Microsoft
Russ Weiser Betrusted

5:30 - 8:00: Dinner (on your own)

8:00 - 9:00
Birds of a Feather sessions - sign up at Registration

Wednesday, April 14

9:00 - 10:00
KEYNOTE ADDRESS
The Middleware Connection
Ken Klingenstein University of Colorado; Internet2

10:00 - 10:30
Private Revocation Test using Oblivious Membership Evaluation Protocol
Hiroaki Kikuchi Tokai University

11:00 - 11:30
"Dynamic Bridge" Concept Paper
Ken Stillson Mitretek Systems

11:30 - 12:30
Panel: Approaches to Certificate Path Discovery
Moderator: Peter Hesse Gemini Security Solutions

Steve Hanna Sun Microsystems
Matt Cooper Orion Security Solutions
Ken Stillson Mitretek Systems

12:30 - 2:00: Lunch - NIST Cafeteria

2:00 - 2:30
Johnson & Johnson Use of Public Key Technology
Rich Guida Johnson & Johnson

2:30 - 3:00
Identifying and Overcoming Obstacles to PKI Deployment and Usage Jean Pawluk
Inovant

3:30 - 4:30
Panel: The PKI Action Plan: Will it make a difference?
Moderator: Steve Hanna Sun Microsystems

Lieutenant Commander Thomas Winnenberg U.S.N., DISA
Jean Pawluk Inovant
Tim Polk NIST
John Linn RSA Laboratories
Sean Smith Dartmouth College

4:30 - 5:00
Wrapup Session

Date: Thu, 25 Mar 2004 22:08:15 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: Alternatives for Long Term Archiving
Cc: [email-masked]
Sender: [email-masked]

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 13

> One of the ideas that came out of Seoul meeting (thanks to Larry Masinter)
> is to use a key-less approach to trusted archive.  The client who has vested
> interest in the secure storage of archived data, can use Shamir's n of m
> scheme to submit the archived data to m archive facilities.  m must be
> greater than 1 and should be selected based on availability needs. n must be
> greater than 1, less than or equal to m, and should be selected based on the
> desired degree of protection against collusion.
>  

Addressing the problem of confidentiality and redundancy need in this way
had been proposed as one of the work iteme of a research project
APRICOT concerning archiving. It seems useful to me to elaborate how
these aproach can be implemented in practice. 
----------
X-Sun-Data-Type: html
X-Sun-Encoding-Info: quoted-printable
X-Sun-Content-Length: 5575
X-Sun-Content-Lines: 129

<!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>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>One of =
the ideas=20
that came out of Seoul meeting (thanks to Larry Masinter) is to use a =
key-less=20
approach to trusted archive.&nbsp; The client who has vested interest in =
the=20
secure storage of archived data, can use Shamir's n of m scheme to =
submit the=20
archived data to m archive facilities.&nbsp; m must be greater than 1 =
and should=20
be selected based on availability needs. n must be greater than 1, less =
than or=20
equal to m, and should be selected based on the desired degree of =
protection=20
against collusion.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>If =
this scheme is=20
used, we may not need any cryptographic operations at the=20
TAA.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>Under =
this scheme,=20
the LTANS WG would need to still define various protocol for submission, =

deletion, and retrieval.&nbsp; if the idea is acceptable to the group, =
it could=20
be the preferred or one of the approaches to perform=20
archiving.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>As the =
current LTANS=20
documents in the&nbsp;various stages state or imply,=20
the&nbsp;trusted&nbsp;archive can continue to be used to submit any =
class of=20
data.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>One =
advantage of the=20
approach&nbsp;is that&nbsp;any&nbsp;document split is not sensitive even =
if the=20
original document is sensitive.&nbsp; However, if the document requires=20
confidentiality,&nbsp;assuming an adversary could be monitoring the =
channels to=20
collect all the splits, the submission and retrieval of the split should =
be=20
provided transmission security using techniques such as SSL or session=20
encryption.&nbsp; This still is lot easier than needing to provide =
long-term=20
encryption for stored data.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>To =
further=20
illustrate one usage of the approach, a client with the&nbsp;need to =
provide=20
long-term,&nbsp;non-repudiation of a transaction, could obtain current =
time=20
stamp, all the trust anchor, certificates, revocation information =
relevant to=20
signatures and time stamp, and package them using TBD record format and =
create m=20
splits.&nbsp; These m split could be sent to m TAAs using TLS.&nbsp; =
Each TLS=20
could provide a pointer to its split.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>When =
there is a need=20
to retrieve the evidence, n splits could be retrieved from n TAAs that =
are=20
available and can be combined to validate the signatures on the =
transaction as=20
well as the time stamp.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>The =
approach also=20
offers some redundancy in case some TAAs are not available, data is =
corrupted,=20
or the challenger does not trust some of the TAAs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><!-- Converted from =
text/rtf format -->
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Santosh =
Chokhani</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Orion Security =
Solutions,=20
Inc.</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>1489 Chain=20
Bridge Road, Suite 300</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2>McLean, Virginia 22101</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =
size=3D2>917</FONT><FONT=20
face=3DArial size=3D2>-</FONT><FONT face=3DArial =
size=3D2>0060</FONT><FONT face=3DArial=20
size=3D2></FONT>&nbsp;<FONT face=3DArial size=3D2> </FONT><FONT =
face=3DArial=20
color=3D#ff0000 size=3D2>Ext. 35</FONT> <FONT face=3DArial =
size=3D2>(</FONT><FONT=20
face=3DArial size=3D2>voice</FONT><FONT face=3DArial =
size=3D2>)</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =

size=3D2>917</FONT><FONT face=3DArial size=3D2>-</FONT><FONT =
face=3DArial=20
size=3D2>0260</FONT><FONT face=3DArial size=3D2> (Fax)</FONT></SPAN> =
<BR><SPAN=20
lang=3Den-us><FONT face=3DArial =
size=3D2>[email-masked]</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Visit our Web =
site</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2><A=20
href=3D"http://www.orionsec.com/">http://www.orionsec.com</A></FONT></SPA=
N> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

Date: Wed, 24 Mar 2004 14:21:03 -0800
From: Larry Masinter <[email-masked]>
Subject: RE: Alternatives for Long Term Archiving
To: "'Santosh Chokhani'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

There seems to be quite a bit of research in this area. For example, see
http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf. I think there are still
open issues about how to manage trust over the long term, and even identity.

Larry

--Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=979542619-24032004><FONT face=Arial 
color=#0000ff size=2>There seems to be quite a bit of research in this area. For 
example, see&nbsp;&nbsp;<A 
href="http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf">http://www.pdl.cmu.edu/PDL-FTP/PASIS/SISW2002.pdf</A>. 
I think there are still open issues about how to manage trust over the long 
term, and even identity. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=979542619-24032004><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=979542619-24032004><FONT face=Arial 
color=#0000ff size=2>Larry</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=979542619-24032004><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_ocIivjkqrOsth0ezJ5qEQA)--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: Alternatives for Long Term Archiving
Date: Wed, 24 Mar 2004 13:36:54 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C411A5.176FB790
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One of the ideas that came out of Seoul meeting (thanks to Larry =
Masinter)
is to use a key-less approach to trusted archive.  The client who has =
vested
interest in the secure storage of archived data, can use Shamir's n of m
scheme to submit the archived data to m archive facilities.  m must be
greater than 1 and should be selected based on availability needs. n =
must be
greater than 1, less than or equal to m, and should be selected based on =
the
desired degree of protection against collusion.
=20
If this scheme is used, we may not need any cryptographic operations at =
the
TAA.
=20
Under this scheme, the LTANS WG would need to still define various =
protocol
for submission, deletion, and retrieval.  if the idea is acceptable to =
the
group, it could be the preferred or one of the approaches to perform
archiving.
=20
As the current LTANS documents in the various stages state or imply, the
trusted archive can continue to be used to submit any class of data.
=20
One advantage of the approach is that any document split is not =
sensitive
even if the original document is sensitive.  However, if the document
requires confidentiality, assuming an adversary could be monitoring the
channels to collect all the splits, the submission and retrieval of the
split should be provided transmission security using techniques such as =
SSL
or session encryption.  This still is lot easier than needing to provide
long-term encryption for stored data.
=20
To further illustrate one usage of the approach, a client with the need =
to
provide long-term, non-repudiation of a transaction, could obtain =
current
time stamp, all the trust anchor, certificates, revocation information
relevant to signatures and time stamp, and package them using TBD record
format and create m splits.  These m split could be sent to m TAAs using
TLS.  Each TLS could provide a pointer to its split.
=20
When there is a need to retrieve the evidence, n splits could be =
retrieved
from n TAAs that are available and can be combined to validate the
signatures on the transaction as well as the time stamp.
=20
The approach also offers some redundancy in case some TAAs are not
available, data is corrupted, or the challenger does not trust some of =
the
TAAs.
=20

Santosh Chokhani=20
Orion Security Solutions, Inc.=20
1489 Chain Bridge Road, Suite 300=20
McLean, Virginia 22101=20
(703) 917-0060  Ext. 35 (voice)=20
(703) 917-0260 (Fax)=20
[email-masked]=20
Visit our Web site=20
http://www.orionsec.com <http://www.orionsec.com/> =20

=20

------=_NextPart_000_0007_01C411A5.176FB790
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>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>One of =
the ideas=20
that came out of Seoul meeting (thanks to Larry Masinter) is to use a =
key-less=20
approach to trusted archive.&nbsp; The client who has vested interest in =
the=20
secure storage of archived data, can use Shamir's n of m scheme to =
submit the=20
archived data to m archive facilities.&nbsp; m must be greater than 1 =
and should=20
be selected based on availability needs. n must be greater than 1, less =
than or=20
equal to m, and should be selected based on the desired degree of =
protection=20
against collusion.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>If =
this scheme is=20
used, we may not need any cryptographic operations at the=20
TAA.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>Under =
this scheme,=20
the LTANS WG would need to still define various protocol for submission, =

deletion, and retrieval.&nbsp; if the idea is acceptable to the group, =
it could=20
be the preferred or one of the approaches to perform=20
archiving.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>As the =
current LTANS=20
documents in the&nbsp;various stages state or imply,=20
the&nbsp;trusted&nbsp;archive can continue to be used to submit any =
class of=20
data.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>One =
advantage of the=20
approach&nbsp;is that&nbsp;any&nbsp;document split is not sensitive even =
if the=20
original document is sensitive.&nbsp; However, if the document requires=20
confidentiality,&nbsp;assuming an adversary could be monitoring the =
channels to=20
collect all the splits, the submission and retrieval of the split should =
be=20
provided transmission security using techniques such as SSL or session=20
encryption.&nbsp; This still is lot easier than needing to provide =
long-term=20
encryption for stored data.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>To =
further=20
illustrate one usage of the approach, a client with the&nbsp;need to =
provide=20
long-term,&nbsp;non-repudiation of a transaction, could obtain current =
time=20
stamp, all the trust anchor, certificates, revocation information =
relevant to=20
signatures and time stamp, and package them using TBD record format and =
create m=20
splits.&nbsp; These m split could be sent to m TAAs using TLS.&nbsp; =
Each TLS=20
could provide a pointer to its split.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>When =
there is a need=20
to retrieve the evidence, n splits could be retrieved from n TAAs that =
are=20
available and can be combined to validate the signatures on the =
transaction as=20
well as the time stamp.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D471225017-24032004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D471225017-24032004>The =
approach also=20
offers some redundancy in case some TAAs are not available, data is =
corrupted,=20
or the challenger does not trust some of the TAAs.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV><!-- Converted from =
text/rtf format -->
<P><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Santosh =
Chokhani</FONT></SPAN>=20
<BR><SPAN lang=3Den-us><FONT face=3DArial size=3D2>Orion Security =
Solutions,=20
Inc.</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT face=3DArial =
size=3D2>1489 Chain=20
Bridge Road, Suite 300</FONT></SPAN> <BR><SPAN lang=3Den-us><FONT =
face=3DArial=20
size=3D2>McLean, Virginia 22101</FONT></SPAN> <BR><SPAN =
lang=3Den-us><FONT=20
face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =
size=3D2>917</FONT><FONT=20
face=3DArial size=3D2>-</FONT><FONT face=3DArial =
size=3D2>0060</FONT><FONT face=3DArial=20
size=3D2></FONT>&nbsp;<FONT face=3DArial size=3D2> </FONT><FONT =
face=3DArial=20
color=3D#ff0000 size=3D2>Ext. 35</FONT> <FONT face=3DArial =
size=3D2>(</FONT><FONT=20
face=3DArial size=3D2>voice</FONT><FONT face=3DArial =
size=3D2>)</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>(703)</FONT> <FONT face=3DArial =

size=3D2>917</FONT><FONT face=3DArial size=3D2>-</FONT><FONT =
face=3DArial=20
size=3D2>0260</FONT><FONT face=3DArial size=3D2> (Fax)</FONT></SPAN> =
<BR><SPAN=20
lang=3Den-us><FONT face=3DArial =
size=3D2>[email-masked]</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2>Visit our Web =
site</FONT></SPAN> <BR><SPAN=20
lang=3Den-us><FONT face=3DArial size=3D2><A=20
href=3D"http://www.orionsec.com/">http://www.orionsec.com</A></FONT></SPA=
N> </P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0007_01C411A5.176FB790--

From: "Muriel Souville" <[email-masked]>
To: <[email-masked]>
Subject: Launch of the Security Plugtests Registration
Date: Wed, 10 Mar 2004 10:12:09 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_03A3_01C40688.2621BA40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

The ETSI Plugtests(tm) Service is pleased to announce the opening
of the Security Plugtests registration.
The event will take place from 24 till 28 May at the ETSI premises,
in Sophia Antipolis (France).
Deadline to register is 5th May.

 All details about the event are to be found at
http://www.etsi.org/plugtests/security.htm

Feel free to forward this email to as many people as you want in order
to have a really interesting test opportunity this week.

For any enquiry you may have, please write to [email-masked].

Thanks for your attention.
We look forward to welcoming you at our Headquarters in May.

Best regards

Muriel SOUVILLE
ETSI Consultant
Tel: +33 (0) 3 90 23 63 63

------=_NextPart_000_03A3_01C40688.2621BA40
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><FONT face=3D"Times New Roman" =
size=3D3>Dear=20
all,<BR><BR>The ETSI Plugtests(tm) Service is pleased to announce the=20
opening<BR>of the Security Plugtests registration.<BR>The event will =
take place=20
from 24 till 28 May at the ETSI premises,<BR>in Sophia Antipolis=20
(France).<BR>Deadline to register is 5th May.<BR><BR>&nbsp;All details =
about the=20
event are to be found at<BR></FONT><A=20
href=3D"http://www.etsi.org/plugtests/security.htm"><FONT face=3D"Times =
New Roman"=20
size=3D3>http://www.etsi.org/plugtests/security.htm</FONT></A><BR><BR><FO=
NT=20
face=3D"Times New Roman" size=3D3>Feel free to forward this email to as =
many people=20
as you want in order<BR>to have a really interesting test opportunity =
this=20
week.<BR><BR>For any enquiry you may have, please write to </FONT><A=20
href=3D"mailto:[email-masked]"><FONT face=3D"Times New Roman"=20
size=3D3>[email-masked]</FONT></A><FONT face=3D"Times New Roman"=20
size=3D3>.<BR><BR>Thanks for your attention.<BR>We look forward to =
welcoming you=20
at our Headquarters in May.<BR><BR>Best regards<BR><BR>Muriel =
SOUVILLE<BR>ETSI=20
Consultant<BR>Tel: +33 (0) 3 90 23 63=20
63</FONT><BR></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_03A3_01C40688.2621BA40--