Re: Fwd: Heads-up on proposed breaking change to XML Signature

Hi Pratik,

I am really glad to hear of your support of the basic subtraction issue.

I also quite agree that a vastly simplified transform system is 
preferable, as I typically have to provide this view of the world with the 
design tools.

On the surface, one might ask why XPath Filter 2 allowed multiple 
operations when it seems it would have been better to do a simple one-step 
transform and then count on the fact that the Reference processing model 
lets you run multiple transforms.  The answer there was performance.  All 
the set operations within a single XPath Filter 2 transform are done using 
a lightweight node marking strategy.  Outputing the result of a transform 
for processing by a subsequent transform is a more costly operation.

All of the transforms that I see fall into three categories:

1) The most prevailing case is simple subtract of a nodeset.  The subtract 
picks off a set of subtree roots and drops those from the thing that gets 
canonicalized and digested.  One of the nodes in the list is always the 
signature being generated.

2) The same as above, except the signature being generated has to "add 
back in" a ds:Object within the signature and/or the ds:KeyInfo.  This is 
common in the use of XAdES for example.  The ds:Object (or some part of 
it) contains metadata considered to be part of the signature (like a 
(unauthenticated) client-side timestamp). 

3) Simple selection of something to sign, which only happens for 
efficiency in a secondary signature, i.e. a countersigning signature that 
really is aimed at signing the same thing as a prior signer plus the prior 
signer's signature itself.

Anyway, the net of this is that the fully generalized solutions in XML 
Signature 1.0 don't seem to come up much in practice, but #2 above is an 
important use case which would not be straightforwardly satisfied via your 
suggestion to have exclusions override inclusions.  However, something 
*like* your idea would be to simplify the transforms down to what will 
meet the above cases, i.e. have a transform that could select, one that 
could subtract, and one that could subtract-then-reselect, and that's it. 

The last one, subtract-then-reselect, is like your idea, except it is 
saying that the explicit inclusion of reselect overrides the exclusion of 
the subtract, which in turn is overriding the default input to the 
transform, which one might imagine is the whole document.

Hope this makes it to your list...  If not, please forward it for me.

Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
Pratik Datta <pratik.datta@oracle.com>
To:
Thomas Roessler <tlr@w3.org>
Cc:
public-xmlsec@w3.org, John Boyer/CanWest/IBM@IBMCA
Date:
10/29/2008 02:52 PM
Subject:
Re: Fwd: Heads-up on proposed breaking change to XML Signature



Hi John

I completely agree on the document subtraction. This is required for 
many other use cases too - for example the EnvelopedSignature Transform 
itself is a kind of document subtraction. Also ebXML msg has subtraction 
requirements. Also the XPath Filter 2 is definitely faster  than the 
original XPath Filter.

The main problem that I have seen is there is too much flexibility in 
transforms. An XPath Filter 2.0 can include many intersect, subtract, 
union operations, and in fact there can be more than one XPath Filter 
transform in the transform chain. Also there is no restriction on the 
order of transforms - e.g. there can be an xpath -> c14n ->  xpath 
transform chain which probably doesn't mean anything but is still 
allowed. With so much of flexibility it is difficult to look at the 
signature and figure out what is really signed.  One idea I have 
proposed is to limit selection to one inclusion Xpath and one exclusion 
xpath  with exclusions overriding inclusions. See 
http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html
.

Also the XPath Filter 2.0 intersect/subtract/union operations are 
described terms of "nodeset" and a nodeset implies a DOM requiring all 
the nodes to be loaded up in memory at the same time, which is a big 
performance problem for large documents. I would like the new XML 
Signature spec to address Streaming issues and not leave it completely 
up to each implementor. Most of the signature examples that I have seen 
only need very basic XPath of the form /a/b/c , which can be easily 
streamed, it would be helpful if XML Signature identifies a streamable 
subset.

Canonicalization is a very hot topic, there have a been lot of 
disucssions in the group on it - especially around whitespaces and 
namespaces.

<http://lists.w3.org/Archives/Public/public-xmlsec/2008Sep/0000.html
>Pratik


Thomas Roessler wrote:
>
> Forwarding with permission.
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
> Begin forwarded message:
>
>> From: John Boyer <boyerj@ca.ibm.com>
>> Date: 28 October 2008 18:23:26 CEST
>> To: Thomas Roessler <tlr@w3.org>
>> Cc: chairs@w3.org, w3c-ac-forum@w3.org
>> Subject: Re: Heads-up on proposed breaking change to XML Signature
>>
>>
>> Hi Thomas,
>>
>> Thanks for taking the time to make this notification.  I generally 
>> agree that some simplifications would be helpful for performance and 
>> for making it easier to express signatures of higher security.  As 
>> I'll explain below, the focus on selection would be too restrictive, 
>> i.e. too much simplification, in that it tends to substantially 
>> *reduce* the security value of the signatures.
>>
>> However, it is easy to maintain the highest possible security while 
>> focusing for performance and simplicity on "selection".  The trick is 
>> to understand what must be selected and why.  Put simply, a document 
>> subset transform is more secure when it selects what must be 
>> subtracted from the document before the canonicalization and digest 
>> operations.  The subtraction filter, then, is a precise and explicit 
>> expression of what part of the document may still be mutated by the 
>> rest of a business process that occurs after the signature is 
>> affixed.  Any change to a document other than to the subtracted part 
>> will invalidate the signature as desired.
>>
>> For example, suppose you have a document with the familiar "office 
>> use only" section. When a user signs the document, the document 
>> subset should be the entire document less the "office use only" 
>> section.  This way, any change made to the document in any place 
>> except the "office use only" section would invalidate the signature. 
>> The purpose of a digital signature is to become invalid when any 
>> change is made, except those anticipated by the system.  Thus, 
>> subtraction filtering is the best fit for a document subset signature.
>>
>> By comparison, if a document subset signature merely selects the 
>> portion of the document to be signed, then additions can be made not 
>> only to the "office use only" section but also to any other location 
>> in the document that is outside of the selected portions of the 
>> document.  It is entirely too easy to exploit the document semantics 
>> and inject unintended side effects.
>>
>> Regarding the issue of performance, I would point out that the 
>> original XPath filter should be replace by XPath Filter 2, or 
>> something like it that is capable of subtraction.  Whereas the 
>> original working group paid insufficient attention to performance as 
>> an interoperability criterion in the original recommendation of the 
>> first XPath filter, the *fix* to that was the XPath Filter 2 
>> recommendation, which was *designed* for performance in the sense 
>> that high performance was considered to be a requirement. 
>> Specifically, interoperable implementations were expected to be 
>> capable of performing a subtraction filter on signature generation 
>> and validation operations over a 100K XML document in 1/4 second per 
>> operation on an 800MhZ computer.  This time includes not just the 
>> subtraction filtering, but the entire 
>> transform-canonicalize-digest-digest-encrypt sequence.
>>
>> The XPath Filter 2 transform should therefore be seen as highly 
>> performant, and I would assert it would be difficult indeed to 
>> provide actual empirical evidence to the contrary.  That being said, 
>> the XPath Filter 2 transform internally allows any number of set 
>> operations of subtraction, union and intersection.  Given the fact 
>> that XML Signatures itself allows multiple References, it would seem 
>> that a single operation of subtraction or selection would be 
>> sufficient for all practical purposes.
>>
>> To be clear, IBM currently ships successful products that are based 
>> on XML Signatures and that are particularly dependent for security 
>> reasons on the existence of subtraction filtering. However, in the 
>> design tools we offer for constructing document signatures, we 
>> simplify the interface down to a simpler set of operations, which you 
>> now appear to be wanting to achieve at a markup level.   This would 
>> make it easier for design tools to offer a visual/gestural experience 
>> that is close in concept to the actual markup that is generated, 
>> which in turn makes it easier for design tools to figure out what has 
>> happened in prior design experiences based on the markup.  There's 
>> just a lot fewer unnecessary knobs and dials, so to speak, so this 
>> seems like a good direction for the working group to take.  As long 
>> as it is clear, in case I haven't said it enough, that we need 
>> document subtraction.
>>
>> As a final point, I realize that this message indicates you are 
>> focusing on the transformation-digest-canonicalization sequence.  My 
>> greatest disappointment at the conclusion of the original XML 
>> signature group pertains to an aspect of canonicalization that the 
>> working group was unwilling to take on at the time due to the newness 
>> of the technologies needed to address it.  But those technologies are 
>> now entrenched, so I would strongly urge the new working group to 
>> reconsider.  The issue is that the current canonicalization 
>> algorithms make no use of DTD or Schema information that might be 
>> available on when whitespace is important and when it isn't.  It is 
>> easy with today's technology to determine when an element's content 
>> model permits whitespace merely as a convenience versus when the 
>> element actually has a PCData or mixed content model.  It would be a 
>> great service to the XML community to see a new canonicalizer that 
>> could detect and eliminate unnecessary whitespace from the canonical 
>> form.
>>
>> Best regards,
>> John M. Boyer, Ph.D.
>> STSM, Interactive Documents and Web 2.0 Applications
>> Chair, W3C Forms Working Group
>> Workplace, Portal and Collaboration Software
>> IBM Victoria Software Lab
>> E-Mail: boyerj@ca.ibm.com
>>
>> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>> Blog RSS feed: 
>> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>>
>>
>>
>>
>> From:
>> Thomas Roessler <tlr@w3.org>
>> To:
>> w3c-ac-forum@w3.org, chairs@w3.org
>> Date:
>> 10/21/2008 08:21 AM
>> Subject:
>> Heads-up on proposed breaking change to XML Signature
>>
>>
>>
>>
>>
>> Dear Chairs and AC representatives,
>>
>> The XML Security Working Group had a productive meeting here in Cannes
>> this Monday and Tuesday.  In outlining its roadmap for a next version
>> of XML Signature, the Working Group - as chartered - reviewed
>> possibilities for simplifying the specification.
>>
>> One area of that is promising for simplification is the Reference
>> Processing Model's ability to specify an (almost arbitrary) list of
>> transforms between node-sets and octet-streams.
>>
>> One option under consideration by the Working Group is to modify the
>> Reference Processing Model in XML Signature 2.0 to consider only
>> "selection", "canonicalization" and "digesting" transformations.  The
>> Working Group believes that there are significant security and
>> performance advantages to making this change to the XML Signature
>> structure, but it does constitute a restriction on behavior that is
>> currently permitted by XML Signature 1.0.  Specifically, this change
>> would still permit signing of document subsets but would prohibit
>> transformations of arbitrary complexity (e.g. unconstrained XSLT) from
>> being used within the XMLDSIG sturcture itself.
>>
>> We plan to outline this design idea in more detail in a Working Group
>> Note that we anticipate to put out for broad comment.
>>
>> At this point, we would be grateful for early feed-back about actual
>> use of custom Transforms with XML Signature that might be affected by
>> the change that is being considered.
>>
>> We're available in the hallways at TPAC to talk more about this, and
>> appreciate early feed-back.
>>
>> Regards,
>>
>> Frederick Hirsch (Nokia), Chair, XML Security WG;
>> Thomas Roessler (W3C), Security Activity Lead.
>>
>>
>>
>>
>
>