[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]