Re: PASWA, canonicalization, and signatures

As someone who thinks base64 is an evil invention of those with too much
bandwidth and cpu time, I agree with Noah on the pragmatic value of
the approach he outlines for signatures.  We'd rather have standard with
base64 soon and a standard w/o base64 later, than only a standard w/o
base64 later.  I do think it prudent to have a working implementation with
binary transmission but b64-based signatures before we are locked in:
does that already exist?

At 11:24 PM 6/12/2003 -0400, noah_mendelsohn@us.ibm.com wrote:

>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.

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Friday, 13 June 2003 12:36:59 UTC