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 01:45 PM 3/29/2003 -0500, Rich Salz wrote:

> > 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.
>
>Hunh?  It's *xml canonicalization* not "HTML canonicalization."  We'd
>be foolish to waste time defining HTML canonicalization.

I'm over my head here, but does XHTML change anything?


>It's irrefutable:  Any XSLT that has "<xsl:output method='html'/>"
>cannot have a signature that covers the output.
>
> > 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".
>
>But if the source inputs are signed, then in case of conflict you can
>always go back to the source and see what was really there.  That's
>better than having unsignable output.

Right, that's why I was suggesting signing both the source document and 
it's transformed version:

<Reference URI="#SomeDocument">
   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
<Reference URI="#SomeDocument">
   <Transforms>
     <Transform Algorithm="http://www.someplace.org/SomeTransform"/>
   </Transforms>
   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <DigestValue>Q52xy4a9289mvDl1up4sbEVU89x=</DigestValue>
</Reference>

We agree that the source document needs to be signed, it's just a 
disagreement on whether to sign the human-readable transformed version, or 
the transforms that produced it.

My proposal would be simple to support in a DSS protocol - the client just 
asks the server to produce a signature on two references which refer to the 
same document, and asks the server to apply a particular transform to one 
of them (or applies the transform itself and sends the hash).  If there's 
issues with canonicalizing XSLT's HTML output, they're not our issues.

Would a "sign the transforms, but not the transformed output" approach be 
similarly simple?  What exactly would the resulting document look 
like?  Note that both Gregor Karlinger's initial example, and Greg Alvord's 
MISMO example, *did* sign the transformed output, so I'm not sure we've 
seen a concrete example yet of what you and Nick are proposing.

Anyways, I just worry that this is more a general XML-DSIG issue than a DSS 
issue, and so we shouldn't expend too much effort trying to solve it, 
unless we can do it very simply.

> >   In addition to the fact that not all
> > transforms will even *BE* signable
>
>Hunh?  How so?  Are you saying the stylesheet is private?
>         /r$

A transform (according to XML-DSIG 4.3.3.4) could be just about any 
algorithm, it doesn't have to be XSLT.  The approach I suggested would work 
with any transform, not just those that are representable in XML like XSLT.

Trevor 



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