Problem with signing Windows provisioning profiles

[pwiatrowski]

Windows Network Provisioning is not happy with the enveloped signature generated by signxml.

After digging the problem I found that second transform in the transforms node:
Working example:
<Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> </Transforms>

Broken example:
<ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></ds:Transform></ds:Transforms>

Unfortunately at the moment there's no way I could disable second transform other than by editing the code of the signxml.

Is there a chance this could be resolved by adding some sort of switch?

[kislyuk]

Thanks for reporting. Does the working example pass xmldsig schema validation?

[kislyuk]

Also, do you know what type of canonicalization your app (Windows Network Provisioning) expects?

[pwiatrowski]

np :)

Yes - the working example pass the verification (tried here: https://www.signatur.rtr.at/en/elsi/Pruefung.html) and Windows (8.1 and 10) accepts it as well.

This is not my app - it's just a part of Windows services allowing (for example) to provision a machine with a WLAN profile. The profile (xml) has to be sign by a valid EV cert.

As far as I know it's using http://www.w3.org/TR/2001/REC-xml-c14n-20010315 as a canonicalization method - or at least this was in the profile originally signed by MS tools.

[vo-va]

Hello,
Is there any update on this issue?

[vo-va]

Microsoft windows uses xsd to validate xml.
xsd schemas are available under %SYSTEMROOT%\schemas\provisioning on any computer that is running Windows 8, Windows 8.1, or Windows 10. (from this page https://docs.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/account-provisioning#find-the-account-provisioning-schema)

Or on this page https://docs.microsoft.com/en-us/uwp/schemas/mobilebroadbandschema/carriercontrolsignatureschema/schema-root (scroll to down of pages there will be full xsd file)
And there is restriction of xml file

  <element name="Transforms" type="ds:TransformsType"/>  
  <complexType name="TransformsType">  
    <sequence>  
      <element ref="ds:Transform" maxOccurs="1"/>    
    </sequence>  
  </complexType> 

  <element name="Transform" type="ds:TransformType"/>  
  <complexType name="TransformType" mixed="true">  
    <attribute name="Algorithm" use="required">   
      <simpleType>  
        <restriction base="anyURI">  
          <enumeration value="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>  
        </restriction>  
      </simpleType>  
    </attribute>  
  </complexType> 

[kislyuk]

I don't currently use software that is incompatible with the way SignXML produces signatures. It's clear that there is demand for fixing the underlying issue here, which is that SignXML only produces "Compatibility Mode" signatures, and not "2.0" signatures. I have described the issue in further detail in #142.

With apologies for not having had time to look at this issue in this level of detail sooner, I must ask that someone familiar with these applications write a principled solution for #142, with a separate test case, if you want this issue to be resolved.

[kislyuk]

SignXML does not and will not support the XML Signature 2.0 draft or this custom "CarrierControlSignatureSchema" that Microsoft came up with (which is not compatible with the W3C XML Signature 1.1 standard).

If you encounter ergonomics issues in subclassing SignXML for this use case, please feel free to open a new issue.