Subject: ERS RFC 4998 question

From: Peter Sylvester <[email-masked]>
Date: Mon, 08 Dec 2008 17:08:30 +0100

Hi,

In a recent discussion I was asked to explain how the timestamp
in an ERS ArchiveTimeStamp is created. 

The text does not seem to be clear, point 5 on page 11:

5 Obtain a timestamp for this root hash value. 

Does it mean that the hash value will be presented directly
or a hash of that value.

If it is presented directly, what has to be done for the root
when the algorithm supported by a TSA and the digestAlgorithm
indicated in the ArchiveTimeStamp are not the same?

TIA for any info
/P

-- 

<http://www.edelweb.fr>
*Edel/W/eb* 	Peter SYLVESTER
Consultant Sécurité des Systèmes d'Information
-----------------------------------------------------------
EdelWeb - Groupe ON-X
15, quai de Dion-Bouton
F-92816 Puteaux Cedex
Tel : +33.1.40.99.14.14 / Fax : +33.1.40.99.99.58
www.edelweb.fr <http://www.edelweb.fr> / www.on-x.com <http://www.on-x.com>
-----------------------------------------------------------
To verify the message signature, see edelpki.edelweb.fr 
<http://edelpki.edelweb.fr/>
Cela vous permet de charger le certificat de l'autorité de racine 
<http://edelpki.edelweb.fr/cacerts/EdelPKI-ca.der>;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Thomas Kunz <[email-masked]>
Date: Tue, 09 Dec 2008 10:44:30 +0100

The root hash value is presented directly to the TSA.
I would say, before building the hash tree, you have to ensure that the 
hash algorithm you use is supported by the TSA. Otherwise, if the hash 
algorithm is not supported, you will have to re-compute the complete 
hash tree.

- Thomas

---

From: Tilo Kienitz <[email-masked]>
Date: Tue, 09 Dec 2008 11:37:45 +0100

> indicated in the ArchiveTimeStamp are not the same?

We had the same problem and implemented the following:

The hash tree uses SHA-256.

a) If the TSA supports SHA-256, then the root hash value is
    presented directly to the TSA.
b) If the TSA only supports SHA-1, then an SHA-1 hash over the
    root hash is computed and sent to the TSA.

As Thomas Kunz writes, b is not exactly what the RFC wants. However,
we had no other choice, because we need qualified time stamps
according to the german signature law. Such timestamps were not
available with SHA-256 until about a year ago. So we had to use
SHA-1 timestamps for a while.

Kind regards
Tilo

---

From: TSG <[email-masked]>
Date: Tue, 09 Dec 2008 08:33:45 -0800

Thomas Kunz wrote:
> I would say, before building the hash tree, you have to ensure that 
> the hash algorithm you use is supported by the TSA. Otherwise, if the 
> hash algorithm is not supported, you will have to re-compute the 
> complete hash tree.
Or you have to have a way of specifying any number of Hash Values which 
could be supported by the TSA in its operations.

Todd
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.9.11/1818 - Release Date: 11/28/2008 7:31 PM
>
>

---

From: Julien Stern <[email-masked]>
Date: Tue, 9 Dec 2008 19:21:27 +0100

Hi list,

allow me to jump in.

I think that section 4.3 makes in reasonnably clear that
it is indeed the hash which is directly presented.

"Check timestamp. In case of a timestamp according to [RFC3161], the
root hash value must correspond to hashedMessage, and digestAlgorithm
must correspond to hashAlgorithm field, both in messageImprint field of
timeStampToken."

and that this is consistent with paragraph 3.2:

"Using this approach, it is possible to "convert"
existing timestamps into ArchiveTimestamps for renewal."

However, I must say that section 4.2 is not perfectly clear:

"Obtain a timestamp for this root hash value. The hash algorithm in
the timestamp request MUST be the same as the hash algorithm of the
hash tree, or the digestAlgorithm field of the ArchiveTimeStamp MUST be
present and specify the hash algorithm of the hash tree."

The first sentence could mean both interpretations (directly present
the hash or hash it).

The second sentence is really unclear: I fail to see a place where
the RFC defines the way the handle an ERS if the hash digestAlgorithm
is different than the digest used by the timestamp.

My current interpretation is the following:

1) If one uses RFC 3161 then, the hash algorithm used in the hash tree
MUST be the same as the one used in the timestamp (and the root is
directly presented). In that case, the digestAlgorithm MUST either be
absent or equals to the timestamp hash.

2) If other kind of timestamps are used, guidance is not as clear and
it could happen that the hash values are different (altough I would not
exactly know how to interpret it).

Does this make sense to you ?

--
Julien