Xml-crypto doesnt properly handle dtd

[bawolff]

Xml-crypto uses xmldom to parse xml. Xmldom does not support dtd, however dtds can affect the meaning of the document.

For example:

<foo>&amp;:bar;</foo>

And

<!DOCTYPE foo [<!ENTITY :bar "admin">]>
<foo>&:bar;</foo>

Have different meanings and different canonical forms. xml-crypto should give these documents different hashes and different digital signatures. However it thinks they are the same.

This is not a huge deal in practise as most downstream users also use xmldom. However it could be a big deal if a downstream user was parsing documents with something more compliant with the xml spec like happydom

Suggested fix: just error if the doc has a dtd, its an obscure feature nobody uses. If that is too restrictive (some people add them as document identifiers) error on dtds containing an internal subset.

[markstos]

I chatted with the GPT-OSS model, and it agreed with the feedback here, suggesting:

1. Fail-fast if DTD is present with a clear error, like "Error: XML document contains an internal DTD subset, which is not supported by xml‑crypto."
2. Document the limitation – Users who need DTD processing must supply their own pre‑canonicalised data or use a different library.

Since it DTD parsing already wasn't working, we aren't breaking any existing cases, only behavior more strictly and "secure by default" for this case.

[shunkica]

This is invalid xml:

<!DOCTYPE foo [<!ENTITY :bar "admin">]>
<foo>&:bar;</foo>

Per https://www.w3.org/TR/REC-xml-names/#Conformance

It follows that in a namespace-well-formed document:

• No entity names, processing instruction targets, or notation names contain any colons.

[bawolff]

Its not namespace well formed but it would be non-namespace well formed. Namespaces are an optional part of xml.

Regardless most xml implementations seem to accept entity names with colons in them.

In any case, if you are really concerned you could relace the colon with À (as in the pre-composed U+00C0, not the decomposed form) and do the exact same thing.

[shunkica]

C14N is inherently namespace-aware, therefore namespace well-formedness is a prerequisite for proper C14N. As is always the case with XML, your mileage may vary with different implementations...

In any case, just throwing an error if the doc has a DTD would be an over-restriction, because it would also break cases where the DTD does not affect the content which is being signed.

Migrating from xmldom to libxml2-wasm could solve this problem, as libxml2-wasm supports expanding entities and has built-in canonicalization.