0

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.

  1. Using the .NET SignedXml class I create <dsig:Signature> element
  2. I manipulate the DOM to remove <dsig:Signature> and recreate the element as <myns:ensembleSignature>.

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?

yzorg
  • 4,224
  • 3
  • 39
  • 57

1 Answers1

0

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.

  1. load XML into XmlDocument
  2. find <customSignature xmlns="http://b-to-b.com/Namespace">
  3. create new element <Signature>
  4. move all children of <customSignature> to
    • Be careful not to disturb whitespace or namespace context of <SignedInfo>.
  5. replace <customSignature> with <Signature>
  6. verify signature using .NET SignedXml class
yzorg
  • 4,224
  • 3
  • 39
  • 57