OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Trevor,

sorry for the delayed answer, please see below.

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net] 
> Sent: Tuesday, March 25, 2003 8:38 PM
> To: Gregor Karlinger; robert.zuccherato@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

smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]