RE: [dss] Use cases and requirements input

[Simeon Falk Sheye <Simeon.Sheye@cryptomathic.com>]

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.

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.

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.


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.