- From: Pratik Datta <pratik.datta@oracle.com>
- Date: Mon, 19 Apr 2010 09:32:39 -0700 (PDT)
- To: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>, XMLSec WG Public List <public-xmlsec@w3.org>
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