> Granted that it's insane (and I appreciate your opinion about this) is it
> *documented* insanity, or is it defined by implementation? From my limited
> reading, it seems to be a very grey area. The c14n documentation doesn't
> mention the DOM at all, but there may be some documentation on the DO
Scott Cantor wrote:
>
>> Aside from the embarrassment though, it remains the case that the
>> serializer does not need the assistance of setAttributeNS; it does this
>> job itself.
>
> There's no such thing as "the serializer". There are hundreds of things
> called "serializers". DOM3 includes
> Aside from the embarrassment though, it remains the case that the
> serializer does not need the assistance of setAttributeNS; it does this
> job itself.
There's no such thing as "the serializer". There are hundreds of things called
"serializers". DOM3 includes an LS interface that includes "a
Peter B. West schrieb:
Werner,
It helped a great deal. I'm embarrassed at my misreading of the API.
I forgot about the xmlns *namespace* itself, possibly because
createElementNS has no need for its explicit expression.
Aside from the embarrassment though, it remains the case that the
seriali
Werner Dittmann wrote:
> Peter B. West schrieb:
>
>>> you're using namespaces.
>>>
>>
>> setAttributeNS doesn't work for me following createElementNS. I get
>> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
>> change an object in a way which is incorrect with regard to na
Peter B. West schrieb:
you're using namespaces.
setAttributeNS doesn't work for me following createElementNS. I get
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object in a way which is incorrect with regard to namespaces.
This makes sense, but means tha
Scott Cantor wrote:
>> I am uncertain about the underlying assumptions here. Please correct me
>> where I am wrong in what follows.
>
> I have to warn you, I'm not a c14n expert, and I know approximately zero
> about XPath. What I'm knowledgable about are the practical aspects of using
> a DOM and
Raul Benito schrieb:
I was talkinb about the use of them alone and then need to be c14n by
itself. Anyway I see the point, and I think is one of the sane ones to be
use outside of the signature. But please in order to not repeat it can you
send me the junit test case. It will be make the change f
I was talkinb about the use of them alone and then need to be c14n by
itself. Anyway I see the point, and I think is one of the sane ones to be
use outside of the signature. But please in order to not repeat it can you
send me the junit test case. It will be make the change faster, and it also
will
Raul Benito schrieb:
Hello,
I think I made the change so I will try to defend it, first of all the use
of KeyInfo out of a Signature it is not a use case I was looking to.
Raul,
KeyInfo as such (as an XML element) is not used inside Signature only. If you
have a look into the OASIS WSS specif
Hello,
I think I made the change so I will try to defend it, first of all the use
of KeyInfo out of a Signature it is not a use case I was looking to. So
perhaps we break it as we don't look at it. And sadly the old api is full of
internal objects that can be use external. And I see KeyInfo like th
Scott Cantor schrieb:
Well, the bug is holistic. What I mean, and this is what I meant in my
original comment, is that the bug is a consequence of the inconsistent XML
handling across the range of libraries. It could be viewed as a bug in lots
of places.
In this specific case, I think it's prob
> thanks for your hints :-) . Of course - the xmlns:ds attribute is the
> important part. After checking the attributes of KeyInfo it turned out
> that no xmlns:ds attribute was found.
I figured.
> This functions differs between 1.4.1 and 1.4.2 in some important lines
when
> it comes to add the x
Scott,
>
> Sorry, that's not the point. Is there a namespace *declaration* there? The
> fact that the DOM knows that it has that namespace is irrelevant to the c14n
> process, as far as I'm aware. If the DOM doesn't have the xmlns:ds
> attribute, you will not get it back out.
>
thanks for your h
> the findElement(...) function finds a node, then the code prints its local
> name and the namespace URI:
>
> Before c14n
> KeyInfo, http://www.w3.org/2000/09/xmldsig#
>
> After running c14n the xmlns: namespace binding is gone.
Sorry, that's not the point. Is there a namespace *declaration* th
After a small update of the test like this:
Canonicalizer c14n =
Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
System.out.println("Before c14n");
Node n = WSSecurityUtil.findElement(doc.getDocumentElement(), "KeyInfo",
"http://
> I am uncertain about the underlying assumptions here. Please correct me
> where I am wrong in what follows.
I have to warn you, I'm not a c14n expert, and I know approximately zero
about XPath. What I'm knowledgable about are the practical aspects of using
a DOM and signing.
> When I construct
Scott Cantor wrote:
>
>> Because we use it in WSS4J we always rely on the backward compatibility.
>> Changing the WSS4J code just to circumvent a problem would cause a major
>> effort to many applications that actually use WSS4J. Before changing
>> WSS4J we shall check if a fix in xmlsec is more
> Is is still necessary to file a new bug for this, or has Werner's work
> covered this?
I think it's still being investigated. If there's no bug filed yet, I would
suggest doing so, and send Werner the bug number so he can attach the
results of his tests.
-- Scott
Sean,
Is is still necessary to file a new bug for this, or has Werner's work
covered this?
Peter
sean.mullan wrote:
>
> I don't know what the cause of this regression could be.
>
> The best thing to do is for Arnaud or Peter to file a new bug at
> http://issues.apache.org/bugzilla under the
Scott Cantor schrieb:
Thus the printout "before c14n" is the doc tree just before c14n. IMHO the
Transformer does not add/modify during transformation of the doc tree to a
string.
Unless we can prove that, my bet might be that the DOM before that step
doesn't contain the declaration, and the DO
> Thus the printout "before c14n" is the doc tree just before c14n. IMHO the
> Transformer does not add/modify during transformation of the doc tree to a
> string.
Unless we can prove that, my bet might be that the DOM before that step
doesn't contain the declaration, and the DOM after it does. Th
All,
I've checked the input and output of c14n of xmlsec-1.4.2 and it seems
the c14n does not emit the ds: name space binding of the KeyInfo node.
Attached is the text file of the test run.
The same test but using xmlsec-1.4.1 shows the name space binding before
and after c14n.
The following th
> Questions here: does the XML doc that goes into C14N misses any
> xmlns: declarations at some important positions? If so - where should
> we include these?
With either incl or excl, the ds namespace prefix should be emitted in both
spots, since it's visibly used in that element, and not used any
After doing some more tests I came to the following results (no
solution yet). The processing for the test case is as follows:
Create a XML DOM with encrypted data, relevant elements etc using
xmlsec library. This works without any error messages
In the test case a printout of the produced XML d
Scott Cantor schrieb:
Because we use it in WSS4J we always rely on the backward compatibility.
Changing the WSS4J code just to circumvent a problem would cause a major
effort to many applications that actually use WSS4J. Before changing
WSS4J we shall check if a fix in xmlsec is more appropriate.
> Because we use it in WSS4J we always rely on the backward compatibility.
> Changing the WSS4J code just to circumvent a problem would cause a major
> effort to many applications that actually use WSS4J. Before changing
> WSS4J we shall check if a fix in xmlsec is more appropriate.
If the issue i
I don't know what the cause of this regression could be.
The best thing to do is for Arnaud or Peter to file a new bug at
http://issues.apache.org/bugzilla under the Security project and if possible,
attach a standalone (i.e. not dependent on WSS4J) test case that reproduces the
problem.
Tha
All,
why did it work with 1.4.0 and 1.4.1 then? Were these two version
buggy in that case? Or what was changed in 1.4.2 to get this
incompatible behaviour?
Because we use it in WSS4J we always rely on the backward compatibility.
Changing the WSS4J code just to circumvent a problem would cause a
Peter B. West pbw.id.au> writes:
>
> Arnaud,
>
> I'm using 1.4.2, and the problem I had may not be the same as yours, but
> see my messages "Unbound prefix after decryption".
>
> In my case, the problem was that the DOM being passed for encryption id
> not have the xmlns attribute set before i
Arnaud,
I'm using 1.4.2, and the problem I had may not be the same as yours, but
see my messages "Unbound prefix after decryption".
In my case, the problem was that the DOM being passed for encryption id
not have the xmlns attribute set before it was processed. A
normalizeDocument() in the right
31 matches
Mail list logo
