Subject: RE: My objections to the submitted draft

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 1 Feb 2004 09:49:41 -0500

The rate of refresh is not dependent on the original signature, but the
cryptographic strength of the last signature by the TSA.  Thus, as the
technology advances TSA is expected to have stronger keys.

Thus, in your example, there should be few refreshes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Sunday, February 01, 2004 1:35 AM
To: [email-masked]
Subject: RE: My objections to the submitted draft

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

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

[Santosh Chokhani] I think LTANS is trying to solve that problem  

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 12:59:46 -0800

Santosh and all,

  Understood here.  However this only in part addresses the
problems or likely conflict with RFC 3161 as previously indicated..

> 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: "Santosh Chokhani" <[email-masked]>
Date: Sun, 1 Feb 2004 14:11:03 -0500

Jeff:

What is the problem with 3161 that is relevant to LTANS?

-----Original Message-----
From: Jeff Williams [mailto:[email-masked]] 
Sent: Sunday, February 01, 2004 4:00 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: My objections to the submitted draft

Santosh and all,

  Understood here.  However this only in part addresses the problems or
likely conflict with RFC 3161 as previously indicated..

Santosh Chokhani wrote:

> The rate of refresh is not dependent on the original signature, but 
> the cryptographic strength of the last signature by the TSA.  Thus, as 
> the technology advances TSA is expected to have stronger keys.
>
> [Santosh Chokhani] There may be some patent related concerns regarding 
> the linked time stamp (Surety in US).
>
> 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

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: Jeff Williams <[email-masked]>
Date: Sun, 01 Feb 2004 18:05:05 -0800

Santosh and all,

  I guess you have not read all of the comments and remarks on this thread.
See earlier responses.

Regards,

---

From: Brian Hunter <[email-masked]>
Date: Mon, 02 Feb 2004 10:10:40 +0100

Jeff,

I believe the only point that Santosh did not address was Libor's last 
point:

First paragraph quote from reqs doc.
 >    This is done, in part, so the archive service can operate without
 >    knowledge of numerous signed data formats, document formats, etc.
 >    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!

I believe that the goal of LTANS is to archive evidence, possibly along 
with the document, that proves that the document existed at a certain 
time in the past.  This goal was also illustrated by Aleksej in his last 
post.  Although document format and its transition is important, I do 
not believe that is the goal of LTANS.

Brian

---

From: Jeff Williams <[email-masked]>
Date: Mon, 02 Feb 2004 13:39:15 -0800

Brian and all

>  >distortion!) Obviously, the TAA could not accept such document!

  Yes I agree.

> not believe that is the goal of LTANS.

  Understood.  Perhaps its transition should be a goal? If not I would
ask, why not?

Regards,

---

From: Brian Hunter <[email-masked]>
Date: Tue, 03 Feb 2004 15:35:53 +0100

Jeff,

>   Understood.  Perhaps its transition should be a goal? If not I would

You are correct, this is a goal of LTANS, which is covered under the 
milestone notary services requirements.  However, I think for the 
current long-term archive requirements document, and its related 
protocol and data structures, that file format conversion is not an 
issue.  Thus, I think discussions on file transitions will be valuable 
when the notary services requirements are written.

Regards,
Brian