RE: When one-pass streaming is not possible...

Meiko,

Forward reference work well for Verification, but how about for Signing?

You would have to emit the signature first, then emit the data to be signed and as you are emitting the data to be signed you also canonicalize digest them. But then how will you go back to the signature and update the digests?


The only possible solution where both Signing and Verification will work with one pass streaming is if we have  this order

1) Identify what is signed, using IDs or Xpath
2) The Data to be signed
3) The digest of the data and the signature value 

The problem is that 1) and 3) are present together inside the Signature.  So if you put 2) before 1) and 3) or 2) after 1) and 3), both situations cause problems.  Konrad had suggested a solution to put the entire data inside a transform called "DataTransform", that would do this 1) 2) 3) ordering, but that solution is completely broken from applications point of view. Because applications want to be control of the layout of the data, and not be driven be signature requirements.

Pratik

-----Original Message-----
From: Meiko Jensen [mailto:Meiko.Jensen@ruhr-uni-bochum.de] 
Sent: Monday, September 06, 2010 7:10 AM
To: XMLSec WG Public List
Subject: When one-pass streaming is not possible...

I drafted some text for the new "XML Signature Streaming Profile for
XPath 1.0 1.0" (scnr :) ) regarding those cases of XML Signature that
are not possible to be done in a one-pass streaming approach (my
Action-644).

I suggest adding this paragraph at the end of Section "2 Streamable" (or
as a new section "On Streamability"):
==================================
Note that it is not always possible to apply or verify XML Signatures in
a one-pass streaming fashion. For instance, the verification of an
enveloped signature requires an XPath for selection that matches an
element that is located prior to the XML Signature itself (in document
order). Hence, on signature verification, the selected elements are
processed by the streaming parser before the selection XPath itself gets
parsed. Example:

-----------------------------
<Document>

  <DataBlock1 />

  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo> 
      [...]
      <Reference>
        <Transforms>
          <Transform
Algorithm="http://www.w3.org/2010/xmldsig2#newTransformModel">
            <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml"
xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" URI="" />
            [...]
          </Transform>
        </Transforms>
        [...]
      </Reference>
    </SignedInfo>
    [...]
  </Signature>  

  <DataBlock2 />

</Document>
-----------------------------
As can be seen, the XML Signature selects the whole document, hence all
XML elements therein must be processed on signature verification.
However, when parsing this document using a streaming approach, the
verifying application might not know in advance which parts of the
document are protected by the XML Signature. Hence, it will start
parsing the document to extract the XPath expressions used for
selection, but once it encounters that information, all the elements
processed before have already been processed and dismissed (such as the
<Document> and <DataBlock1> elements). Thus, these elements have not
been digested, and hence there is no way to verify such an XML Signature
in a one-pass streaming fashion.

Note that this impossibility of one-pass streaming is not only affecting
enveloping signatures. For instance, an XML Signature verification with
a selection of
-----------------------------
            <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml"
xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" URI="" >
              <dsig2:IncludedXPath> //DataBlock1 </dsig2:IncludedXPath>
            </dsig2:Selection>
-----------------------------
would have also failed due to the same issue, though not being an
enveloped signature. The same holds for ID-based selection if the
selected elements occur prior to the XML Signature in document order.

In general, applications SHOULD avoid backward references of any kind if
they want to use streaming-based processing of the XML Signature.
==================================

This should close my Action-644.

Besides: During drafting the text I came across some issues I found
worth discussing:

#1:
I took the XMLDSig2 example code from the latest editor's draft
document. Is it correct that this example still uses the
"newTransformModel" URI suffix in the Transform-Algorithm attribute? I
remember we've been talking about this one before (sth. like changing it
to "2.0TransformModel" or so...), but I'm not sure on the outcome...

#2:
Since the 2.0 mode disallows all kinds of transforms besides the new
selection-c14n-v10n transform, how do we cope with enveloped signatures
(and the enveloped-signature-transfom) in that case? Does a developer
have to explicitly add an appropriate XPath expression in ExcludedXPath
for the ds:Signature element? how does that one look like?
"<ExcludedXPath> //ds:Signature </ExcludedXPath>" ? Is this streamable?
Is this discussed somewhere in the spec / the best practices? I didn't
find anything on a quick review....

cheers

Meiko

-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Tuesday, 7 September 2010 19:50:18 UTC