PASWA, canonicalization, and signatures

From paswa61.html [1] onwards, there has been several statements made
about the desirability and feasability of applying digital signatures
to messages with attachments, but usually without saying who will
design the canonicalization (c14n) algorithms to use or how to sign
the "value space" [0095] when the "abstract process" is that "[t]he
application adds any binary attachment to the SOAP message infoset as
base64 encoded content." [0145]

1. Who is expected to invent the c14n algorithm to be used when
   signing the "value space"?

   Note that the W3C XML Signature and XML Encryption activities
   closed in May 2003. [2]

2. Given the widespread assumption of signing the "value space", "raw
   octets", or "binary data", is it more correct that the "abstract
   process" is that "the application adds any binary attachment to the
   SOAP message as binary content" and that it's only "inefficient
   implementations" that will add attachments as "base64 encoded
   content"?


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


Background Information
======================

Section 8, Security Considerations, of paswa61.html [1] includes:

   Current XML signature algorithms require signing the included data
   as base64-encoded characters; the lexical form of such characters
   SHOULD be canonicalized. (A suitable algorithm may be under
   development by the XML Schema WG.) However, note that an
   include-aware canonicalization algorithm may be able to eliminate
   the need to convert between the raw octets and base64-encoded
   characters.

On May 8, Marc Hadley referred to "an attachment/xninc:Include aware
C14N algorithm that allows signing of the raw attachment octets
(base64 encoding not required)." [0038]

Also on May 8, Mark Nottingham proposed "An alternative is to use a
signature algorithm that (perhaps selectively) operates on the value
space of the content, rather than the lexical space." [0044]

Later on May 8, Mark Nottingham added:

   I think an appropriate question is whether it's a problem we (XMLP)
   need to provide a solution for, as it's rather specific to digital
   signatures, and therefore might be better considered elsewhere. I
   do agree that we need to investigate enough to assure that it's
   solveable, which we appear to be doing. [0048]

On May 14, Martin Gudgin stated:

   WRT disg we could define a C14N algorithm that ALWAYS works on the
   value space ( raw octets ) or one that ALWAYS works on the lexical
   space ( base64 chars as UTF-8 ). The former will cause extra work
   for non-PASWA nodes, the latter will cause extra work for PASWA
   nodes. [0095]

However, as quoted above, paswa61.html states "the lexical form of
[base64-encoded] characters SHOULD be canonicalized" so there is
presumably extra work for non-PASWA nodes in both cases.

The "Notes" in the message "PASWA in terms of a binding mechanism"
from Herve Ruellan on May 28 state:

   - Efficient implementations of these processes will provide ways
   for directly transfering the binary data from the application to
   the binding (or the reverse) without having to pass through the
   encoding/decoding process.
   - The *abstract representation* of binary attachments as base64
   encoded content allows non PASWA enabled SOAP features to handle
   correctly the message. For example a signature feature will be able
   to sign the message by signing the binary attachment as base64
   encoded content (for efficient implementation, this will require a
   base64 encoding step).
   - Some SOAP feature can also have efficient implementations by
   accessing directly the binary data and not asking for the base64
   encoded data. For example, a PASWA enabled encryption feature could
   encrypt directly the binary data. This same PASWA enabled
   encryption feature could also transfer the encrypted data directly
   as binary to the binding instead of storing it in the SOAP message
   as base64 content.


[1] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html
[2] http://lists.w3.org/Archives/Member/w3c-ac-members/2003AprJun/0028

[0038] http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0038.html
[0044] http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0044.html
[0095] http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0095.html
[0145] http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0145.html

Received on Tuesday, 10 June 2003 11:29:46 UTC