You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to https://www.w3.org/TR/xmldsig-core2/#sec-Overview, the ID and URL attributes are defined as optional (with a ?). I believe it should have a option/parameter to indicate whether theses attributes may be generated or not.
However, I see no option for generating and verifying a signature without theses attributes.
Is there any related issue or a fix for this requirement?
UPDATE:
Just figured out that setting isEmptyUri to true on addReference causes the ID not to render on the output, but it stills does not verify the signature.
Any fix for verifying a signed Xml, having no ID attribute on the reference node?
@psavelis , we welcome community contributions for improvements in documentation, fixes for incorrect behavior, and changes enabling additional behavior. Please consider contributing a PR with a test suite to at least recreate the weakness that you're encountering and we might be able to help you code a solution.
isEmptyUri: true on addReference signs with <Reference URI=""> and adds no Id to the signed element.
The failure to verify such signatures was most likely fixed by #581, released in 6.2.0. When enveloped-signature was the only transform, the signer hashed xmldom's serialization while the verifier canonicalized, so any document whose serialization wasn't already canonical, such as one with a self-closing tag or attributes out of C14N order, failed. With 6.3.2, signing with isEmptyUri: true and then verifying passes, both with enveloped-signature alone and followed by a C14N transform.
If it still fails for you on 6.3.2 or later, please comment here with a reproduction and we'll reopen.
Activity
cjbarth commentedon May 29, 2023
@psavelis , we welcome community contributions for improvements in documentation, fixes for incorrect behavior, and changes enabling additional behavior. Please consider contributing a PR with a test suite to at least recreate the weakness that you're encountering and we might be able to help you code a solution.
sibelius commentedon Jan 3, 2025
is there a workaround for this ?
cjbarth commentedon Sep 24, 2026
isEmptyUri: trueonaddReferencesigns with<Reference URI="">and adds noIdto the signed element.The failure to verify such signatures was most likely fixed by #581, released in 6.2.0. When
enveloped-signaturewas the only transform, the signer hashed xmldom's serialization while the verifier canonicalized, so any document whose serialization wasn't already canonical, such as one with a self-closing tag or attributes out of C14N order, failed. With 6.3.2, signing withisEmptyUri: trueand then verifying passes, both withenveloped-signaturealone and followed by a C14N transform.If it still fails for you on 6.3.2 or later, please comment here with a reproduction and we'll reopen.