Re: Transform Note Design Decisions

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 <mailto:tlr@w3.org>>
>
>
>
>
>
>
>