Subject: Re: Our objections to draft ERS

From: Brian Hunter <[email-masked]>
Date: Thu, 01 Apr 2004 11:17:18 +0200

Libor,

Thanks for your comments on the draft.  Please find my comments below.

[email-masked] wrote:
 >>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!

This is related to your next question. In your example, the whole CMS 
object, as in RFC 3126, should be given to the TAA for archiving.

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

As Aleksej and Santosh said, the document and signature, along with 
certificates, crls, etc, should be archived, in order to provide 
non-repudiation of the document and signature in the future.

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

One reason why no id is included, is that we do not want a connection 
between the evidence record and the actual provider, since it is not 
necessary for validating the record.  As Aleksej said, this is a 
management issue, which can be handled by a doc id in the protocol or by 
meta data, to aid searching, as he earlier proposed.

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

You are correct, that is what is meant.  I will make the text more 
explicit in this regards.

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

If this name leads to confusion for developers, then we should discuss 
this.  We initially used the term Enhanced Time-Stamp. Let's first wait 
for some new name suggestions, and we can then decide whether to leave 
the name or change it.

All the suggestions below will be integrated.

Brian

> - 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: <[email-masked]>
Date: Fri, 2 Apr 2004 11:04:39 +0200

Brian,

> In your example, the whole CMS object, as in RFC 3126, should be
> given to the TAA for archiving.

I have one quite elementary question to verify if I understand well. See
the following example:

Today 2nd April 2004, I digitally sign the digital contract and I do not
have the TAA at my disposal at present. My certificate for the digital
signature verification will expire 30th April 2004. When signing acc. to
RFC-3126, I will add the non-signed attribute Electronic Signature
Timestamp, containing the time stamp acc. to RFC-3161 with the TSA
certificate (expire date 31st Dec. 2008), to the CMS message, containg
the digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my
agreement (CMS message) into this TAA. This will create the ERS with the
first ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp
is issued with the issue date of the following root hast-tree - let's
say 6th May 2007.

In 2020, I will submit this contract to the court as a proof. I am
obliged to prove the non-repudiation. This means, I will obtain the ERS
from the TAA, which can prove, that the whole CMS message has not been
changed from the first issuing of the  ArchiveTimeStamp in 6th May 2007
up to present.

Now, the CMS message will be verified the same way it would have been
done in 6th May 2007. It means, I will verify that the time stamp in the
non-signed attribute had a valid TSA digital signature in 6th May 2007.
The time stamp was issued in 2nd April 2004. I will verify if my
personal signature certificate was valid in 2nd April 2004..... Result:
digital contract is valid.

 2.4.2004               6.5.2007                               2020
-+----------------------+--------------------------------------+--
 <------------CMS validity------------->
                        <-----------------ERS validity----------->>>

Libor

---

From: Larry Masinter <[email-masked]>
Date: Thu, 08 Apr 2004 11:10:49 -0700

Every time I've tried to explain this, I had to draw a set of diagrams on
the board, and invent some notation. I'm not happy with the notation, but I
think there must be some better way of explaining the chain-of-evidence.
 
Today 2nd April 2004, I digitally sign the digital contract and I do not
have the TAA at my disposal at present. My certificate for the digital
signature verification will expire 30th April 2004. When signing acc. to
RFC-3126, I will add the non-signed attribute Electronic Signature
Timestamp, containing the time stamp acc. to RFC-3161 with the TSA
certificate (expire date 31st Dec. 2008), to the CMS message, containg the
digitally signed contract.

In 2007, I will start the TAA. In 1st May 2007, I will archive my agreement
(CMS message) into this TAA. This will create the ERS with the first
ArchiveTimeStamp, issued after 1st May 2007. This ArchiveTimeStamp is issued
with the issue date of the following root hast-tree - let's say 6th May
2007.

In 2020, I will submit this contract to the court as a proof. I am obliged
to prove the non-repudiation. This means, I will obtain the ERS from the
TAA, which can prove, that the whole CMS message has not been changed from
the first issuing of the  ArchiveTimeStamp in 6th May 2007 up to present.

Now, the CMS message will be verified the same way it would have been done
in 6th May 2007. It means, I will verify that the time stamp in the
non-signed attribute had a valid TSA digital signature in 6th May 2007. 

I don't understand how, in 2020, you will verify that the TSA digital
signature was valid in May 2007. Won't you need more information than will
be trustably available after 13 years?