XPath Filter Transform and Namespace Declarations for Qualified Nodes

I received a question recently about declaring namespaces for qualified
nodes in the XPath string in an XPath Filtering Transform. Essentially,
it would appear that the XML Signature specification may need to be more
definitive about how such namespaces can be declared.

What is fairly clearly allowed, though maybe not so clearly specified,
by the XML Signature specification is the declaring of namespaces
through attributes of the XML Signature <XPath> element as so:

   <Document xmlns="http://example.org/doc">
     <Title>Example 1</Title>
   ...   
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      ...
       <Reference URI="">
         <Transforms>
           <Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
             <XPath xmlns:doc="http://example.org/doc">
             /doc:Document/doc:Title
             </XPath>
           </Transform>
         </Transforms>
         <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <DigestValue></DigestValue>
       </Reference>
     </SignedInfo>
     <SignatureValue></SignatureValue>
    </Signature>
    ...
   </Document>

The query I received asks, in the case of an enveloped signature, why
cannot one reuse existing namespaces contexts like so:

   <doc:Document xmlns:doc="http://example.org/doc">
     <doc:Title>Example 1</doc:Title>
   ...   
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      ...
       <Reference URI="">
         <Transforms>
           <Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
             <XPath>
             /doc:Document/doc:Title
             </XPath>
           </Transform>
         </Transforms>
         <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <DigestValue></DigestValue>
       </Reference>
     </SignedInfo>
     <SignatureValue></SignatureValue>
    </Signature>
    ...
   </doc:Document>

Part of my answer to that question would be that the namespace
declaration is not signed could therefore be manipulated so that the
signature still validates but the data being validated is not the data
that is supposed to be signed by the signature. Therefore, it is
important for namespace declarations used by the XPath Filtering
Transform to be signed.
Even so, that still leaves the possibility of putting the namespace
declarations in a signed ancestor element such as <SignedInfo>. E.g.

   <Document xmlns="http://example.org/doc">
     <Title>Example 1</Title>
   ...   
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo xmlns:doc="http://example.org/doc">
      ...
       <Reference URI="">
         <Transforms>
           <Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
             <XPath>
             /doc:Document/doc:Title
             </XPath>
           </Transform>
         </Transforms>
         <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
         <DigestValue></DigestValue>
       </Reference>
     </SignedInfo>
     <SignatureValue></SignatureValue>
    </Signature>
    ...
   </Document>

Though that might be secure, and I can see that for enveloping
signatures contain multiple objects in a certain namespace that some
might want to reuse an existing, signed top-level namespace declaration,
my preference is to limit flexibility unless there is a clear need. As
such, I propose the following text:

“If an XPath Filtering Transform instance includes qualified nodes, then
associated namespace declarations MUST be specified through attributes
of the <XPath> element.”

If there is a concensus that namespace declarations up to and including
the <SignedInfo> element are acceptable, the wording above can be
adjusted.

Thoughts?

Received on Tuesday, 7 April 2009 22:00:50 UTC