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.