Re: New Attachments Issues

On Tuesday, Jun 10, 2003, at 10:56 US/Eastern, Jacek Kopecky wrote:

> I don't think we ever wanted to consider security mechanisms visible to
> the application that would be aware of any optimizations not visible to
> the application, like the optimization of binary data in SOAP messages.
> I thought the expectation was that dig-sig or encryption would work on
> canonical base64 representation of the data. There can still be some
> optimizations in the implementations, e.g. only do the base64 encoding
> on the fly for signature computation, never store the actual full 
> base64
> version of the data. Base64 encoding is cheap and if the signature code
> can consume a stream, the cost of base64 encoding will be lost in the
> cost of computing the signature, I believe (and somebody else has
> mentioned this before me, too).
>
I'd like to see some performance data on this, do you have a pointer to 
any ? In order to make an informed choice I think it behooves us to 
consider real data rather than make any such assumptions.

Thanks,
Marc.

>
> On Tue, 2003-06-10 at 16:35, Marc Hadley wrote:
>> So, to paraphrase, you would say that:
>>
>> (1) We DO NOT expect intermediaries to preserve what is serialized as
>> attachments and what is serialized inside the SOAP envelope.
>>
>> (2) The binding determines which nodes to serialize as attachments in
>> an implementation specific manner.
>>
>> That's certainly a coherent answer to the two issues.
>>
>> Your proposed answers probably have some implications for the set of
>> security technologies we can apply to messages containing attachments,
>> e.g. I expect it would prevent use of S/MIME or PGP-MIME. It also 
>> means
>> that digital signatures must always be calculated on the text data
>> representation of attachments and verified using the same - i.e. even
>> if you use attachments to optimize the transfer, if you are using XML
>> security that includes the attachment data then you always need to
>> compute the base64 transform at both sender and receiver.
>>
>> Marc.
>>
>> On Tuesday, Jun 10, 2003, at 07:46 US/Eastern, Jacek Kopecky wrote:
>>
>>> As we're only talking about optimization of transfer of binary data
>>> (we're not yet talking about the other aspects of PASWA, like
>>> swa:Representation), it is not critical from our point of view that 
>>> the
>>> optimization be preserved across intermediaries (1) or that it be 
>>> done
>>> at all (2). However, I do think we should say something, so I prefer
>>> option (ii) below - that we say your two questions are answered in
>>> implementations in an implementation-specific way.
>>>
>>> It is important that whatever we produce from PASWA emphasizes the 
>>> fact
>>> that we're providing a possible optimization of binary data transfer
>>> and
>>> how it may be particularly useful with the other stuff like
>>> swa:Representation.
>>>
>>> Best regards,
>>>
>>>                    Jacek Kopecky
>>>
>>>                    Senior Architect
>>>                    Systinet Corporation
>>>                    http://www.systinet.com/
>>>
>>>
>>>
>>>
>>>
>>> On Fri, 2003-06-06 at 18:25, Marc Hadley wrote:
>>>> All,
>>>>
>>>> Following the resolution of issue 429[1], I'd like to raise the
>>>> following new issues:
>>>>
>>>> 1: "What are the semantics of attachments w.r.t. SOAP 
>>>> intermediaries.
>>>> E.g. do we expect intermediaries to preserve what is serialized as
>>>> attachments and what is serialized inside the SOAP envelope."
>>>>
>>>> 2: "How does the binding determine which nodes to serialize as
>>>> attachments ?"
>>>>
>>>> Amongst the many possible answers, the following spring immediately 
>>>> to
>>>> mind:
>>>>
>>>> (i) We don't specify that.
>>>> (ii) An implementation specific mechanism (similar to (i) but we
>>>> explicitly say so).
>>>> (iii) Its triggered by something in the infoset - if so, what.
>>>>
>>>> Thanks,
>>>> Marc.
>>>>
>>>> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x429
>>>>
>>>> --
>>>> Marc Hadley <marc.hadley@sun.com>
>>>> Web Technologies and Standards, Sun Microsystems.
>>>
>>>
>> --
>> Marc Hadley <marc.hadley@sun.com>
>> Web Technologies and Standards, Sun Microsystems.
>
>
--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Wednesday, 11 June 2003 10:31:34 UTC