You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Mingfa Ma <mi...@deepnetsecurity.com> on 2013/07/09 17:58:40 UTC
RE: XML canonicalization
Hi, Scott,
My dispute on c14n with F5 still goes on.
They thought I was using c14n 1.1 version which was totally wrong, as I
proved it by debugging the checksig utility.
First of all, I saw, it went to this block, as tmpSB =
http://www.w3.org/2001/10/xml-exc-c14n#
else if (tmpSB.sbStrcmp(URI_ID_EXC_C14N_NOC) == 0) {
m_canonicalizationMethod = CANON_C14NE_NOC;
}
Then I noticed the variable m_exclusive = false in
XSECC14n20010315::checkRenderNameSpaceNode(DOMNode *e, DOMNode *a).
My question is, why we call http://www.w3.org/2001/10/xml-exc-c14n#"
as "Exclusive XML Canonicalization Version 1.0" however m_exclusive =
false? Is it special doing c14n inside reference?
Regards,
Mike
For your convenience, here I attached their response.
------------------------------------------------------------------------
-----------------------------
Some research with "Apache Santuario" was done.
We tried the tool which came with install "c14n" "tool to dump a XML
file to the console after canonacalising it through c14n"
We checked different options and found the following:
c14n -n -x assertion.xml => This generates the canonicalized xml
which is exactly same as what F5 generates.
c14n -n -x -1.1 assertion.xml => This generates what is explained in the
BUG which is different from what F5 generated.
In the above command "1.1" refers to "Use c14n 1.1".
>From the source code xml-security-c-1.7.1/xsec/dsig/DSIGConstants.hpp
#define URI_ID_C14N11_NOC "http://www.w3.org/2006/12/xml-c14n11"
#define URI_ID_EXC_C14N_NOC
"http://www.w3.org/2001/10/xml-exc-c14n#"
This tells us that the canonicalization used by Apache Santuario is
'URI_ID_C14N11_NOC' but we see the <ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> inside SAML
response which is not right.
Look at "http://www.w3.org/TR/DSig-usage/"
The solution to this problem is that, do not use "1.1" option with c14n
when SAML response is generated to work with F5.
------------------------------------------------------------------------
----------------------------------------------------
-----Original Message-----
From: Cantor, Scott [mailto:cantor.2@osu.edu]
Sent: 06 June 2013 17:24
To: dev@santuario.apache.org
Subject: RE: XML canonicalization
> It output " Signature verified OK! "
>
> So,
>
> If Apache is right, then F5 is wrong.
> If F5 is right, then Apache is wrong.
There are two Apache libraries. Assuming you generated the signature in
something that's not the C++ library, then Apache has verified it with
two different implementations, and there's a strong chance we're right
and they're wrong.
That's aside from the fact that looking at it, it strongly appears they
are wrong and are confused about how c14n is done inside references.
-- Scott
Re: XML canonicalization
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 7/10/13 11:14 AM, "Mingfa Ma" <mi...@deepnetsecurity.com> wrote:
>
>Actually I tried Java code (not Apache library, but
>javax.xml.crypto.dsig.*, very simple) and passed the core validation on
>my samples, so I never doubt the apache's correct handling on XML
>canonicalization.
Ok, then I'm fairly confident in the conclusions.
>There are two reasons why I dig into checksig utility,
>
>1, I showed F5 my Java code, but they seemed blind on that. Probably
>their product is developed with C(C++), they are more like to see C
>implementation.
What's relevant is you have two independent sources pointing to they've
got the bug, which shifts the burden in such cases.
>After a deeper dive into checksig, I finally got the answer,
>
>The CanonicalizationMethod (in my case,
>"http://www.w3.org/2001/10/xml-exc-c14n#" ) defined in SignedInfo should
>be ONLY used on the second step of core validation - Signature
>Validation.
>However, F5 also employed the same method onto the first step (Reference
>Validation), which I think is wrong.
I think that's what I was trying to explain when you first posted the
issue. It appeared to me they were confused about how Reference validation
works. Sorry if I wasn't clear.
-- Scott
RE: XML canonicalization
Posted by Mingfa Ma <mi...@deepnetsecurity.com>.
Sorry Scott,
Actually I tried Java code (not Apache library, but
javax.xml.crypto.dsig.*, very simple) and passed the core validation on
my samples, so I never doubt the apache's correct handling on XML
canonicalization.
There are two reasons why I dig into checksig utility,
1, I showed F5 my Java code, but they seemed blind on that. Probably
their product is developed with C(C++), they are more like to see C
implementation.
2, I myself want to learn and understand XML canonicalization through
the C implementation so that I can convince F5 guys in theory where and
why they were wrong, as I can't find the authority in this field to get
the verdict on this dispute.
After a deeper dive into checksig, I finally got the answer,
The CanonicalizationMethod (in my case,
"http://www.w3.org/2001/10/xml-exc-c14n#" ) defined in SignedInfo should
be ONLY used on the second step of core validation - Signature
Validation.
However, F5 also employed the same method onto the first step (Reference
Validation), which I think is wrong.
Many thanks,
Mike
-----Original Message-----
From: Cantor, Scott [mailto:cantor.2@osu.edu]
Sent: 09 July 2013 20:12
To: dev@santuario.apache.org
Subject: Re: XML canonicalization
On 7/9/13 11:58 AM, "Mingfa Ma" <mi...@deepnetsecurity.com> wrote:
>
>They thought I was using c14n 1.1 version which was totally wrong, as I
>proved it by debugging the checksig utility.
That doesn't have any real impact on much, 1.0 and 1.1 are very similar,
and there is no exclusive 1.1.
>My question is, why we call http://www.w3.org/2001/10/xml-exc-c14n#"
>as "Exclusive XML Canonicalization Version 1.0" however m_exclusive =
>false? Is it special doing c14n inside reference?
I didn't write the c14n code and have little familiarity with it.
>This tells us that the canonicalization used by Apache Santuario is
>'URI_ID_C14N11_NOC' but we see the <ds:CanonicalizationMethod
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> inside SAML
>response which is not right.
There are many cases in which both algorithms will produce the same
output. The differences manifest when the object being processed isn't
the root of the document.
As I told you originally, you have a simple way to determine whether
there's a bug. If the Java library doesn't accept the signature, there's
a good chance one of the two is wrong. If it does, there's very little
chance both are broken in the same way.
-- Scott
Re: XML canonicalization
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 7/9/13 11:58 AM, "Mingfa Ma" <mi...@deepnetsecurity.com> wrote:
>
>They thought I was using c14n 1.1 version which was totally wrong, as I
>proved it by debugging the checksig utility.
That doesn't have any real impact on much, 1.0 and 1.1 are very similar,
and there is no exclusive 1.1.
>My question is, why we call http://www.w3.org/2001/10/xml-exc-c14n#"
>as "Exclusive XML Canonicalization Version 1.0" however m_exclusive =
>false? Is it special doing c14n inside reference?
I didn't write the c14n code and have little familiarity with it.
>This tells us that the canonicalization used by Apache Santuario is
>'URI_ID_C14N11_NOC' but we see the <ds:CanonicalizationMethod
>Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> inside SAML
>response which is not right.
There are many cases in which both algorithms will produce the same
output. The differences manifest when the object being processed isn't the
root of the document.
As I told you originally, you have a simple way to determine whether
there's a bug. If the Java library doesn't accept the signature, there's a
good chance one of the two is wrong. If it does, there's very little
chance both are broken in the same way.
-- Scott