- From: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>
- Date: 19 Apr 2010 18:57:32 +0200
- To: "Pratik Datta" <pratik.datta@oracle.com>
- Cc: "XMLSec WG Public List" <public-xmlsec@w3.org>
Pratik, see inline. Pratik Datta schrieb: > 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. > Agreed, however, we implemented it for single-pass. Once you've completed the document (more precise: the last signed subtree) you can compare the digests with what you already parsed and stored before (from the References). You can retrieve and store both information combined in a single pass, then see what matches, and if all references are matching to signed subtrees (and the signature value over SignedInfo can be verified) the signature is valid. No need for a second pass in this setting. > 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. > We've implemented such gateway already (see Ph.D. thesis of Dr. Nils Gruschka, University of Kiel, Germany, 2007 or 2008). You are correct that the gateway is forced to store the message until signature verification is done, however, it is not necessarily processed a second time. Either you can implement your application in an event pipeline (see our SAGC@ARES2010 paper), waiting for the "endDocument" event to do the application-specific transactions, but storing all necessary data within first processing, or the gateway may decide to forward the message on successful signature verification (hence flush the message text to the network, not second XML processing step done). > 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. > As stated above, especially for XML security gateways you don't want to do a second XML parsing task. If the signature is placed before the referenced subtree, you can extract and follow the references, digest and compare the hash to what was given in the Reference. The troubles start when the signed contents start before you've read the SignedInfo (as e.g. in SAML tokens, since they use enveloped signatures). In that case you can assume the existence of a Reference from the presence of a "wsu:Id" attribute, but you'll never know about it (and its c14n, transforms etc.) until you've seen the SignedInfo block. By now, our gateway just started digesting 4 different c14n settings (inc/exc, with/wo comments), then comparing according to what was later on seen in the References. My intention here was to improve this by making this information explicit. If the WG decided not to use PIs then maybe additional (optional) attributes from the ds2 namespace might be defined, just in order to provide the c14n and transforms information for streaming-based parsers in the case of SignedInfo being late in document order. >From my experience, this really makes sense. best regards Meiko > 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:58:02 UTC