[xmlsec] Signature in different namespace

[Simon Josefsson]

Interesting -- thank you for your insight.  How should XMLDsig be
referenced in XML Schemas?  I suppose you are saying that the following
approach used by PSKC is incorrect?

     <xs:complexType name="KeyContainerType">
          <xs:sequence>
...
               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>

/Simon

Aleksey Sanin <aleksey at aleksey.com> writes:

> I think it is a bug in the spec which makes it incompatible
> with W3C Digital Signatures spec.
>
> Aleksey
>
> On 10/15/12 2:27 PM, Simon Josefsson wrote:
>> Aleksey Sanin <aleksey at aleksey.com> writes:
>> 
>>> I don't see example but "ds:SignatureType" defines Signature node in
>>> the DS namespace.
>> 
>> The example is here:
>> 
>> http://tools.ietf.org/html/rfc6030#section-7
>> 
>> and contains
>> 
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <KeyContainer
>>        xmlns="urn:ietf:params:xml:ns:keyprov:pskc"
>>        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>>        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>>        Version="1.0">
>> ...
>>        <Signature>
>>            <ds:SignedInfo>
>> ...
>> 
>> I have validated the example against the schema using xmllint.  The
>> XMLSec library templates create a Signature element like this:
>> 
>> ...
>>        <ds:Signature>
>>            <ds:SignedInfo>
>> ...
>> 
>> With the "ds:" prefix on the Signature element, I get a schema
>> validation error:
>> 
>>     pskctool/tests/pskc-figure9.xml:30: element Signature: Schemas validity error : Element '{http://www.w3.org/2000/09/xmldsig#}Signature': This element is not expected. Expected is one of ( {urn:ietf:params:xml:ns:keyprov:pskc}KeyPackage, {urn:ietf:params:xml:ns:keyprov:pskc}Signature, {urn:ietf:params:xml:ns:keyprov:pskc}Extensions ).
>> 
>> However, I have come up with a temporary workaround: after
>> xmlSecDSigCtxSign() succeeds, I do a xmlSetNs (signNode, NULL) to clear
>> the namespace prefix for the Signature element.  This seems quite ugly
>> though.  I have yet to write the code to verify these signatures
>> though...
>> 
>> /Simon
>>