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

["Gregor Karlinger" <gregor.karlinger@cio.gv.at>]

Rich,

> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com] 
> Sent: Saturday, March 29, 2003 7:46 PM
> To: Trevor Perrin
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Groups - dss-requirements-1.0-draft-02.doc uploaded
> 
> 
> > 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.
> 
> It's irrefutable:  Any XSLT that has "<xsl:output 
> method='html'/>" cannot have a signature that covers the output.

Why shouldn't this be possible? The XSLT transform produces an octet
stream as output, and this octet stream can be signed. 

Of course, that octet stream cannot be fed into xml canonicalication;
therefore XMLDSIG recommends to choose output method xml.

/Gregor
 
> > 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.
> 
> >   In addition to the fact that not all
> > transforms will even *BE* signable
> 
> Hunh?  How so?  Are you saying the stylesheet is private?
>         /r$
>

smime.p7s