I'm trying to implement an industry spec that requires enveloped XML digital signatures (XMLDSIG). Instead of conforming to the examples (<Signature>
) my spec uses its own name for the signature element:
<xs:element name="ensembleSignature" type="dsig:SignatureType" />
<!-- wish this was: <xs:element ref="dsig:Signature" /> -->
So the element isn't named 'Signature' and is in the domain's XML namespace instead of the dsig XML namespace.
With a lot of extra work I can create this custom signature in .NET.
But it seems .NET can't verify the incoming <myns:ensembleSignature>, even if I rename the incoming element back to <dsig:Signature>.
I've been over the XMLDSIG spec many times, and although all their examples use <Signature> it doesn't seem to specifically require this element name, even for enveloped transforms. So is this a bug in SignedXml that it only supports this single element name when there is no such requirement in XMLDSIG spec?
Using a non-standard element name isn't possible in .NET. But the signature element name isn't part of the digest, so you can remove the 'custom' signature element and add a 'standard' signature element name (<Signature>) but be careful not to change any whitespace or namespaces in the SignedInfo element, because SignedInfo IS part of the digest. In the canonicalization method I am using whitespace is significant, and so is the namespace of the elements.