Re: [ACTION-98] Part-I: Requirement to sign derived data

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