Open issue on BSP10 secure channel (Re: [ogsa-wg] Teleconference minutes - 12 September 2005)

[Hiro Kishimoto]

Thanks Takuya for starting this discussion thread.

Yes, I think R0301 sets bar too high, IMHO.
I would make one more point that R0302 cannot allow client-side
simpler implementation.

Given that OGSA WSRF BP 1.0 mandates to provide state-change
notification, client-side implementation is RECEIVER of such
state-change notifications.

Thus both server-side and client-side software must support
TLS and MLS. I guess that is not Takuya's intention.

Thoughts?
----
Hiro Kishimoto

Takuya Mori wrote:
> Hi All,
> 
> I am sending this message to get more opinions on the issue 
> about requiring the implementations to support both TLS and MLS.
> 
> Hopefully, I'd like to form a consensus on it before reviewing 
> the BSP on the next monday call.
> 
> 
>>  - R0301,0302: mandates that the RECEIVER support both TLS and MLS;
>>    and SENDER can use either.
>>    - Hiro thinks that this sets too high a bar on implementations and
>>      should be relaxed for the RECEIVER also.
>>    - Takuya thinks that the secure channel profile sets a high bar
>>      anyway so this additional requirement is acceptable and is
>>      needed to promote interoperability.
>>    - No consensus reached.
>>    - Takuya will put the issue to the list to get more opinions.
> 
> 
> Here is the statement.
> 
> ----
> R0301 A RECEIVER MUST support both Transport Layer Security and 
>       Message Level Security as profiled in the section 3.2 and 
>       3.3 of this Profile.
> 
> R0302 A SENDER MUST employ, at least, one of Transport Layer 
>       Security or Message Level Security as profiled in the 
>       section 3.2 and 3.3 of this Profile.
> ----
> 
> The current draft of the OGSA BSP10 Secure Channel mandates a 
> RECEIVER to "support" both TLS and MLS, while it requires to
> use at least one of them for a SENDER.
> 
> My intention here is that to require the support of the both
> of TLS and MLS by a RECEIVER is essential to ensure 
> interoperability,  because supporting one of them by a RECEIVER
> allows mismatch of the protocol between a RECEIVER and SENDER.
> 
> On the otherhand, as described in the minutes above by Andreas,
> Hiro thinks that this sets too high a bar on implementations and
> should be relaxed for the RECEIVER also.
> 
> I can also understand his opinion.  And I think the cause of
> the contrary is that we have different priorities between
> interoperability and practicability.
> 
> Any comments to this issue will be welcomed very much!
> Just telling us your preference will also be great.
> 
> Thanks,
> Takuya
> 
> 
>