Re: PASWA, canonicalization, and signatures

Hi Tony.  I believe that the idea here is that the conversion from
binary to characters--the base64 encoding--will be built into the
signature algorithm.  Therefore the binary can be sent over the
wire and stored locally, then the signature computation will convert
to base64 immediately before computing its values.  This approach
allows binary transmission and storage without reopening the
standards for signatures.

John.

At 04:31 PM 6/10/2003 +0100, Tony Graham wrote:

> 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

______________________________________________________
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 Tuesday, 10 June 2003 12:39:02 UTC