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: [dss] Core spec: client-side transforms, etc.


Konrad Lanz wrote:
> Hi Trevor,
> 
> Trevor Perrin schrieb:
> 
>> [...]
> 
> 
>> My question below is still outstanding, as for why servers will be 
>> signing documents which are different from what clients send,
> 
> 
> Please read 
> http://www.cafeconleche.org/books/xmljava/chapters/ch10s05.html

Okay, I looked through it briefly.  Thanks for pointing this out, this 
seems important regardless of splicing.

Basically, the page describes options for a DOM parser, such as:
  - discarding whitespace not allowed according to a schema
  - discarding content whose values can be inferred according to a schema
  - discarding namespace declarations
  - re-encoding characters
  - re-encoding values to "normalized" form, i.e. "1" -> "true"

I think these things are bad, at least for basic processing, and we 
should add text to disallow them.

Default server behavior should be to sign what clients send, or add 
explicit transforms, *not* to silently discard portions, re-encode, or 
normalize it.

At least that's my opinion.



> (c) 2000,2001 Elliotte Rusty Harold and most of what is bespoken there 
> is already reality these days.
> Read also http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#key-nv
> 
>> so that document-splicing on the client-side will be unreliable.
> 
> 
> After you have read the first parts of these links above, you should 
> have an idea of how n clientside-parsers will behave in combination with 
> m severside-parsers, if the input document was not embedded binary by 
> the client using Base64XML or as a character stream by EscapedXML.
> The situation gets worse if the input had to be on the client side to be 
> transformed and these problems apply now as well.
> I think however that m severside-parsers can be managed.
> 
>> [...]"""
>> Could you explain in detail, with some examples?

(Thanks for the concrete example - This seems a good example for the 
client-side transforms issue, not the splicing issue, so I'll deal with 
it in that context.)

Anyways, below are two transforms.  The first one selects a node-set 
from the input document.  The second one goes back to the original input 
document, and adds onto the node-set.

Konrad points out that if the client only sends the transform results 
after the first transform, the server will not have the context (the 
original input document) to apply the second transform.

My proposal is that if the server wants to apply a transform such as 
this, it needs to operate under some profile or policy which requires 
the client to send the entire untransformed input document.

Since many servers will place requirements on the form of input 
documents, I think these requirements are best handled at the 
policy/profile level, while basic processing should support the most 
general form of input documents.


> Please consider the following Transforms:
> 
>           <dsig:Transforms>
>             <dsig:Transform              
> Algorithm="http://www.w3.org/2002/06/xmldsig-filter2";>
>               <dsig-xpath:XPath Filter="intersect"> 
> //*[starts-with(name(),'B')] </dsig-xpath:XPath>
>               <dsig-xpath:XPath Filter="union"> //AAA </dsig-xpath:XPath>
>             </dsig:Transform>
>             <dsig:Transform              
> Algorithm="http://www.w3.org/2002/06/xmldsig-filter2";>
>               <dsig-xpath:XPath Filter="union"> //EEE </dsig-xpath:XPath>
>             </dsig:Transform>
>           </dsig:Transforms>
> 
>     <AAA>
>          <CCC>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>          </CCC>
>          <DDD>
>               <BBB/>
>               <BBB/>
>          </DDD>
>          <EEE>
>               <CCC/>
>               <DDD/>
>          </EEE>
>     </AAA>
> 
> Client applies frst transform and sends:
>     <AAA>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>     </AAA>
> 
> Transmission
> 
> Server applies second transform and signs:
>     <AAA>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>     </AAA>
> 
> 
> However, if either the client or the server would have applied both 
> transforms they would have signed:
> 
>     <AAA>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>               <BBB/>
>          <EEE>
>          </EEE>
>     </AAA>


Trevor


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]