Re: [ltans] Canonicalization

Markus Isler <isler@keyon.ch> Thu, 26 April 2012 13:31 UTC

Return-Path: <isler@keyon.ch>
X-Original-To: ltans@ietfa.amsl.com
Delivered-To: ltans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF6E21F8598 for <ltans@ietfa.amsl.com>; Thu, 26 Apr 2012 06:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFxKHqwIluNU for <ltans@ietfa.amsl.com>; Thu, 26 Apr 2012 06:31:03 -0700 (PDT)
Received: from keyon.ch (keyon.ch [91.193.21.20]) by ietfa.amsl.com (Postfix) with SMTP id 04A2F21F85A4 for <ltans@ietf.org>; Thu, 26 Apr 2012 06:31:02 -0700 (PDT)
Received: (qmail 11385 invoked from network); 26 Apr 2012 13:31:20 -0000
Received: from keyon.ch (91.193.21.20) by keyon.ch with QMTP; 26 Apr 2012 13:31:20 -0000
Received: (qmail 27395 invoked from network); 26 Apr 2012 13:30:51 -0000
Received: from mail.keyon.local (10.20.0.25) by gateway.keyon.local with SMTP; 26 Apr 2012 13:30:51 -0000
Received: from MAIL.keyon.local ([fe80::7d9f:46c8:e003:9d25]) by mail.keyon.local ([fe80::7d9f:46c8:e003:9d25%11]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 15:30:48 +0200
From: Markus Isler <isler@keyon.ch>
To: "ltans@ietf.org" <ltans@ietf.org>
Thread-Topic: [ltans] Canonicalization
Thread-Index: Ac0ivfP69AnWd5RsRQCooLTigEkPgAAxPZ+AAAlvUXA=
Date: Thu, 26 Apr 2012 13:30:46 +0000
Message-ID: <59E0E1DB40095E47AC604C81EE613F0C189D1DB3@mail.keyon.local>
References: <59E0E1DB40095E47AC604C81EE613F0C189D1803@mail.keyon.local> <4F991D31.7040207@gondrom.org>
In-Reply-To: <4F991D31.7040207@gondrom.org>
Accept-Language: de-CH, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.0.21]
Content-Type: multipart/alternative; boundary="_000_59E0E1DB40095E47AC604C81EE613F0C189D1DB3mailkeyonlocal_"
MIME-Version: 1.0
Subject: Re: [ltans] Canonicalization
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: LTANS Working Group <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltans>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 13:31:10 -0000

Hi Tobias

Yes  3.2. item 2. Sorry for the confusion and thanks for clarification.

I understand that it makes sense to canonicalize XML data if you integrate XMLERS into to XML structure you archived. This is similar to XMLDSIG. However XMLDSIG allows XML input only where XMLERS allows any input format like RFC 4998. Processing XMLDSIG input data is very clear. If it cannot be XML parsed it is invalid. Processing RFC 4998 input data is also clear as the input is a binary blob and I don't care about its format.  XMLERS is tricky because if I strictly follow the RFC 6283 a "canonicalization method MUST be used also for archive data when data is represented in XML format". As you mentioned before I can technically treat every input as binary blob unaware of the format of the data. In this case XML data is not canonicalized. I am pretty sure that this leads to compatibility problems. I wonder how others that implement XMLERS deal with that.

Best regards
Markus


From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of Tobias Gondrom
Sent: Donnerstag, 26. April 2012 12:02
To: ltans@ietf.org
Subject: Re: [ltans] Canonicalization

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

ltans@ietf.org<mailto:ltans@ietf.org>

https://www.ietf.org/mailman/listinfo/ltans