FW: Preference for STR-based solution to identifying Token used to protect a RM Sequence

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

Forwarded from Hal . .

> -----Original Message-----
> From: Hal Lockhart 
> Sent: Wednesday, July 12, 2006 5:14 PM
> To: Gilbert Pilz
> Subject: Preference for STR-based solution to identifying 
> Token used to protect a RM Sequence
> 
> Having looked at the latest proposal from Oracle, using the 
> usage label, as well as their slide deck relating to 
> implementation issues, I still believe the STR-based approach 
> proposed by IBM & MSFT, is superior.
> 
> 1. The STR approach will not require that existing WSS logic 
> be altered.
> 
> 2. The STR approach allows a variant of the same solution to 
> be used when a Security header is not present, i.e. when 
> SSL/TLS is used.
> 
> 3. The usage label approach in my view entangles the 
> processing of the security and RM layers, whereas the STR 
> approach permits cleaner layering. In particular, the 
> Security layer will have to know what portions of the message 
> constitute an RM sequence and thus require protection.
> 
> 4. I don't believe the usage label approach can easily handle 
> multiple services, sequences and tokens without introducing 
> additional ad hoc rules.
> 
> The slides provided Oracle presume a particular and in my 
> view peculiar implementation. In particular the logic to 
> handle signatures protecting RM sequences will be different 
> from that of applications and other services using 
> signatures. The analysis only shows one step (create 
> sequence) in the entire process, omitting steps such as 
> secure conversation setup and sequence transmission. As 
> mentioned above, it appears that the security layer will be 
> required to identify what elements must be protected when 
> transmitting a sequence.
> 
> I acknowledge that the STR-based approach requires making use 
> of the schema defining the STR, but I expect this to be 
> stable and widely known and thus able to be used in a 
> "canned" way. Thus I am not concerned about this issue.
> 
> Hal