~Softwaremaker (BLOG) M. Twain: "I didn't have time to write a short letter, so I wrote a long one instead"
Let me guess ...
you are submitting this snipper to apache security suite.
I have seen you post the same code around over the web. The problem is not your code BUT the validator used to read this.
The dsig prefix doesn't indicate whether they 2 use different namespaces. Checkthe namespaces and compare (in the first case check the default namespacexmlns='...").
If the validator cannot read this, then it is really poor design to rely on namespace prefix.
If you look at the specs, Section 1.3 states that:
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
Therefore, it is NOT necessarily to have a prefix to it as long as it points to the same namespace ...
However, AFAIK - If you need to, you will need to do a lot of grunt work and that means building your own signature stack.
Softwaremaker wrote:...However, AFAIK - If you need to, you will need to do a lot of grunt work and that means building your own signature stack...
I have looked closely at that stack - if you really need the dsig prefix and the other end cannot validate it, you would have to output your own signatures. It is not as hard as it sounds. Just a fair bit of grunt work. No rocket science involved.
I would advise you to advise the other party of the spec requirements. Having the prefix is only OPTIONAL and to be honest - prefix/s are not important at all. If the other party needs to have it to validate it, then it is a serious design flaw on their end.
Strictly speaking -
are isomorphically the same.
If the other parser thinks it is different, it is a design flaw at the other end.
If the other end is an Apache AXIS Server, I believe the newer version (WSS4J 1.0) fixes their problem.
Senshodan wrote:Although the validator can validate the signature without the prefix we would like creating our signatures with the prefix inside.You told that adding that prefix " It is not as hard as it sounds. Just a fair bit of grunt work. No rocket science involved."Do you have any clue about that??
1) If the specs say the prefix is OPTIONAL and your validator can validate the prefix-less signatures, why would you want to "create the signatures with the prefix inside" ? What is the compelling reason for that ?
2) The constant you need to override with the prefix is an internal class. Therefore, you need to disassemble the .NET XMLSignature stacks. The [internal] XMLSignature class contains the prefixes you need to change
Senshodan wrote:...- We are planning to extend the signature to XADES format. In that case the dsig prefix is mandatory.
Did u mean the ds prefix ? The specs didnt make any mention of dsig
Its your lucky day. If you agree to my disclaimer here, you may proceed to my blog post here: http://www.softwaremaker.net/blog/XAdESInteropWithXMLDSIGAsImplementedByTheNETFramework.aspx and see my explanations behind all. At the end, you will find a download.
I hope it works !!! I know you have been asking around this for some time in the forums and newsgroups with no answers
I have spoken to a few experts [on the standards body] about this and it seems that the concensus is that the prefix is NOT needed at all.
The XAdES specifications did not EXPLICITLY state that the prefix is needed so I don't see how you draw the conclusion that prefixes are fixed. Maybe I am missing something.
It looked to me like all the spec was saying was that the *examples* used those prefixes.
It strikes me as surprising that any specification worth its salt would specify a *fixed prefix*. It would have been too restrictive and not something that many vendors would agree and abide.
You may want to check with the other party for this.