W3C home > Mailing lists > Public > xml-dist-app@w3.org > June 2003

Re: PASWA, canonicalization, and signatures

From: Tony Graham <Tony.Graham@Sun.COM>
Date: Tue, 10 Jun 2003 23:00:58 +0100
Message-ID: <16102.21786.848953.450891@tenso.ireland.sun.com>
To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>

Rich Salz wrote at 10 Jun 2003 14:05:08 -0400:
 > > 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.

It's fine by me if there isn't a c14n algorithm in use.  My point is
that posts to this list have been all over the map w.r.t. both what is
required for canonicalization and who is going to work out what is
required.

It's better to say that we don't know yet than to have numerous
conflicting assumptions.

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

I know that.  I mentioned the W3C activities because they would be the
obvious choice if you followed the "better considered elsewhere"
sentiment through to a conclusion.

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

But what the application passes in isn't necessarily what gets sent
over existing transports, otherwise the current "abstract process"
wouldn't 'convert all occurences to "xbinc:Include" elements and
create an attachment containing the decoded data of each occurence.'

The desire expressed from paswa61.html onwards is "to eliminate the
need to convert between the raw octets and base64-encoded characters."
Given that, I'm asking whether it's better to consider that the
abstract process is about binary data, not about base64-encoded data,
since everybody is talking about binary data.  That leaves the "base64
encoded content" as how you talk about the "real" abstract process in
SOAP terms.  That seems more real to me than talking in abstract terms
about "efficient implementations" and "PASWA enabled" features when
it's the "efficient implementations" that people will be zeroing in
on.

The answer can be "No", of course.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708
Received on Tuesday, 10 June 2003 17:58:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT