OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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