atom feed63 messages in org.oasis-open.lists.dssRE: [dss] Groups - dss-requirements-1...
FromSent OnAttachments
robe...@entrust.comMar 24, 2003 12:58 pm 
Gregor KarlingerMar 25, 2003 7:34 am.bin
Trevor PerrinMar 25, 2003 11:30 am 
Nick PopeMar 25, 2003 11:35 am 
Nick PopeMar 25, 2003 12:23 pm 
Trevor PerrinMar 25, 2003 12:29 pm 
Trevor PerrinMar 25, 2003 12:33 pm 
jmessingMar 25, 2003 12:36 pm 
Trevor PerrinMar 25, 2003 1:18 pm 
Nick PopeMar 25, 2003 1:21 pm 
Nick PopeMar 25, 2003 1:21 pm 
Nick PopeMar 26, 2003 1:21 am 
kare...@esat.kuleuven.ac.beMar 26, 2003 4:02 am 
Nick PopeMar 26, 2003 5:22 am 
jmessingMar 26, 2003 5:26 am 
Trevor PerrinMar 26, 2003 10:49 am 
jmessingMar 26, 2003 10:57 am 
Trevor PerrinMar 26, 2003 11:11 am 
Rich SalzMar 26, 2003 11:24 am 
Trevor PerrinMar 26, 2003 1:15 pm 
Greg AlvordMar 27, 2003 4:37 am 
Gregor KarlingerMar 27, 2003 9:01 am.bin
Trevor PerrinMar 27, 2003 1:17 pm 
Nick PopeMar 28, 2003 3:54 am 
Trevor PerrinMar 28, 2003 1:52 pm 
Nick PopeMar 29, 2003 9:35 am 
Rich SalzMar 29, 2003 10:10 am 
Trevor PerrinMar 29, 2003 10:14 am 
Rich SalzMar 29, 2003 10:36 am 
jmessingMar 29, 2003 11:19 am 
Rich SalzMar 29, 2003 11:26 am 
Trevor PerrinMar 29, 2003 11:46 am 
jmessingMar 29, 2003 12:31 pm 
Rich SalzMar 29, 2003 3:35 pm 
Trevor PerrinMar 30, 2003 1:49 am 
Gregor KarlingerMar 30, 2003 10:50 am.bin
Gregor KarlingerMar 30, 2003 11:07 am.bin
Gregor KarlingerMar 30, 2003 11:18 am.bin
Gregor KarlingerMar 30, 2003 11:23 am.bin
Gregor KarlingerMar 30, 2003 11:31 am.bin
Gregor KarlingerMar 30, 2003 11:47 am.bin
Gregor KarlingerMar 30, 2003 11:58 am.bin
Gregor KarlingerMar 30, 2003 12:14 pm.bin
Gregor KarlingerMar 30, 2003 12:23 pm.bin
Rich SalzMar 30, 2003 2:25 pm 
Gregor KarlingerMar 30, 2003 11:14 pm.bin
Gregor KarlingerMar 30, 2003 11:20 pm.bin
Gregor KarlingerMar 30, 2003 11:26 pm.bin
Gregor KarlingerMar 30, 2003 11:30 pm.bin
Gregor KarlingerMar 30, 2003 11:37 pm.bin
Trevor PerrinMar 31, 2003 1:41 am 
Gregor KarlingerMar 31, 2003 1:48 am.bin
Gregor KarlingerMar 31, 2003 1:56 am.bin
Nick PopeMar 31, 2003 4:02 am 
Anthony NadalinMar 31, 2003 5:15 am 
Karel WoutersMar 31, 2003 6:30 am 
Gregor KarlingerMar 31, 2003 7:22 am.bin
Trevor PerrinMar 31, 2003 8:46 am 
Gregor KarlingerMar 31, 2003 1:20 pm.bin
Nick PopeApr 1, 2003 1:32 am 
Karel WoutersApr 1, 2003 2:52 am 
Nick PopeApr 1, 2003 2:52 am 
Nick PopeApr 1, 2003 3:03 am 
Subject:RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
From:Gregor Karlinger (greg@cio.gv.at)
Date:Mar 30, 2003 10:50:18 am
List:org.oasis-open.lists.dss
Attachments:
bin00005.bin - 13k

Trevor,

sorry for the delayed answer, please see below.

-----Original Message----- From: Trevor Perrin [mailto:tre@trevp.net] Sent: Tuesday, March 25, 2003 8:38 PM To: Gregor Karlinger; robe@entrust.com Cc: ML OASIS DSS Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded

[...]

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.

The solution is not to sign the XML data, but rather all information used to compute the transforms. Almost all that information is al- ready signed because it is part of dsig:SignedInfo. The only additional information one has to take care separately are imported stylesheets in XSLT transforms.

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?

The relying party knows the XML, which forms the input of the transformation process. The relying party knows the transforms that should have been applied. The signature contains all infos about the transforms actually applied. As a consequence of those three facts the relying party can check if the relationship bet- ween the XML and the resulting data signed by the signing party is what it should be.

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.

The transformed, human readable result of the transforms must be signed in several cases, otherwhise you will not be able to create a signature accomplishing non-repudiation (e. g. with respect to the European Union legislation).

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?

This might work to resolve disputes in a court, but not for an automatic check of the relationship between the XML and the HTML.

/Gregor