Re: PASWA, canonicalization, and signatures

+1

----- Original Message ----- 
From: <noah_mendelsohn@bea.com>
To: "Marc Hadley" <Marc.Hadley@Sun.COM>
Cc: "Rich Salz" <rsalz@datapower.com>; "Tony Graham"
<Tony.Graham@Sun.COM>; <xml-dist-app@w3.org>
Sent: Thursday, June 12, 2003 8:24 PM
Subject: Re: PASWA, canonicalization, and signatures


>
> I >think< there is a relatively obvious path to follow in the case of
> PASWA.  one that would be very much in the spirit of incremental
evolution
> that's characterized SOAP itself.
>
> In PASWA, the message is the Envelope infoset.  Any efforts to carry
parts
> of the data in binary are merely optimizations and are not visible at
the
> SOAP processing level.  The data we think of as attachments is at least
> conceptually present in the form of base64 character encodings.  As Rich
> has pointed out, there is some momentum toward using the already
published
> exclusive canonicalization as the basis for WS-Security, a least in the
> short to medium term.
>
> We all agree that exclusive canonicalization will work with such an
> Infoset, and the only question is whether an alternative approach might
> leverage the efficient availability of a binary form to improve
> performance.  My suggest (speaking for the moment only for myself and
not
> necessarily for my employer) is that we take the easy step first.  Let's
> start by relying on the standard exclusive canonicalization algorithm,
> applied to the character based infoset.  This builds largely on
> investments that will be made for other reasons anyway.
>
> If deployment experience shows that performance is indeed a problem, we
> always have the opportunity to consider later the possibility of a more
> elaborate c14n that would draw on the value space, at least for some
> elements.  Some of you may have noticed another thread I've started on
the
> relationship between PASWA and the XQuery data model.  I haven't seen
any
> specific requirements for doing signatures over instances of the XQuery
> model (I.e. signing the input and output of XML databases and queries),
> but it's not implausible that the need would eventually arise.  If so, I
> suspect that there might be synergy in considering together signatures
> over the XQuery model and optimizing PASWA signatures:  both involve
> combinations of value space and lexical space forms.
>
> For now, speaking for myself, I think it makes sense to start by using
the
> existing c14n recommendations in conjunction with the character form of
> the Infoset.  If individual implementations choose to optimize their
> computations of such signatures in the face of PASWA so be it, but such
> optimizations should not be visible externally.  The signature should be
> the same as that which would result from naively converting the value
> space to characters, and then signing that.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
>
>
>
>
>
>
> Marc Hadley <Marc.Hadley@Sun.COM>
> Sent by: xml-dist-app-request@w3.org
> 06/11/03 10:20 AM
>
>
>         To:     Rich Salz <rsalz@datapower.com>
>         cc:     Tony Graham <Tony.Graham@Sun.COM>, "xml-dist-app@w3.org"
> <xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Re: PASWA, canonicalization, and signatures
>
>
>
> On Tuesday, Jun 10, 2003, at 14:05 US/Eastern, Rich Salz wrote:
>
> >
> >> 1. Who is expected to invent the c14n algorithm to be used when
> >>    signing the "value space"?
> >
> > It's not clear that there needs to be one.  If it's binary data -- 
such
> > as a JPEG or PDF -- then specify specify no transform.  If it's XML,
> > then
> > (sigh) re-serialize the infoset according to one of the several c14n
> > methods that are already out there.
> >
> In that case, the problem is identifying which chunks to process as XML
> and which as binary. Unless we prohibit intermediaries from inlining
> attachments then its possible that something that was signed as binary
> at the start of the message chain will be converted to base64 text
> somewhere along the message path. Without some clever C14N (and perhaps
> some indication in the infoset to trigger clever behaviour) its likely
> that such binary->infoset transform will break signatues.
>
> If we want efficient signature processing then I think we either need a
> PASWA aware C14N or we need to prohibit intermediaries from messing
> with the message representation. The other answer is to do neither
> which means that sigs will need to be computed on the base64 encoded
> versions of attachments.
>
> Marc.
>
> >>    Note that the W3C XML Signature and XML Encryption activities
> >>    closed in May 2003. [2]
> >
> > Irrelevent; since Transform/@Algorithm is a URI, anyone can develop
> > a C14N spec.  UDDI has an XSD-based one, for example.
> >
> >>    SOAP message as binary content" and that it's only "inefficient
> >>    implementations" that will add attachments as "base64 encoded
> >>    content"?
> >
> > Or that that wish, e.g., to work over existing transports.
> >         /r$
> >
> >
> --
> Marc Hadley <marc.hadley@sun.com>
> Web Technologies and Standards, Sun Microsystems.
>
>
>
>

Received on Friday, 13 June 2003 14:33:46 UTC