W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2009

Re: ACTION-127: Tade-offs between different extensibility mechanisms

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Mon, 17 Aug 2009 07:50:14 -0400
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <9162AA1D-E9A5-4464-838C-9A4EEC158CCB@nokia.com>
To: ext Thomas Roessler <tlr@w3.org>
suggestion inline

regards, Frederick

Frederick Hirsch
Nokia



On Aug 17, 2009, at 7:33 AM, ext Thomas Roessler wrote:

> I propose adding the following text above section 2.1.2, under Best
> Practice 3 ("Consider avoiding XSLT Transforms"):
>
>> Instead of using the XML Signature XSLT transform, deployments can
>> define a named transform of their own, by simply coining a URI in
>> their own domain that can be used as the Algorithm.  How that
>> transform is implemented is then out of scope for the signature
>> protocol -- a named transform can very well be built in XSLT.

ok

>
>> In deciding whether to pursue this avenue - instead of embedding
>> XSLT transforms in-line with the signature - considerations will
>> involve the ease of deployment and flexibility:
>> When the XSLT
>> transform mechanism is used to transmit transforms inline, then the
>> signer can change the untransformed data format and the
>> transformation without having to synchronize with the verifier, as
>> long as the result of the transformation meets the verifier's
>> assumptions.  In some use cases, this flexibility may prove
>> valuable.  Deployment of a named transform will require that signer,
>> verifier, and any intermediaries that need to process the transform
>> output, be aware of the identifier and the meaning of that transform.
>

I suggest replacing this second part with the following:

Choosing to name a new transform rather than embedding an XSLT  
transform in the signature reference has the advantage
that the  semantic intent of the transform can be made clear and  
limited in scope, as opposed to a general XSLT transform, possibly  
reducing the attack surface and allowing alternate implementations.

What may be lost is the general flexibility of using XSLT, requiring  
closer coordination between signer and verifiers since all will be  
required to understand the meaning of the new named transform.


> I don't know if there's much more we'd want to say about this; input
> welcome.
>
> FWIW, I consider my action item closed.
>
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
>
>
>
>
>
>
>
Received on Monday, 17 August 2009 11:51:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:59 GMT