RE: [dss] Use cases and requirements input

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Title: 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? 

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

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

        Robert.