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

RE: ACTION -169: Update draft - Transform Note

From: Ed Simon <edsimon@xmlsec.com>
Date: Mon, 02 Feb 2009 13:40:50 -0500
To: Brad Hill <brad@isecpartners.com>
Cc: "Graf, Kenneth M" <kenneth.m.graf@intel.com>, Pratik Datta <pratik.datta@oracle.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-Id: <1233600050.6833.9.camel@ES-XMLSEC.phub.net.cable.rogers.com>

Shouldn't an XML Signature instance include all the information needed
for a signature validator to validate the signature? This, to me, does
not put the Decryption Transform in the same category as the "Sign What
is Seen" issue. 

Ed


On Mon, 2009-02-02 at 10:02 -0800, Brad Hill wrote:
> Agreed.  I would add that I am opposed to perpetuating all "workflow" functionality, generally.  This would also include the decryption transform.
> 
> The problems of workflow and composition of XML processes got crammed into signature for want of a better place.  Today, the place for such use cases is XProc.
> 
> Brad Hill
> 
> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Graf, Kenneth M
> Sent: Monday, February 02, 2009 7:43 AM
> To: Pratik Datta; XMLSec WG Public List
> Subject: RE: ACTION -169: Update draft - Transform Note
> 
> 
> I am against perpetuating the "sign what is seen" use case.  The potential exposures to validators when XSLT is introduced are very serious, and I do not see how this achieves the stated goal.
> 
> If XSLT are limited to trusted XSLT then the following call sequences yield the same result. "viewerTransform" could be whatever fun things the browser and its plugins do so the user actually sees something.
> 
> whatIsSeen = viewerTransform( sign( htmlXsltTransform( rawData )))
> whatIsSeen = viewerTransform( htmlXsltTransform( sign( rawData )))
> 
> I prefer the later; In XMLdsig we do not control nor guarantee the proper operation of the viewerTransform, I do not see how including the htmlXsltTransform in the signing operation allows to achieve the "sign what you see" goal.
> 
> Thanks, Ken.
> 
> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Pratik Datta
> Sent: Monday, February 02, 2009 1:31 AM
> To: XMLSec WG Public List
> Subject: Re: ACTION -169: Update draft - Transform Note
> 
> 
> Here is a list of changes that I made
> 
> Changes that we had not discussed, or just alluded to.
> ---------------
> 1) Added details about the "sign what is seen" requirement. i.e. the 
> requirement to convert the xml to a html using XSLT and decrypt transform
>   a)  Section 2 bullet 4
>   b) Added a new <Transforms> element in between <Selection> and 
> <Canonicalization>
>   c) section 4.3
> 
> 
> 2) Clarified the requirements in section 3 - there are 4 bullets, and 
> each is expanded out
>   in detail in section 3.1 (determine what is signed), 3.2 
> (performance), 3.3 (security) and 3.4 (canonicalization)
> Section 3.1.1.  and 3.1.2 is new material - talks about problems in 
> determining what is signed
> Section 3.2.1 and 3.2.3 are also new - talks about performance problems.
> Section 3.3 is also new - security- it is basically all the DoS problems 
> listed in the best requirements doc. the requirement is to solve them
> 
> 
> 3) Removed Section 4, as that was overlapping with requirements and 
> design.  Problems in old spec is now part of requirements.
> 
> 4) Added some more properties to Section 4.4 canonicalization
>  serialization="EXI/XML" , sortAttributes="true/false", 
> preserverPrefixes="true/false"
>  
> 
> 
> Changes that were discussed
> -------------
> 1) added me as an Author
> 2) incorporated both of Frederick's emails
> 3) incorporated introductory text from Scott
> 4) incorporated , no entity expansion in C14N from Brad
> 5) Section 3.4 is canonicalization - it has been removed from the 
> requirements document, and placed here
>     It split up into 3.4.1 historical requirements, and 3.4.2 : modified 
> requirements. Modified requiremens is what we discussed in F2F
> 
> 6) Split up the deisgn into a section by element
>   4.2 <Selection>  4.3 <Transforms>  4.4 <Canonicalization>
> 
> 
> Pratik Datta wrote:
> >
> > I have updated the transform notes with all the discussions that we 
> > had during the Redwood City F2F.
> >
> > http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
> >
> > This closes ACTION-169
> >
> 
> 
> 
> 
> 
Received on Monday, 2 February 2009 18:41:33 GMT

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