[xmlsec] namepace and cannoalization methods

Wed, 23 Jul 2003 08:41:15 -0700

This is a multi-part message in MIME format.
--------------080800020602000107010604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> 1) Is there a difference between the cannonalization algorithm
> http://www.w3.org/TR/2001/REC-xml-c14n-20010315 and
> http://www.w3.org/2001/10/xml-exc-c14n# (which I seem to
> get from XMLSec when specifying c14 without comments)?
> Why the "#" any not an exact number?
>
There are two difference C14N algorithms: XML Canonicalization [1]
(with identifier http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
and Exclusive XML Canonicalization [2] (with identifier
http://www.w3.org/2001/10/xml-exc-c14n#). In the xmlsec, the
first one has transform IDs "xmlSecTransformInclC14NId" and
"xmlSecTransformInclC14NWithCommentsId" [3]. The second
one (exclusive c14n) has transform ids "xmlSecTransformExclC14NId"
and "xmlSecTransformExclC14NWithCommentsId" [4].

Since xmlsec does not add the transform by itself, I guess
that you have specified the wrong canonicalization in signature
template.

> 2) There is still now way of specifying a namespace prefix in XMLSec?
>
Why? These are absolutely equvivalient nodes:
    "<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" />"
and
    "<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" />"

But the second one is 6 characters longer. Any XML processor
should accept both and produce same internal DOM tree (I meant
that DOM tree would have same nodes, the content of the nodes
would be slightly different, of course).
Nothing is impossible and one can hack xmlsec to use a user defined
prefix but personaly I have no idea why is it needed. If you would
like to prepare such a patch look for xmlSecDSigNs and xmlSecEncNs.
But I would guess it'll be a very ugly and long patch.

IMO, if someone has problems with processing a valid XML then
it's better to fix the code that has the problem.

With best regards,
Aleksey

[1] http://www.w3.org/TR/2001/REC-xml-c14n-20010315
[2] http://www.w3.org/TR/xml-exc-c14n
[3] 
http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMINCLC14NID
[4] 
http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMEXCLC14NID

--------------080800020602000107010604
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
 <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
 
<blockquote type="cite"
 cite="mid000001c35101$6ef6efc0$3b01a8c0@PCHaarek">
 <div class="Section1">
 1) Is there a difference
between the cannonalization algorithm 
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a>
and 
<a class="moz-txt-link-freetext" href="http://www.w3.org/2001/10/xml-exc-c14n#">http://www.w3.org/2001/10/xml-exc-c14n#</a> (which I seem to 
get from XMLSec when specifying c14
without comments)? 
Why the &#8220;#&#8221;
any not an exact number?
 </div>
</blockquote>
There are two difference C14N algorithms: XML Canonicalization [1] 
(with identifier <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a>) 
and Exclusive XML Canonicalization [2] (with identifier 
<a class="moz-txt-link-freetext" href="http://www.w3.org/2001/10/xml-exc-c14n#">http://www.w3.org/2001/10/xml-exc-c14n#</a>).
In the xmlsec, the 
first one has transform IDs "xmlSecTransformInclC14NId" and 
"xmlSecTransformInclC14NWithCommentsId" [3]. The second 
one (exclusive c14n) has transform ids "xmlSecTransformExclC14NId" 
and "xmlSecTransformExclC14NWithCommentsId" [4]. 
 
Since xmlsec does not add the transform by itself, I guess 
that you have specified the wrong canonicalization in signature 
template. 
 
<blockquote type="cite"
 cite="mid000001c35101$6ef6efc0$3b01a8c0@PCHaarek">
 <div class="Section1">
 <o:p></o:p>
 2) There is still now way
of
specifying a namespace prefix in XMLSec?
 </div>
</blockquote>
Why? These are absolutely equvivalient nodes: 
&nbsp;&nbsp;&nbsp; "&lt;Signature xmlns=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#">"http://www.w3.org/2000/09/xmldsig#"</a> /&gt;" 
and 
&nbsp;&nbsp;&nbsp; "&lt;ds:Signature xmlns:ds=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2000/09/xmldsig#">"http://www.w3.org/2000/09/xmldsig#"</a>
/&gt;" 
 
But the second one is 6 characters longer. Any XML processor 
should accept both and produce same internal DOM tree (I meant 
that DOM tree would have same nodes, the content of the nodes 
would be slightly different, of course). 
Nothing is impossible and one can hack xmlsec to use a user defined 
prefix but personaly I have no idea why is it needed. If you would 
like to prepare such a patch look for xmlSecDSigNs and xmlSecEncNs. 
But I would guess it'll be a very ugly and long patch. 
 
IMO, if someone has problems with processing a valid XML then 
it's better to fix the code that has the problem. 
 
 
With best regards, 
Aleksey 
 
<blockquote type="cite"
 cite="mid000001c35101$6ef6efc0$3b01a8c0@PCHaarek">
 <div class="Section1">
 <o:p></o:p>
 <o:p></o:p>
 </div>
</blockquote>
[1] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">http://www.w3.org/TR/2001/REC-xml-c14n-20010315</a> 
[2] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/xml-exc-c14n">http://www.w3.org/TR/xml-exc-c14n</a> 
[3]
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMINCLC14NID">http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMINCLC14NID</a> 
[4]
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMEXCLC14NID">http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMEXCLC14NID</a> 
 
 
 
</body>
</html>

--------------080800020602000107010604--