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

Pratik,

you are right, the signer side poses some issues with one-pass as well.
I haven't thought about this problem since it does not directly affect
the XPath/ID selection itself. In fact, if you have an unsigned XML
document that you want to sign, this usually implies that you already
know what part of the document you want to sign (e.g. from an external
security policy or a statically configured selection). Hence, even if
the <ds:Signature> element is located before the selected part in
document order---which is the difficult case here---you don't run into
problems with the *selection*. There's no problem with having the
correct XPath/ID value being written to the <ds:Signature> element.

The problem is that you get the digest and signature *values* themselves
only after having processed the selected contents completely. If the
<ds:Signature> is located after the selected part in document order,
that's no problem, but in the other case you cannot put your calculated
digests into the <ds:Signature>, since it has already passed the
streaming processor. Yes, this means that the signer side cannot do
one-pass streaming in such cases.

However, I'm still struggling with the implications of this issue. In my
draft, the resulting recommendation was to avoid backward references
where possible. Now, if our intent is to optimize streaming for the
signer side, this leads to the recommendation not to use *forward*
references at all (since their digest values could not be added to the
<ds:Signature> element later-on). So we do have contradicting
implications here, and must decide on which of both approaches we favor
(or whether we leave this open completely for the spec adopters...). I
still favor to avoid backward references (since to my consideration the
verifier side is way more critical than the signer side, and I'd assume
each signature gets applied once and verified n times), but I think we
need a WG's decision here. Afterwards I'll redo/extend the draft
accordingly.

best regards

Meiko

Pratik Datta schrieb:
> 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 Friday, 10 September 2010 09:20:14 UTC