- From: Ed Simon <edsimon@xmlsec.com>
- Date: Tue, 07 Apr 2009 18:00:08 -0400
- To: XMLSec WG Public List <public-xmlsec@w3.org>
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