[xmlsec] Encryption and namespace

Daniel Veillard veillard at redhat.com
Tue Mar 23 02:59:29 PST 2004

On Tue, Mar 23, 2004 at 11:20:15AM +0100, Matthias Jung wrote:
> Aleksey Sanin wrote:
> >It seems to me that this is only a warning. The code in
> >gnome-xml/parser.c file prints out the error message
> >    "Namespace prefix %s for %s on %s is not defined\n"
> >and continues. It should still create the XML tree.
> Yes it does, but libxml returns XML_NS_ERR_UNDEFINED_NAMESPACE as error 
> code. The function xmlSecParseMemoryExt does just like 0 as valid 
> xmlParseChunk result.
> Changing the three error check expressions (buffer, postfix, finishing) 
> after calling xmlParseChunk to:
> if(ret != 0 && ret != XML_NS_ERR_UNDEFINED_NAMESPACE) {
> XMLDecryption works fine. :-)
> I am afraid this is not a capable way to solve the parsing problem.
> May be the undefined namespace needs to linked some more to the DOM 
> document? What do the experts say?

  XML parsing is only defined at a document level. There is no standard
about parsing a subdocument, or parsing in a subtree context.
  Libxml2 before 2.6 was more permissive about documents breaking the namespace
spec. What still surprises me is that XML Sec and XML DSig rely to this
spec for C14N but also require to not rely on this, there is something nasty
  Now to get back to technical problems, what should libxml2 do when
it encounters a document like  "<foo:bar/>", this is well formed XML-1.0
so it has to parse it. But foo:bar is not a QName, it's just a Name, so
the element should be in no namespace and with a Name of "foo:bar".
This is significantly different from proposal 1/ made by aleksey of
"parsing in Namespace context" where the result at a tree level would be
that the element is in a namespace.
  It seems to me that the solution from a DSig point of view is an extension
of the XML parsing rules, that should be looked at from a standard perspective
(Aleksey, could you carry this on the W3C/IETF Working Group ?), and from
a libxml2 API this would require to build a specially crafted XML parser
context and call xmlParseContent() handling production [43] of the 
XML spec:
  [43] content ::= (element | CharData | Reference | CDSect | PI | Comment)*
and do some minimal checking of the result to avoid accepting things like

  Comments ?


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

More information about the xmlsec mailing list