[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: In relation to DSS Action Item - 06-04-24-01 - C14N Note
Hi Hal, eventually I found some time to elaborate this action further. regards Konrad Hal Lockhart wrote: > Konrad, > > I still have not heard from you, so I am guessing at what you intended > based your message from March 6. > > So far I have this: > ------------------ > > It is well known that problems of spurious validation errors can occur > with XML Digital Signature due to the inclusion of different namespace > declarations under the signature than those included when the signature > was calculated. The Exclusive Canonicalization Algorithm was devised to > address this issue. However, during our work, the OASIS Digital > Signature Services Technical Committee has identified additional cases > where this may occur. > > If expressions (XPath-Expressions) inside XPath-Filters (or > XPath-Filters 2.0), XSLT etc.. used in the chain of transforms (i.e. > <ds:Reference>/<ds:Transforms>/<ds:Transform>) are used in a way so that > they may also refer to parts of the surrounding context, e.g. a > transport protocol, the output will be different depending on whether > the document is inside that context or not. This can result in spurious > validation errors. > ------ > we can continue like this: Such transformations walk up the XPath ancestor-axis or refer to absolute parts that may be changed by processing and include or exclude elements depending on the . Hence somebody may repudiate to have created a valid signature if s/he has the possibility to choose the context in which the signature is to be verified. I.e.: The signature is valid in one system, but invalid in another one. The following line in WSS 1.1 section 8 <http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf#page=35> "... Instead, messages SHOULD explicitly include the elements to be signed. ..." suggests that explicit referencing of the relevant elements and their children to be signed is sufficient to prevent false negatives caused by changes to the transport protocol (i.e. soap headers). As mentioned above this isn't the case. Also the use of SOAP normalization as recommended in WSS 1.1 section 8.1 <http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf#page=36> is not sufficient as long as it is not performed as the first transform in the chain of transforms and then followed by canonicalization, so that the removed elements cannot be navigated anymore. The means identified by the OASIS Digital Signature Services Technical Committee to assure consistent behavior is "context free extraction" of signed inline XML content as in section 3.3.2 Process Variant for <InlineXML> <http://docs.oasis-open.org/dss/v1.0/oasis-dss-1.0-core-spec-cd-r4.pdf#page=22>. > Then you have this sentence: > > Behavior can then also change depending on SOAP normalizations > which is used in WSS. > > I am not sure what you meant here. Is this an additional problem? > No, it's the same problem. > Hal >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]