RE: LTANS: Examples of ERS data - cross checking of implementations

["Tobias Gondrom" <tgondrom@xxxxxxxxxxxx>]

And again sorry for the late answer.

At first: Adrian is completely right: just for simplicity IXOS
homogenized the tree to binary, ternary, or whatever is configured.
(in the server it can usually be configured special attributes of the
tree (size, number of objects, number of levels, magnitude, ...) 
(note: although we found no significant reason for more than binary
trees at the higher levels)

Second: as Thomas pointed out, it can not be distinguished whether the
hash values in the first sequence form a semantically important group or
are just by coincident members of a data object group (e.g. because the
system by default collects a certain number (e.g. here 3) of objects to
groups.

Actually I see here no problem. Semantic must be handled by the
client/application any way: It will be up to the verification client to
decide whether it wants to verify a single or multiple single objects or
a complete data group.

Tobias



-----Original Message-----
From: owner-ietf-ltans@xxxxxxxxxxxx
[mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Thomas Kunz
Sent: Monday, February 13, 2006 1:56 PM
To: Adrian Frei
Cc: Tilo Kienitz; ietf-ltans@xxxxxxx
Subject: Re: LTANS: Examples of ERS data - cross checking of
implementations


Adrian Frei wrote:
> Thomas Kunz wrote:
> 
>>Tilo Kienitz wrote:
>>
>>>Hello,
>>>
>>>Frei Adrian (frr) wrote:
>>>
>>>
>>>>Hmm, I think you misunderstood the generation of the reduced hash
tree
>>>>(I-D 3.2). The five lists in IXOS' hash tree are not five data
object
>>>>groups; they are five levels of the hash tree. The tree looks like 
>>>
>>> > this:
>>>
>>>
>>>>                    ROOT
>>>>                      |                                      \   \
>>>>                    YYYY                                   f79a 0000
>>>>                      |                            \   \    /|\
>>>>                    YYYY                          c414 3413 
>>>>                      |                    \   \   /|\ /|\
>>>>                    YYYY                 cf18 6ba0
>>>>       /              |             \     /|\ /|\
>>>>     YYYY (c4a8)    b837           46d8
>>>>  /    |   \     /    |   \     /    |   \
>>>>51b1 5bd0 60bb XXXX XXXX XXXX XXXX XXXX XXXX
>>>>data obj grp 1 data obj grp 2 data obj grp 3
>>>
>>>
>>>Thank you for the explanation. If it is really meant to encode this
>>>tree in the way the Ixos-example dit it, then how would it be
possible
>>>to encode the tree if I wanted to include the complete "data obj grp
2"
>>>too? In the simple case that I only want to proove that a certain,
>>>single data object exists in the tree, only a single data object
group
>>>has to be included in the reduced hash tree and the Ixos-encoding
works
>>>fine. But let "data obj grp 1" contain the hash over the signature of
>>>a document and "data obj grp 2" the hash over the OCSP response for
the
>>>certificate of the person who signed the document. Then I would like
>>>to have both hashes in the same reduced hash tree. Of course I could
>>>create two independent evidence records where each contains the
reduced
>>>hash tree for one of the hashes. But it would be good to have every-
>>>thing relating to one document (sig hash and OCSP response hash) in
the
>>>same evidence record.
>>>
>>
>>You have always different evidence records for every data object group

>>in the hash tree. If you would like to have the hash over the
signature 
>>and the hash over the ocsp response in the same reduced hash tree, you

>>should build a data object group containing these two hashes. In the 
>>example above, "data obj grp 1" consists of three (data object)
hashes, 
>>but a data object group can be of arbitrary size, independent of
having 
>>a binary tree, a ternary tree or whatever tree.
> 
> 
> Ok, sorry, actually the three leafs in the IXOS tree are all single
> object groups with only a single object, which means the text in my
> diagram is wrong. However, it could have been otherwise.
> 
The text in your diagram is not necessarily wrong. As I pointed out in 
another thread in this mailing list, if you have a ternary tree and the 
first list of hash values in the reduced hashtree contains three hashes,

you can't unambiguously detemine if you have a object group containing 
only one data object hash (and the other two hashes a simply siblings) 
or a data object group containing three data object hashes (the same 
e.g. in the case of a binary tree and two hash values in the first
list).
Of course, since IXOS provided only one document together with the 
evidence record, we can assume that the group consists only of one 
document hash.

Regards,
Thomas