RE: [dss] Use cases and requirements input

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

Robert,

please find my comments inline below.

/Gregor

-----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.