- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Fri, 7 Nov 2008 16:29:48 -0500
- To: ext Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, XMLSec WG Public List <public-xmlsec@w3.org>
comments inline (not as chair) On Nov 4, 2008, at 10:09 AM, ext Konrad Lanz wrote: > Dear fellow XML-Sec members, > >> Draft database certificate use case and requirements for document, >> share on mail list > > Let me first state more precisely that the requirement for XML > Signatures to be able to secure derived data is not only limited to > data > derived from a database. > > Rationale: The rational for requiring XML Signature applications to > remain (at least optionally) supporting standard XML transformations, > like stylesheet (XSL) is to have a deployed capability for securing > derived data. This data can either be retrieved from a data base or > larger xml documents and is to be transformed into human readable > formats such as HTML, XHTML, plain test or PDF. > > cf. http://www.w3.org/TR/xmldsig-core/#sec-Seen >> If signing is intended to convey the judgment or consent of a user >> (an automated mechanism or person), then it is normally necessary to >> secure as exactly as practical the information that was presented to >> that user. Note that this can be accomplished by literally signing >> what was presented, such as the screen images shown a user. However, >> this may result in data which is difficult for subsequent software to >> manipulate. Instead, one can sign the data along with whatever >> filters, style sheets, client profile or other information that >> affects its presentation. > frederick: cannot this last sentence be achieved by including a ds:Reference to the data pre-transform as well as a ds:Reference to the transform itself? The referenced text seems to imply that case. If so, then an XSLT transform need not be supported as part of the ds:Reference transform chain itself since it may be applied distinct from that chain, as long as signing can include pre-transform data as well as the transform itself. In other words XML Signature need not define and support arbitrary transformations or workflow, yet can be used to secure such workflows. > > 1. Requirement: XML Signatures should be able to secure derived data. > The chain of transforms is supposed to be secured by the signature > itself and shall express the derivation as reproducible processing to > retrieve the actually secured data (the digest input), which is to be > presented to the user. > > cf.: http://www.w3.org/TR/xmldsig-core/#sec-See : >> the transformed document that should be represented to the user and >> signed > > As concerns about the trustworthiness and the impracticably and high > costs of inspecting and analyzing stylesheets have been raised: > frederick: Again, isn't all that is required is to be able to sign source data and each transform source. Thus why do transforms need to be within the ds:Reference chain. Why cannot they be executed "outside of the signature processing model" as long as the signature is able to secure the material as described in the quoted see-what-you-sign reference. > 2. Requirement: The ds:SignatureValue and the ds:SignedInfo shall be > verified before the ds:Reference elements. Hence only signed > ds:Transforms will be executed. > Stylesheets referred to via xsl:include or xsl:import will have to be > referred to by a ds:Reference previous to the ds:Reference in question > (the one including/importing the other stylesheets). > frederick: I don't understand the "Hence". Why does this follow from order of verification? Do we need a best practice regarding includes/imports? > 3. Requirement: XML Signature Spect should require implementations to > prominently allow to access the digest input. > frederick: This agrees with desire for explicit selection/exclusion transform, yes? > 4. Requirement: Requirements 1. to 3. should not prevent a profile or > new markup to clearly designate constrained transforms allowing for > streaming processing, potentially including constrained stylesheets. > frederick: how unconstrained is this? is that an issue? I think we might want to disallow arbitrary transforms. Again, cannot that effect be achieved outside the XML Signature processing rules and structure? > Konrad > <Konrad_Lanz.vcf> While the requirements 1-3 seem appropriate, I'm not sure they necessitate the use of XSLT or other transforms in a ds:Reference chain to achieve them. regards, Frederick Frederick Hirsch Nokia
Received on Friday, 7 November 2008 21:31:06 UTC