W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: Why is it extrictly obligatory the use of CanonicalizationMethod?

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 14 May 2001 09:43:52 -0400
Message-Id: <4.3.2.7.2.20010514092345.03381e28@localhost>
To: "gonzalo rodriguez" <gonzrodriu@hotmail.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
At 20:41 5/12/2001 +0000, gonzalo rodriguez wrote:
>First of all, sorry for bothering you (forgive me if my english is not the 
>best) but there is no email to make suggestions about the recommendations, 
>neither in the WG  neither Signature nor Encryption.

http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/
>Please send comments to the editors and cc: the list 
><w3c-ietf-xmldsig@w3.org>.


>I cannot understand why it "MUST" appear the element called 
>"CanonicalizationMethod" every time that an "SignedInfo" element appears.

I'm cc:ing your email to the list as others' recollections are probably more 
accurate than mine.

In general, we erred on the side of relying upon explicit declaration over 
implicit/default meaning and the element was made mandatory. Also, at one 
point we spoke of a "null algorithm" meaning no canonicalization. Over time, 
we lost the "null canonicalization" concept because it doesn't make much 
sense in the XML processing context and we continue to maintain the explicit 
declaration. Subsequently, the implementations have always used 
canonicalization, and it's been Canonical XML that everyone has used -- we 
dropped minimal canonicalization. Consequently, there are two slightly odd 
characteristics of this Method:

1. Should you wish to not use any canonicalization (this isn't really 
meaningful to my mind), the declaration would look like:
   <CanonicalizationMethod Algorithm=""/>
2. CanonicalizationMethod, SignatureMethod, DigestMethod, and Transform all 
were of type "mixed", meaning character data could be included between the 
start and end tag, this would be information relevant to the actual method 
(parameters). Aside of transforms, we haven't seen a great deal of 
employment of this functionality yet.

>As my English is not very good I'm going to argue my reasons by using the 
>signature-example.xml. This example appears as a link at the end of 
>"XML-Signature Syntax and Processing":
>
>1.- Shouldn't it be the DEFAULT WAY to make the things the next?...
>To make concatenation of all the elements that appear and in the order that 
>they appear. e.g(using the data of signature-example.xml):
>
>http://www.w3.org/2000/09/xmldsig#dsahttp://www.w3.org/TR/xml-stylesheet/http://www.w3.org/2000/09/xmldsig#base64http://www.w3.org/2000/09/xmldsig#nullhttp://www.w3.org/2000/09/xmldsig#sha1j6lwx3rvEPO0vKtMup4NbeVu8nk=http://www.w3.org/TR/REC-xml-names/http://www.w3.org/2000/09/xmldsig#base64http://www.w3.org/2000/09/xmldsig#sha1UrXLDLBIta6skoV5/A8Q38GEw44=
>
>and this information should be after encrypted.

I don't understand. Do you mean encrypted, or signed?

>2.- In case this is true, and that most of people wish only use this way of 
>operation (all the times), why should they have to learn how the "Canonical 
>XML" works in order they documents to be valid?
>(Even now i cannot understand how the "Canonicalization Method" is used
>by the documents, at least in the three examples you give. Sorry.)

The *.tar.gz examples in the Implementation Report might help you understand 
how the CanonicalizationMethod is used:
        http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html

>3.- Wouldn't it be better to make the element optional?
>(Even strongly recommended in the "XML-Signature Syntax and Processing")

If in fact someone wants to use null processing, giving that such an 
approach is rather rare (no implementations are supporting this), I think it 
should actually be explicitly designated.

__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Monday, 14 May 2001 09:43:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC