Issue on verification for InlineXML

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Dear all,

While implementing DSS verifying protocol we have found what we think 
that is a potential
source of problems.

Section 4.3 step 1 describes the process to extract signed Document: 
"This document is extracted and decoded as described in 3.3.1 Step 1.a 
(or equivalent step in variants of the basic process as defined in 3.3.2 
onwards depending of the form of the input document)."
Section 3.3.2 Step 1.a describes the process to extract an InlineXML 
element from within the document. It says: "Exclusive Canonical XML MUST 
be applied to extract data...".

Imagine that we signe this document with my own local XMLdsig tool:

<b:doc xmlns:b="http://bb.b"; xmlns:c="http://cc.c";>
 <b:el1>Text....</b:el1>
 <c:el2>Text2...</c:el2>
</b:doc>

Imagine that the local signature tool canonicalizes the document 
producing the following data (DOC-CAN):
<b:doc xmlns:b="http://bb.b"; xmlns:c="http://cc.c";>
  <b:el1>Text....</b:el1>
  <c:el2>Text2...</c:el2>
</b:doc>

This data whould then be hashed and signed, producing the resulting XML 
signature.

If we want to verify the signed document using DSS verifying service we 
would generate a request like this:
<dss:VerifyRequest xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; 
RequestID="UPCRequestVerifyXMLSig_0">
 <dss:InputDocuments>
     <dss:Document RefURI="">
         <dss:InlineXML>
             <b:doc xmlns:b="http://bb.b"; xmlns:c="http://cc.c";>
                 <b:el1>Text....</b:el1>
                 <c:el2>Text2...</c:el2>
             </b:doc>
          <dss:InlineXML>
....Other data.....

Now, if the server proceeds as described in section 4.3 Step 1, it will 
extract element doc from the request and apply exclusive 
canonicalization to it. The result will be this (DOC-EXCL):

<b:doc xmlns:b="http://bb.b";>
 <b:el1>Text....</b:el1>
 <c:el2 xmlns:c="http://cc.c";>Text2...</c:el2>
</b:doc>

This document is different from the one signed (DOC-CAN), so it would 
produce a different hash value and therefore we think that it would 
generate an invalid signature validation

[DOC-CAN]
<b:doc xmlns:b="http://bb.b"; xmlns:c="http://cc.c";>
  <b:el1>Text....</b:el1>
  <c:el2>Text2...</c:el2>
</b:doc>
[DOC-EXCL]
<b:doc xmlns:b="http://bb.b";>
 <b:el1>Text....</b:el1>
 <c:el2 xmlns:c="http://cc.c";>Text2...</c:el2>
</b:doc>

We think that this is happening because the server is performing a 
transform (Exclusive canonicalization) that was not performed when 
creating the signature. This transform moves the namespace "http://cc.c"; 
with prefix c from element doc to element el2 because doc does not use 
this namespace but el2 does use it (see exclusive canonicalization). So, 
as Hash(DOC-CAN) is different from Hash(DOC-EXCL), the signature will 
then be invalid.

If what we have mentioned so far is true, we think that the problem
is in mandating extraction of the inline xml with exclusive 
canonicalization
from the VerifyRequest message. One thing is mandating an exc 
canonicalization
when you are signing and you may put the transformation indication 
within the
SignedInfo and something different is mandating to use exc 
canonicalization for
extracting XML: in this last case, the server does not have control on the
transformations applied for computing the signature, and must perform the
ones indicated in the SignedInfo generated by the signing device....

We think that some modification is required in section 4.3.

1. text in line 1368, text:

"This document is extracted and decoded as described in 3.3.1 Step 1.a 
(or equivalent step in variants of the basic process as defined in 3.3.2 
onwards depending of the form of the input document)"
could be substituted by:
"This document is extracted and decoded as described in 3.3.1 Step 1.a 
or equivalent step in variants of the basic process as defined in 3.3.2 
onwards depending of the form of the input document, except when the 
<Document> content is an <InlineXML> element. In this case, the server 
should extract <InlineXML> contents without taking inherited namespaces 
and attributes."


2. text in line 1388
Substitute
"a.    If the input document is a <Document>, the server extracts and 
decodes as described in 3.3.1 Step 1.a (or equivalent step in variants 
of the basic process as defined in 3.3.2 onwards depending of the form 
of the input document). "
by
"a.    If the input document is a <Document>, the server extracts and 
decodes as described in 3.3.1 Step 1.a or equivalent step in variants of 
the basic process as defined in 3.3.2 onwards depending of the form of 
the input document, except when the <Document> content is an <InlineXML> 
element. In this case, the server should extract <InlineXML> contents 
without taking inherited namespaces and attributes".

Could you please provide feedback?

Regards,

Juan Carlos Cruellas, Sergi Cabré