Re: How to deal with null references?

Pratik, all,

if we introduce this new (optional) verification phase, maybe we could
additionally use it to enable ID-based referencing that is more
resistant to signature wrapping attacks. I imagine a second type of
verification "assertion" that may contain structural position
information about the referenced content. For instance, it could contain
XPath expressions that have to match the referenced content's position
in the document. This way, instead of "selecting" the referenced element
via XPath we just "verify" its position (which then is way more flexible
in terms of what is really enforced), but stick to ID-based referencing
in selection. I'm not yet sure which syntax would be reasonable, but a
first draft could be something like

<Verification>
  <PositionAssertion>
    /soap:Envelope/soap:Body
  </PositionAssertion>
</Verification>

The good thing about this approach is that implementations could simply
ignore this verification assertion and rely solely on the ID-based
referencing---on the risk of being vulnerable to signature wrapping.

By the way: are all <Verification> assertions (or whatever we call them
in the end) mandatory to hold, meaning that signature verification will
fail if one of them does not hold? Or are they "optional" in the sense
that a verifier may ignore them, as long as the digests and signature
values match?

best regards

Meiko


Pratik Datta schrieb:
> Here is the proposal using the <Verification> ACTION-613
>
> Section 4.4.3.7 The "2.0 Mode" Transforms Processing Model
>
> Original:
> The special Transform element consists of a required dsig2:Selection  element followed by an optional CanonicalizationMethod element.
>
> Modified:
> The special Transform element consists of a required dsig2:Selection  element followed by an optional CanonicalizationMethod element and an optional dsig2:Verification element
>
>
> New Section 4.4.3.9  The dsig2:Verification element
>
> The dsig2:Verifcation is an optional element that will contain information to help in signature Verification. It will contain one or more of the following subelements
> 1.  <dsig2:DigestDataLength> which is an integer that specifies the number of bytes that were digested in this reference.  This can be used for multiple purposes, a) to debug digest verification failures, b) to indicate intentional signing of 0 bytes, this can happen if an XPath expression did not choose anything, c) to bypass the expensive digest calculation if the during verification the computed length doesn't match length found in reference.
>
> 2. <dsig2:DigestData> it is a base64 string, containing the actual pre digest data. This is practical to use only if the data is small, because it is really a duplication of all the data that was selected in the dsig2:Selection and then canonicalized. (Pratik: We haven't discussed this one yet. I have just put it out here, so that we can discuss in the next meeting. This option will be very useful for diagnosing canonicalization problems.)
>
>
>
> The 2.0 schema will be modified to include these new elements.
>
> Pratik
>
>
>
> -----Original Message-----
> From: Chris Solc [mailto:csolc@adobe.com] 
> Sent: Tuesday, June 29, 2010 1:29 PM
> To: Pratik Datta; Meiko Jensen; Thomas Roessler
> Cc: XMLSec WG Public List
> Subject: RE: How to deal with null references?
>
> It could also remove any need to compute the digest if the length of data being digested doesn't match the length found in the reference.  A nice performance win especially on less powerful devices.
>
> Chris.
>
> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Pratik Datta
> Sent: Tuesday, June 29, 2010 1:35 PM
> To: Meiko Jensen; Thomas Roessler
> Cc: XMLSec WG Public List
> Subject: RE: How to deal with null references?
>
> I am trying to generalize this to not just null references, but also references which unintentionally end up signing very little data.
>
> It would be nice to have a mechanism to indicate the number of bytes that were digested. E.g. the DigestDataLength in the example below . (I know this breaks the schema, so we can't really do it like this)
>
>
> <Reference>
>   <Transforms>...</Transforms>
>   <DigestValue>jksdakjlkah3FDsjkl</DigestValue>
>   <ds2:DigestDataLength>1200</ds2:DigestDataLength>
> </Reference>
>
>
> On the sender side after an application has called the signature library, it can inspect the DigestDataLength to check if it was 0 or a very low number - that would indicate a problem.  
> This would also help the receiver know if the sender really intended to digest 0 bytes.
>
> Pratik
>
> -----Original Message-----
> From: Meiko Jensen [mailto:Meiko.Jensen@rub.de] 
> Sent: Tuesday, May 11, 2010 9:57 AM
> To: Thomas Roessler
> Cc: XMLSec WG Public List
> Subject: Re: How to deal with null references?
>
> Yes it is, and of course, one should only process what was signed.
> However, I know lots of real-world scenarios in the Web Services world
> where this is not applied. You process and rely on the soap envelope,
> even if it is not signed at all. You have to in order to find the
> signature within the header. In the same way, for the Web Services case,
> signature validation and application logic may be separated in a way
> that prohibits the see-what-was-signed approach (e.g. as a dedicated Web
> Service Security Gateway).
>
> For all such cases that do not sufficiently follow the "good principles"
> such a restriction may turn out to be rather helpful, and I don't see a
> legal use case that would suffer from it (besides one of our ongoing
> academic approaches, but that's a different issue).
>
> However, as before, I do not insist in having it in. I just recommend
> it, based on my (and my colleague's)  experience.
>
> best regards
>
> Meiko
>
> Thomas Roessler wrote:
>   
>> Isn't this another instance of the more general effect that one shouldn't trust anything -- except for what one gets out of, e.g., evaluating a particular xpath?
>>
>> The real problem in the scenario you describe seems to be that neither side verifies that the xpath is what it's believed to be.
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
>>
>>
>>
>>
>>
>>
>>
>> On 11 May 2010, at 17:46, Meiko Jensen wrote:
>>
>>   
>>     
>>> Within the discussion on the XPath referencing style I remembered an
>>> issue we came across lately:
>>>
>>> If an XPath contains syntactical errors, this does not result in a
>>> visible error. It is only treated differently, and might just result in
>>> referencing no node in the actual XML document. If that is not
>>> considered as an error in the XML Signature specification, there is a
>>> threat of someone screwing it up without noticing. Even the verifier
>>> does not notice: nothing was referenced, so the digest is calculated
>>> about the empty nodeset, hence about "". As this was exactly the same
>>> input as at the signer side, hash values match => signature is valid.
>>> However, it protects nothing in the document from modification.
>>>
>>> Hence, I recommend putting a sentence to XML Signature 2.0 stating that
>>> a reference to an empty nodeset MUST be treated as a fault.
>>>
>>> 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
>>>
>>>
>>>
>>>     
>>>       
>>   
>>     
>
>
>
>
>
>   

-- 
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