Re: [ltans] Canonicalization

Tobias Gondrom <> Thu, 26 April 2012 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F09921F86AB for <>; Thu, 26 Apr 2012 03:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.777
X-Spam-Status: No, score=-96.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A3dkUAOvSgmL for <>; Thu, 26 Apr 2012 03:03:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 294B721F8674 for <>; Thu, 26 Apr 2012 03:03:23 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=amy8pTCX28FAiWEbI6skXyKTLp05huKQAYh3j6j/eN4xVHZBNA3qRnF8XIRz8JvleVsTt9acJ5Ua0OJADEMFXUdjwz2/2xYyIe6A9Q08lCv5dXF+lG9heyqBiyrKIa30; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type;
Received: (qmail 7264 invoked from network); 26 Apr 2012 12:02:30 +0200
Received: from (HELO ? ( by with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Apr 2012 12:02:29 +0200
Message-ID: <>
Date: Thu, 26 Apr 2012 18:02:25 +0800
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
References: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local>
In-Reply-To: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local>
Content-Type: multipart/alternative; boundary="------------090406080003000507090905"
Subject: Re: [ltans] Canonicalization
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LTANS Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2012 10:03:25 -0000

Hi Markus,

actually section 3.2.2 is referring to the Reduction of Hash Tree. From 
you question I assume you meant to refer to section 3.2 item 2.

Please be advised, that if you store archive objects in XML data without 
canonicalization, you have a significant risk that the order of elements 
may be rearranged by parsers when read/edited and the bit representation 
of the data may change and will therefor no longer correspond to 
previously calculated hash values.
Therefore it is important to make sure XML data is canonicalized before 
it enters the system. Mainly consider scenarios where a client may want 
to intergrate the XMLERS into the same XML data structure and later 
obviously must remove it from the structure before it can be verified.
(on a side note: btw. pure XML data format alone is in general 
suboptimal for long-term non-repudiation of documents, as it may also 
require stylesheets to achieve reproducible representation of the data.)

So if you put XML data into the system and want to use some of the 
special properties of XML (i.e. allowing to integrate the XMLERS 
afterwards into the XML document itself and removing it prior to 
verification) you MUST canonicalize it to make sure your bit 
representation will always remain consistent after these operations.

However, from a technical perspective you can equally treat it as a data 
blob (agnostic to the format). So you can treat it as bits and bytes 
unaware of any file format.

Best regards, Tobias

On 25/04/12 16:41, Markus Isler wrote:
> Hi
> I have a question regarding Canonicalization of XML elements. 
> According to 3.2.2 archive data has to be canonicalized before hashing it.
> Supposed we are archiving files of arbitrary format. Does this mean 
> that we have check each file whether it is a valid XML file? I hope 
> this is not the case.
> Regards
> Markus
> _______________________________________________
> ltans mailing list