Re: Transform Note Design Decisions

+1

In addition to the security implications, the current transform  
complexity may have a negative impact on adoption and a declarative  
approach might help drive adoption going forward.

The WG may also wish to later examine in more detail how XML Security  
might integrate  in the context of XProc, to aid adoption.

regards, Frederick

Frederick Hirsch
Nokia



On Mar 25, 2009, at 1:23 PM, ext Pratik Datta wrote:

> We need to look at this at a higher level.
>
> Think of thick contract that you have to sign when buying real  
> estate. The real estate agent puts sticky note "sign here" in each  
> page that you need to sign. You sign them, and the agent verifies  
> that each sticky note has a signature.  So basically the process of  
> signing and verification is easy, but did you understand what you  
> signed ?
>
> That is exactly, how I view the current transform model - it tells  
> you the procedural steps for signing and verification, but doesn't  
> say how to understand what was really signed. This is a fundamental  
> problem in the spec and it needs to be addressed, and this why we  
> need to move away from a procedural model and go to declarative model
>
> Continuing with the above analogy, the transform extension point is  
> like somebody inserting a few sheets in greek (or some other  
> language you are unfamiliar with) into your contract. Yes, you can  
> sign them because those sheets also have the sign-here sticky note.   
> But did you understand them at all? Do you know how they fit into  
> the overall contract?
>
> What we need is a simple way for an application to determine what is  
> signed - the more complexity we put in the procedural steps, the  
> harder this problem becomes. In the transform note, I have attempted  
> to restrict to very simple subset which in my experience is what  
> most people use currently.
>
> The performance/streaming aspect of it the transform is a completely  
> orthogonal problem, which I want to solve too, but that is not the  
> major focus of this transform simplification note.
>
> I know there are lot of toolkits already implementing the dsig 1.0  
> standard and it is hard to justify a change, but I also know that  
> many applications built on top of dsig 1.0 do not even bother to  
> check what is signed. Many developers who use dsig Apis, are often  
> new to security - they get so caught up understanding all the  
> concepts - SignedInfo, KeyInfo, Transforms, Namespaces, C14N  
> issues ... they forget to do the basic thing of checking what is  
> signed.
>
> So far there have not been any publicized attacks on dsig, but this  
> could happen - that might drive people to move away complex  
> signature technologies and go towards basic SSL. We need to  
> proactively think of ways to simplify our model, to hope to prevent  
> such a scenario.
>
> Thomas, regarding your nodeset question, I have been also trying to  
> think of an different model  to represent a document subset - the  
> event stream is a popular model in streaming parsers, but maybe we  
> need to define our own model.
>
> Pratik
>
>
>
>
> Thomas Roessler wrote:
>>
>> I've reviewed the transform note with a view toward identifying the  
>> design decisions in it.  Here's what I came up with:
>>
>> - Processing as XML and binary is made explicit (the type  
>> parameter); it seems like we can't switch back and forth between  
>> the two during processing.  There's special case handling for  
>> extracting base64 encoded material from XML.
>>
>> - There's a fixed sequence of selection, possibly an external XSLT  
>> transform (the idea is to have a well-known transform and no  
>> transforms inline), and then canonicalization.
>>
>> - The selection is a further simplified version of the XPath Filter  
>> 2.0 transform, plus (optionally) the existing decryption and  
>> nveloped signature transforms.
>>
>> - Canonicalization is restricted to the pre-hashing use case, which  
>> relaxes some constraints; however, we don't have a good design  
>> draft of what that simpler canonicalization could look like.
>>
>> I was trying to frame my thinking about this as "how do these  
>> design decisions affect the existing model"; the point where I have  
>> most trouble right now is the data model that we expect to work on  
>> top.  Is all of this implementable on top of an event stream?  Do  
>> we still need to handle a node-set, but with the knowledge that  
>> that node set is structurally simpler?
>>
>> Help, please!
>>
>> Thanks,
>> --
>> Thomas Roessler, W3C  <tlr@w3.org>
>>
>>
>>
>>
>>
>>
>>
>

Received on Monday, 30 March 2009 18:57:47 UTC