Re: ERS RFC 4998 question

[Julien Stern <julien.stern@xxxxxxxxxxxxx>]

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

On Tue, Dec 09, 2008 at 11:37:45AM +0100, Tilo Kienitz wrote:
>
> Peter Sylvester wrote:
>> 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?
>
> 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
>