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


At 05:50 PM 3/29/2003 +0000, Nick Pope wrote:
>Content-Transfer-Encoding: 7bit
>
>Trevor,
>
>Canonicalisation does not deal with the application specific information
>between the tags.  Differences such as line lengths and white spaces which
>in HTML don't effect the output can so easily creep in.

Huh.  Well, if the canonicalization transform isn't really canonicalizing, 
then I'd say the transform needs to be fixed, or a better one defined or 
something.


>I feel that where there exists two alernatives, I would much rather go for
>the one which both parties work from the same data rather than depend two
>implementations of complicated transforms such as XSLT working in exactly
>the same way for all situations.

If they *don't* work in the exact same way, modulo canonicalization, then 
there's room for the requestor to say, "oh, I didn't mean to sign *THAT*, 
my XSLT processor produced something slightly different".

That's one reason I think signing the transformed data is better than 
signing the transforms themselves.  In addition to the fact that not all 
transforms will even *BE* signable, so this method has limited 
applicability.  Also, XML-DSIG only allows you to specify transforms that 
are applied to the to-be-signed data before the signing.  Now you're 
proposing a different thing, transforms that are applied to the was-signed 
data after signing.  So we'd have to create a new syntax to support these 
post-signature transforms.

In any case, this whole discussion has more to do with the format of an 
XML-DSIG, then with a DSS protocol.  I hope Gregor will let us know what he 
thinks we should do here, and we can see if/how it would impact the protocol.

Trevor


>Nick
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:trevp@trevp.net]
> > Sent: 28 March 2003 21:55
> > To: Nick Pope; karel.wouters@esat.kuleuven.ac.be;
> > dss@lists.oasis-open.org
> > Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
> >
> >
> > At 12:07 PM 3/28/2003 +0000, Nick Pope wrote:
> > >Content-Transfer-Encoding: 7bit
> > >
> > >Trevor,
> > >
> > >My concern with the signing of the data after an XSLT transform has been
> > >applied is that the chances of two independent implementations of XSLT to
> > >get exactly the same byte-by-byte value for all possible styles is fairly
> > >low, event though they will look the same.
> >
> > Is this taken care of by the last paragraph in XML-DSIG 6.6.5
> > (http://www.w3.org/TR/xmldsig-core/)? -
> >
> > "The output of this transform is an octet stream. The processing
> > rules for
> > the XSL style sheet or transform element are stated in the XSLT
> > specification [XSLT]. We RECOMMEND that XSLT transform authors use an
> > output method of xml for XML and HTML. As XSLT implementations do not
> > produce consistent serializations of their output, we further RECOMMEND
> > inserting a transform after the XSLT transform to canonicalize
> > the output.
> > These steps will help to ensure interoperability of the resulting
> > signatures among applications that support the XSLT transform.
> > Note that if
> > the output is actually HTML, then the result of these steps is logically
> > equivalent [XHTML]."
> >
> >
> > Trevor
> >
> >
> >



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