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

[Trevor Perrin <trevp@trevp.net>]

Right, but then I think you need to sign both the XML *and* the 
transformed, human-readable form.

As described, Gregor's use case only signs the transformed, human-readable 
form (which is produced from the XML by transforms, but that's not the same 
as signing the XML).

Trevor


At 08:37 PM 3/25/2003 +0000, you wrote:
>Content-Transfer-Encoding: 7bit
>
>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
> >
> >
> >