F5 Product Development/Engineering Services came back with following 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
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.
Basically, they doubted I was using C14N 1.1.
I can't find the authority in this field to get the verdict on this dispute, so I have to dive deeply into C14N, hopefully in the end I can convince F5 guys in theory where and why they were wrong.
After spending a whole week on trying to understand C14N in XML signature validation, I can confirm F5 PD/EC opinion was wrong.
Basically, the CanonicalizationMethod (in my case which is "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 (the exclusive one) onto the first step (Reference Validation), which is wrong.
You can check my research details at this link.
1 comment:
did you ever hear back from F5 about your last findings?
Post a Comment