RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

["Nick Pope" <pope@secstan.com>]

Trevor,

I support Gregor's use case is realistic need.  There are situations where
the same data is required to be human readbale and machine processible, for
example my tax return which I want to keep a printed copy and also submit it
to the IRS / Inland Revenue for processing.  It is easier to prove that the
IRS processed what I saw if the human displayed version and the machine
processed version both are produced from the same raw XML.  The style sheet
used also needs to be signed though.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 25 March 2003 19:38
> To: Gregor Karlinger; robert.zuccherato@entrust.com
> Cc: ML OASIS DSS
> Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
>
>
> At 04:43 PM 3/25/2003 +0100, Gregor Karlinger wrote:
>
> >Robert & Trevor,
> >
> >I would like to make a clarification regarding the use case
> >"Securing The Transform Chain" I have submitted to the group:
> >
> >It seems that in the requirements draft there is a mix up of
> >two different stories:
> >
> >   1. The use case "Securing The Transform Chain" (which has
> >      been the first part of my message "Use cases and
> >      requirements input" sent to the list on Wed, 15 Jan
> >      2003 [1].
> >
> >
> >   2. A collection of requirements regarding digital signature
> >      services in general (which comprise the second part of
> >      that message).
>
> Okay.  I think all your general requirements are incorporated
> into section
> 3, in various places.  So we should change 2.7 to just mention the
> particular aspects of your use case.  I have a question about the
> use case,
> though:
>
> You mention using transforms to make XML data human readable (by
> turning it
> into HTML, say), and then signing the XML data along with the transforms,
> so the relying party can reconstruct exactly what the signer saw when he
> was signing.
>
> But then the XML data isn't really signed, so the relying party can't do
> anything with the XML itself - the transform might have turned
> the XML into
> something completely different.  So if all this accomplishes is
> transmitting signed HTML, why not just send signed HTML in the
> first place?
>
> It seems that, if you want the relying party to process XML, the
> XML itself
> needs to be signed, not a transformed, human-readable version of
> it.  Presenting the to-be-signed data to the signer in an
> agreeable format
> is the problem of the signer's application software.
>
> Now if that software wanted to add a signed attribute containing
> the HTML,
> or some transforms on the XML, to specify "this is what the
> signer actually
> saw", that might be a good idea, and could be used to resolve disputes
> about the signer's intent.  Should we modify the use case to
> something like
> that?
>
> Trevor
>
>
>