RE: [dss] Use cases and requirements input

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

Title: RE: [dss] Use cases and requirements input

Some responses below:

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

Unless I am missing something, it seems to me that the relying party can still work with the XML structure, even if it is not signed.  It seems to me that what is gained by including the XML structure in the scope of the signature is protection from modification or substitution of that XML structure into another structure that will give the same result after applying the transform.  This is definitely useful.  I don't disagree with that.  I just want to be clear about what we achieve by doing this.  It's also not clear to me that defining the format of the signature is necessarily within the scope of this TC.  Our deliverables include protocols for obtaining and verifying signatures, not the signature formats themselves.  However, I think it is certainly worthwhile to include this use case at this point and see what requirements we get from it.

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

Perhaps.  I fear however developing a protocol that has many optional features that can be used at the client's decision and thus becomes so complicated that interoperability is difficult and it doesn't get used.  Thus, I would like to focus as much as possible on the actual signature validation.  However, let's discuss further after all of the use cases and requirements have been collected.

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

Agreed.  I'm just trying to decide which of the requirements that we come up with will be worth the added complexity in the protocol.  It's not clear to me that this one is.  But I would be interested in the opinions of others.

        Robert.