Re: Processing Instructions for supporting Streaming mode?

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