RE: Processing Instructions for supporting Streaming mode?

In the WS-Security, the <Signature> is usually before the data to be signed, however in practice this still doesn't give us 1 pass.
The problem is that you have a very large data that is signed, till you get the last byte you don't know if the signature will verify or not. 

This is especially a problem in XML gateways appliances. These appliances are sitting on the network and trying to verify signatures as the messages flow past. Suppose there is a 1GB data to be signed, with an XML signature, the XML gateway needs to have an onboard memory to store this 1GB data, because it cannot pass along the message as verified unless it has seen the last byte.  Contrast this to SSL, where each "SSL record" has a separate MAC, so each record can be verified independently, thus the appliance doesn't need this 1GB memory.

While it is true that the XML verification becomes one pass if the signature is first, the overall processing still remains two pass. In my mind it is not very useful to try to make verification one pass, since the application needs to make one more pass anyway. If we really want to make it one pass, we should attempt to have some kind of block/record/packet semantics.

Pratik

-----Original Message-----
From: Meiko Jensen [mailto:Meiko.Jensen@ruhr-uni-bochum.de] 
Sent: Monday, April 19, 2010 4:25 AM
To: XMLSec WG Public List
Subject: Processing Instructions for supporting Streaming mode?

Hi all,

regarding the support for streaming mode verification of XML Signatures
I'd like to throw in the following idea: Is is useful to define optional
XML processing instructions that indicate the parsing engine with all
information necessary to process the referenced parts of a document?
Strawman example:

<A>
  <?xml-signature c14n="..." digestMethod="..." ?>
  <SignedFragment>
    Some signed contents
  </SignedFragment>
</A>

This way, the parsing engine is not required to first inspect the
<ds:Signature> subtree for determining the selection paths (e.g. if that
information occurs late in the document, as e.g. in SAML Assertions).
Hence, this might allow one-pass signature verification instead of
two-pass/DOM in many scenarios. It's easier to collect all data, then
draw the links instead of starting with the <Reference> and follow a
backward link.

Obviously, the information given in the PI must be validated for
equality to those given in the <ds:Signature> part later on, to prevent
version-rollback attacks. However, I don't see a reason to have the PI
covered by any signature itself.

What do you think?

best regards

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. IC 4/150
D-44780 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// www.nds.rub.de

Received on Monday, 19 April 2010 16:34:33 UTC