RE: [dss] Use cases and requirements input

[Gregor Karlinger <gregor.karlinger@cio.gv.at>]

Simeon,

In general, I think we have quite a common understanding of the
"secure transform chain" use case. Please see my comments below
for the motivation of my feeling.

>Liebe Gruesse/Regards,
>Gregor Karlinger

>-----Original Message-----
>From: Simeon Falk Sheye [mailto:Simeon.Sheye@cryptomathic.com]
>Sent: Tuesday, January 28, 2003 1:03 PM
>To: gregor.karlinger@cio.gv.at; dss@lists.oasis-open.org
>Subject: RE: [dss] Use cases and requirements input
>
>
>
>Gregor,
>
>I have a comment to item 1.1 below (transform chain).  Regarding where
>the transform takes place, I think it must at least  be possible for
>the server to carry out the transformation, because this  allows the
>server to present the transformed data on a separate channel.
>
>An example could be:
>1. The user enters data in his browser.
>2. The browser prepares DataToBeSigned and submits it to the server
>   (including transformation algorithm and parameters)
>3. The server prepares the transformed data
>4. The server sends the transformed data back to the user for
>   approval.
>   This could be by a separate channel such as SMS or MMS.
>5. The user acknowledges or rejects the presented data.
>6. The server decides whether or not to generate the signature based
>   on the  answer in step 5.
>
>If the server is trusted, a scheme like the above restricts the scope
>of  attacks open to a rouge client, because a separate channel is used
>to  authorise the signature.  The scheme does not hold if the client
>itself prepares the transform.

We have a very similar scenario in mind here in Austria as part of the
Austrian Citizen Card concept (enabling the citizen to produce signed
documents in a satisfying qualitiy).

>Regarding what is actually signed by the server, I think it is most
>important  that the transformed data (including DataToBeSigned,
>transformation and parameters)  is signed, since this reflects what
>the user actually approved.  However, to liberate the relying party
>from the burden of  carrying out the transformation, the
>DataToBeSigned should have its own separate signature.  If the
>signature service is trustworthy (i.e. it ensures that DataToBeSigned
>and the transformed data are only signed pairwise), it is sufficient
>for  the relying party to store (and not validate) the transformed
>data and only validate  DataToBeSigned. In case of a dispute between
>the user and the relying party,  the signed transformed data can be
>retrieved and verified.

This is exactly what I wanted to describe with my use case. It is
essential in this scenario, that the "linkage" between the 
DataToBeSigned and the TransformedData is secured by cryptographic
means. 

An "ordinary" XML signature secures the following:

  - the TransformedData
  - most of the parameters of the transform instructions

Unfortunately, the following parts are not secured:

  - the DataToBeSigned
  - some parameters of the transform instructions (currently I am
    aware of a single parameter, namely stylesheets that are referred
    in import statements of the base stylesheet in an XSLT transform).

Since the TransformedData is the actual data which has been presented
to the client, and all the other stuff (DataToBeSigned, transform
parameters) is just for further processing by machines, I suggested
the following for an "all-inclusive" XML signature:

  - supplement the "ordinary" XML signature with a DSIG Manifest which
    contains DSIG References to
     o the DataToBeSigned
     o all transform parameters which are not yet secured by the 
       "ordinary" signature

>To summarise, my opinion is that
>1. The server must be allowed to perform the transformation
>   (not necessarily required to do so), and
>2. It should be possible to get two signatures in one operation
>   a. The first on the DataToBeSigned, excluding transformation
>   algorithm and parameters
>   b. The second on the treansformed data, including DataToBeSigned,
>      transformation algorithm, parameters and the transformed data.

The "all-inclusive" XML signature I suggest both includes (a) and (b).
To check signature (b) you make an ordinary verification according to
the processing model of XMLDSIG. To check signature (b), you have to
check the additional DSIG manifest.

>
>
>Simeon Sheye
>Cryptomathic
>
>-----Original Message-----
>>From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com]
>>Sent: Thursday, January 16, 2003 9:55 PM
>>To: 'Gregor Karlinger'; ML OASIS DSS
>>Subject: RE: [dss] Use cases and requirements input
>>
>>
>>Comments below:
>>> 1.1 Securing the transform chain
>>>
>>> If XML data should be signed by a human, the following
>>> problem can appear:
>>>
>>> For machines, the data to be signed by the human should be
>>> the pure XML data, since this is the format which will be
>>> further processed. On the contrary, for the human, signing
>>> pure XML structures is not feasable since he must be able to
>>> comprehend what he is signing.
>>>
>>> With XML signatures, this problem can be solved by using the
>>> transforms concept. The pure XML data is fed into a
>>> stylesheet transform, whicht transforms it into - lets say -
>>> an HTML document. This HTML result can be shown to the human
>>> and will be signed.
>>>
>>> But this solution only solves the signature creation. The
>>> signature validation is still a problem, since the machine
>>> wants to further process the pure XML data, but the human
>>> has signed the transformed data.
>>>
>>> To overcome this problem, special means have to be taken
>>> during the signature creation: Not simply the resulting
>>> transform data has to be signed, but also the pure XML
>>> data as well as the way to get the transform data from the
>>> pure XML. Those additional data items should be put in a
>>> dsig:Manifest, since it is not really data signed by the
>>> human, but rather "technical data" signed by the client
>>> software used by the human to create the signature.
>>
>>Just so that I am clear, the purpose of this is (assuming a
>>trustworthy signature implementation) just to prevent
>>modification or substitution of the pure XML and transform data?
>>
>
>Let's have a look at the following example:
>
>o The maschine wants the following XML form to be signed:
>
> <Data2BeSigned>
>   <Name>Gregor</Name>
>   <Donation>100$</Donation>
> </Data2BeSigned>
>
>o Since the human does not want to sign the pure XML (though this
> simple XML structure is understandable, but not a more complex
> structure), the XML structure is transformed into a human-
> feasable html representation using a stylesheet transform; so
> the signature created by the human will look like:
>
> <ds:Signature>
>   <ds:SignedInfo>
>     ...
>     <ds:Reference URI="data2BeSigned.xml">
>       ...
>       <ds:Transforms>
>         <ds:Transform Algorithm="...stylesheet">
>           <xsl:stylesheet>
>             <!-- Stylesheet for transforming XML data into
>                  HTML -->
>               ...
>               <!-- basic stylesheet imports another stylesheet
>                    document, let's say anotherStylesheet.xsl -->
>               <xsl:import>...></xsl:import>
>               ...
>           </xsl:stylesheet>
>         </ds:Transform>
>       </ds:Transforms>
>       ...
>     </ds:Reference>
>   </ds:SignedInfo>
>   ...
> </ds:Signature>
>
>o Now, the relying party still wants to work with the XML structure
> (<DataToBeSigned>), but the human has signed its XML representa-
> tion.
>
>o This can only be achieved if all the parameters needed to compute
> the transform chain in <ds:Transforms> are covered by the signa-
> ture as well:
>
> - The definition of the transforms to be computed is part of
>   ds:SignedInfo and therefore already covered by the signature.
>
> - The input into the first transform (the XML structure referred
>   to by the URI "dataToBeSigned.xml" in ds:Reference) is not
>   covered by the signature; so it must be additionally included
>   into the signature (I suggest a ds:Refernence in a ds:Manifest).
>
> - The basic stylesheet is part of the transform definition ->
>   nothing additional to do.
>
> - The cascaded stylesheet "anotherStylesheet.xsl" imported into
>   the basic stylesheet is not part of the transform definition;
>   it must be additionally included into the signature as well.
>
>o In order to support this scenario, the signature valdiation
> service must check if all "additional transform parameters"
> - in the example "dataToBeSigned.xml" and "anotherStylesheet.xml" -
> are secured by the signature.
>
>
>>> 2.2.1 Provide data actually signed
>>>
>>> For the requester it is also important to know WHAT has been
>>> signed by the signature to be validated. If the validation
>>> service does not provide this information, the requester has
>>> to process the transforms specified in the signature; but
>>> this is lots of work.
>>
>>My opinion is that in order to keep the protocol that we
>>eventually decide upon as simple as possible, the validation
>>service should only provide services directly related to
>>signature validation.  I see this as more of an XML processing
>>service provided in addition to the validation service.
>>Personally, I think it would be best to assume that the client
>>will process the transforms, and would rather not see this as a
>>requirement.
>>
>
>I do not share your opinion. If the client needs to process the
>transform, this is quite painful since the client has to under-
>stand lots of different transforms (i. e. needs appropriate
>software tools); I estimate that processing of the transform
>makes about 2/3 of the overal work to validate the signature.
>
>I do not argue that the information what has been signed must
>be given to the client in any case, but it should be an optional
>feature at the client's decision.
>
>>> 2.2.4 Allow for configuration profiles
>>>
>>> - Trust
>>>
>>> The requester should be able to specify the trust settings
>>> (accepted root certificates, accuracy of CRL checking, ...)
>>> to be applied by the service when validating a signature.
>>>
>>> Since this trust-related information can be quite bulky, the
>>> requester should alternatively identify this information by
>>> a named profile.
>>I'm not opposed to allowing requesters to specify the trust
>>settings, but not at the expense of producing a protocol that is
>>more complicated that necessary.  I'm guessing that this feature
>>would not be required in the majority of signature validation
>>server environments.  The trust settings would be implicitly
>>defined by the service.  At least in our first iteration I would
>>like to produce something that is simple, usable and works.  We
>>can then build upon that.
>
>I think that there is not a 1:1 relation between a signature
>validation service and a trust setting in lots of cases; Different
>clients will use the same validation service, but with different
>trust settings.
>
>One could argue that you can achieve this by providing different
>access points for those different services (i. e. a different
>web service address for each trust setting). But this is simply
>a change of place from the application layer to the transport
>layer.
>
>
>

Attachment: smime.p7s
Description: application/pkcs7-signature