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

ACTION-127: Extensibility mechanisms - input needed

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 5 Jan 2009 12:15:41 +0100
Message-Id: <1F1593DB-98AB-4689-9162-09AED4DB87D2@w3.org>
To: XMLSec WG Public List <public-xmlsec@w3.org>

Per ACTION-127, I'm to contribute text about extensibility mechanisms  
for the best practices document.

I was basically planning to spell out the trade-offs between custom  
transforms and use of generic transform mechanisms (like XSLT),  
roughly along these lines:

- Custom transforms require implementation in the verifier in order to  
even make core validation succeed.  They probably limit attack  
surface, because they do not involve running code that possibly came  
from the attacker.

- Generic transforms let core validation do its job without much extra  
handling; however, applications need to ensure that the transform  
that's sent by the attacker | signer is actually the transform they  
expect.  It is a good idea to verify that that is really the case  
*before* throwing the transform at the XSLT engine.

I then realized that these trade-offs might change when you factor in  
deployment stories for intermediaries:  Use cases where some generic  
intermediary is supposed to do a first level of signature verification  
before application logic is hit would seem to favor the generic  
transform model.

My question to the group is, therefore, whether people have any data  
on the use of such intermediaries beyond just WS-Security -- or, put  
differently, to what extent has this an issue, and to what extent  
hasn't it been?  It feels as though that would be useful information  
to factor in before writing up any best practice advice in the area.

Thomas Roessler, W3C  <tlr@w3.org>
Received on Monday, 5 January 2009 11:15:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:10 UTC